You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: Superstructure
Superstructure Author
User level: Level 1
0 points

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
12 replies
User profile for user: Superstructure
Superstructure Author
User level: Level 1
0 points

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
User profile for user: etresoft
etresoft
User level: Level 9
50,854 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
User profile for user: Superstructure
Superstructure Author
User level: Level 1
0 points

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
User profile for user: ALMB
ALMB
User level: 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
User profile for user: geofizzer
geofizzer
User level: Level 1
0 points

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
User profile for user: jcohnsf
jcohnsf
User level: 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

Apple Perl and LDAP

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.
Learn more Sign up