Apple Perl and LDAP

Question

Apple Perl and LDAP

We have come across some strange and rather annoying behaviour of Apple's implementation of Perl and LDAP.

I am part of a small scientific software company that provides specialist software for life sciences.

Our internal network is driven by linux servers, but we also have a number of intel Mac's, as many of our customers are using Mac's as well. User accounts on our network are set up and information propogated using LDAP.

Some of our software makes use of some perl scripts.

We have noticed that if we log in to one of the Snow Leopard machines (via ssh) and run our software in the background and then log off before the job finishes, then frequently the job will crash with an error perl: no user <uid>.

If you do not log off, the job completes correctly. This appears to be related to the directory services cache - dscachutil -list will correctly return user information if you are logged in. If you run in the background and log off, it returns nothing.

If, however, we install a different perl install, say Activestate perl, then this problem disappears - we can submit jobs in the background and log off and the jobs finish correctly.

Has anyone else observed this and more importantly, is there a simple solution that doesn't involve installing a new perl distribution?

imac, Mac OS X (10.6.2)

Posted on Mar 24, 2010 11:38 AM

Reply

Answer 1

etresoft

Level 8

46,312 points

Mar 24, 2010 4:37 PM in response to Superstructure

Can you provide more detail about what exactly is causing the error? What is the Perl script doing?

Reply

Answer 2

Mar 25, 2010 3:12 AM in response to etresoft

We think it is perl initialisation that is doing this. Possibly in combination with LDAP.

If I ssh to our Mac Pro running Snow Leopard and execute the following:
sleep 10 ; perl -e 'use strict;' || echo failed with status $status > x.out &

and then logout immediately, perl will exit with error status. If I stay logged in, it is fine!

As I have said- if we install ActiveState perl, it works! This is also a problem that only seems to affect Snow Leopard. We have some machines still running Leopard and they are fine.

We believe that perl's getpwuid may be getting its answers from the directory services cache?

If you run sleep 10; dscacheutil -list > dscache.out & and stay logged in, then you get the user info listed in the output file. If you immediately log out, the output file is blank.

Reply

Answer 3

etresoft

Level 8

46,312 points

Mar 25, 2010 4:34 AM in response to Superstructure

Well, there certainly may be some LDAP issues going on, but first I need verify that you are actually running this script via nohup.

Reply

Answer 4

Mar 26, 2010 3:48 AM in response to etresoft

We were not running via nohup but I have just tried running via nohup - made no difference to the outcome.

Reply

Answer 5

etresoft

Level 8

46,312 points

Mar 26, 2010 6:55 AM in response to Superstructure

In that case, you'll have to provide intimate details about how your LDAP is setup and what that script does. I can think of any number of reasons that a script running under an LDAP-managed account should catastrophically fail when that user logs out. You may be able to construct a script that runs successfully, maybe not. The only safe method would be a launchd script. If ActiveState Perl works, that honestly sounds more like an ActiveState bug than an Apple one.

I am no LDAP expert. But if I wanted all my users to be run from server-managed accounts, I don't think I would want user scripts running when the user isn't logged in. What about their home directory mounted on the server? What about usage restrictions? How can you check usage rights when the account isn't logged on anymore?

Maybe take a step back and explain (at a high level) what you are really trying to do with this script. Honestly, running nohup scripts is not a normal task. I probably only do it once or twice a year. I've never done it on a Mac with a server-managed account.

Reply

Answer 6

Mar 26, 2010 9:18 AM in response to etresoft

I think you maybe have misunderstood slightly. Our Mac Pro is a client machine on our local network. It mounts users home directories, exported from the server. Users do not have local directories and no disks/partitions are exported from the Mac.

Whilst it is the case that most of the time, the only person running jobs on the Mac is logged in to its console and remains logged on, as a groupo of software developers, occasionally others need to test software under OS X and thus need to log in to the Mac - via ssh.

Some of the jobs we run can take an hour or more so we tend to submit the job in the background and log off and get on with other jobs on our local workstation and periodically check in on the progress of the job.

Our software suite includes a number of perl scripts. None of these explicitly go to query the system to confirm the users uid. This behaviour is presumably in the perl initialisation - something that is doen automatically when perl is invoked, before even attempting to interpret the actual script.

As for the ldap set up it seems it has been set up with more or less default options. The device mapping is set to RFC 2307(unix).

As I have said, this is only an issue with Snow Leopard. We have some machines running Leopard, which are set up and connected to the network in exactly the same way, same LDAP set up, and they are fine. We also do not have any issues with any of our linux workstations.

Stop press: This is not simply limited to perl. It would seem that python is also affected - we have just tried to run the command
sleep 10 ; python -c "print 'Hello World'" > & xx.out ; echo $status >> xx.out &
and log out immediately - this also exits with error status. If you do not log out, then it is OK.

Is there some particular LDAP setting that needs to be changed/added?

Reply

Answer 7

etresoft

Level 8

46,312 points

Mar 26, 2010 10:06 AM in response to Superstructure

Maybe ask your question in the MacOS X Server forum.

Reply

Answer 8

ALMB

Level 1

0 points

Mar 30, 2010 12:27 AM in response to Superstructure

I thought I would add that I'm actually running into the same issue with perl. We're using an automated build system called QuickBuild (pmease.com), which basically installs a client on a build machine, and allows a script to be executed on the build machine. We use perl in one of the scripts, and I noticed that this was happening with a macmini server that we recently got (with Snow Leopard). And of course we never have this problem with an older macmini which still has Leopard installed.

It seemed to be a random problem, and I was never able to narrow down the issue, but after reading your post, I started looking into LDAP. We don't use LDAP (normally we use NIS, but I turned it off here to see if it would help this issue), but looking in Directory Utility, LDAP is actually enabled by default, even if nothing is configured for it. I unchecked it, and the problem seems to have gone away.

There could be one other thing that fixed it, however. The QuickBuild client is started through a terminal command, so it can be done directly on the machine, or through ssh. This time, I tried it directly on the machine (in addition to disabling LDAP), so that could have had something to do with it.

Hopefully this will help you in some way. I've had this problem for several months, and there was nothing on google for "perl: no user" until your recent posts. Definitely a frustrating problem!

If I get a chance later, I'll try to do some tests to try and figure out what exactly fixed it. But for now, I'm just glad to get it working, so I can't mess with it for awhile.

Reply

Answer 9

Apr 23, 2010 2:28 PM in response to Superstructure

I wanted to add myself to list of people having this problem. If I run a csh script that calls perl scripts on my Mac Pro (running Snow Leopard) in the background (from ssh) and logout, then when I return, the output is full of "Perl: no user <uid>" messages. This is a crippling problem for what I need to do, since I have routines that take overnight to run and I can't monopolize the console.
I made sure my OS and Xcode are up to date before posting this, so I think its an ongoing problem. I haven't changed any LDAP settings on the Mac Pro, or done anything else sophisticated, I frankly wouldn't know how. It is a computer that was originally purchased with Leopard and Snow Leopard was recently installed.
Any help or ideas will certainly be appreciated!

Reply

Answer 10

Apr 23, 2010 4:45 PM in response to Superstructure

Ok, I tried turning off LDAP and this didn't change the behavior at all (not sure it was even applicable for a computer without network login(?)). I also tried starting the script from in front of the computer and then logging out and the problem was still the same.

Reply

Answer 11

etresoft

Level 8

46,312 points

Apr 23, 2010 4:55 PM in response to geofizzer

Same question applies. Are you using nohup?

Try running Terminal and then ssh into your box. That will put you into a different, non GUI, environment. Then run your script, exit (twice) and logout.

Reply

Answer 12

jcohnsf

Level 1

0 points

Jul 12, 2010 12:09 PM in response to Superstructure

I have been trying to run a Java program in the background, which I have not run in 2 years. The program loops through many job requests and as part of the job executes a perl script. Two years ago, this program ran fine on both Linux (various flavors) and Mac (Leopard? Tiger?). I tried running it again a few days ago and came across the problem discussed in this thread: i.e. everything runs just fine until I log out of the user account where I started the program - either locally or remotely. Everything else runs just fine in the background. It is only perl scripts which fail (with the no user message). To eliminate other issues, I wrote a c shell script with a loop to execute over and over again a much simpler perl script. Execution of this simple script had the same problem with or without nohup (note: on various computers running Snow Leopard desktop and server that I tried, Java, c shell scripts, fortran programs, etc do not require nohup to run in the background after logging out).

I spent many frustrating hours over the weekend troubleshooting the issue. I only saw this thread this morning but by that time I had figured out a workaround: use sudo. If I run the program in the background with sudo, I can safely log out and the perl script executes as it should.

Has anyone else found any other solutions?

Reply