More cron weirdness

giskard22 · 10-03-2005, 12:08 PM

I was having some trouble because, in 10.4, it appears that cron doesn't use the standard PATH. It seems like this is a change from 10.3. It also appears that chown commands in scripts run by cron don't have access to non-local users.

I have a user refresh script that, upon logout, deletes the contents of a user home and copies fresh files from a template. When it runs overnight via cron, it breaks. The last step in the script is to chown the new files to the user instead of root (which performed the copy). The problems seems to be that the user is in an Open Directory, and when cron runs the script chown doesn't think the user exists. The files end up still being owned by root. You can imagine how well that works when the user tries to log in. :\

Any ideas on how to fix this?

hayne · 10-03-2005, 12:42 PM

Quote:

Originally Posted by giskard22


	The last step in the script is to chown the new files to the user instead of root (which performed the copy). The problems seems to be that the user is in an Open Directory, and when cron runs the script chown doesn't think the user exists.

1) Please show the exact commands being used and the error messages (verbatim) received.

2) Does the script work for local user accounts? Does it work when you run it in a Terminal window?

3) Try replacing the 'chown' command by a command that merely prints out info about the user account - e.g. '/usr/bin/id user_name'

4) You might consider using something like "Radmind": http://eq.rsug.itd.umich.edu/software/radmind/

giskard22 · 10-03-2005, 12:50 PM

I guess I wasn't too clear. This script runs perfectly, dozens of times a day, from the logoutHook and from interactive shells. It only breaks when it runs via cron. I look at the systems in the morning, after the cron job runs, and the copied files are still owned by root instead of by the user. If you log in and log out (so the logoutHook runs the refresh script again), everything gets fixed.

The command is 'chown -R student:staff /Users/student'. When cron runs the script, the files end up with root:staff ownership. Student is an Open Directory user.

I haven't looked at it in about 5 months, but radmind is far more complicated than I need. This is an extremely simple script: move everything from /Users/student to a folder in /Library, copy files from a template to /Users/student, and chown the files.

edit: I have no idea where to look for error messages generated by cron jobs.

hayne · 10-03-2005, 01:36 PM

Quote:

Originally Posted by giskard22


	The command is 'chown -R student:staff /Users/student'

As I said in the other thread where you had trouble with cron:

Quote:

Originally Posted by hayne


	As a system admin, you should always be specifying the full path to commands in your scripts.

giskard22 · 10-03-2005, 02:04 PM

Well, OK, I'll certainly try specifying the path, but given that all the other commands in 4 or 5 different scripts work as expected (ditto, cp, rm, hdiutil, chmod, etc) is there any reason to suspect that this is the problem?

It may be worth noting that this doesn't always fail. In testing, I obviously have to keep editing /etc/crontab to get it to run the jobs again. In repeated attempts on the same computer, it stops having problems. But when it runs overnight, the failure is consistent.

Since I think that the likelihood of problems with chown is low, is there perhaps the possibility that, after a couple hours of non-use, machines are losing their connection to the Open Directory?

Also, if there's something sent to stderr during a cron job, where does it go? How can I do better diagnosis?

hayne · 10-03-2005, 02:22 PM

Quote:

Originally Posted by giskard22


	I'll certainly try specifying the path, but given that all the other commands in 4 or 5 different scripts work as expected (ditto, cp, rm, hdiutil, chmod, etc) is there any reason to suspect that this is the problem?

Results of my cron script that did '/bin/echo $PATH > /tmp/cronpath':

Code:

% cat /tmp/cronpath 
/usr/bin:/bin

Investigation of the commands you listed above and the command you had trouble with:

Code:

which ditto
/usr/bin/ditto
% which cp
/bin/cp
% which rm
/bin/rm
% which hdiutil
/usr/bin/hdiutil
% which chmod
/bin/chmod
% which chown
/usr/sbin/chown

Quote:


	if there's something sent to stderr during a cron job, where does it go? How can I do better diagnosis?

I think the output gets mailed to the user (in this case, 'root') who was running the cron job. That means that you probably need 'postfix' (email server) enabled to see this mail. Note also that you can control this with MAILTO in the crontab itself. (see the cron man page)

Another possibility would be to run 'cron' in a Terminal window (after killing the existing 'cron' process) and supply some of the debug flags via the "-x" option. I note that the values for these debug flags seem not to be described in the current version of the cron man page but you can find info about them by googling for: cron debugflags

giskard22 · 10-03-2005, 03:32 PM

Wow. The endless layers of UNIX protecting the system from itself strike again. Thanks, hayne.

acme.mail.order · 10-03-2005, 07:09 PM

regarding the chown problem - remember that you don't have to use a name. chown accepts the user ID number even if there is no user associated. Later, when an association becomes available the proper name will reappear.

In reality, chown always works on the number, it accepts a name from you as a convenience, looks up the UID number, and sets the file to that. `ls` and other processes do it in reverse.

For fun on Halloween, try `chown :666 ./*` - changes the group id of all files to Satan, but doesn't affect usability unless you are dependent on groups.

giskard22 · 10-03-2005, 07:17 PM

Hehe! It was definitely a problem of the executable being outside cron's $PATH, so going through my scripts and making sure commands had absolute paths took care of things. I drew the line at putting /bin/ in front of every mv, cp, and echo though. :P

This organization of executables just astonishes me. I hope Apple takes an axe to it like I did to the various methods of launching daemons and background tasks.

acme.mail.order · 10-03-2005, 07:27 PM

Quote:

Originally Posted by giskard22


	This organization of executables just astonishes me. I hope Apple takes an axe to it...

Don't hold your breath. That's the flipside to hardcoding paths - you can't rearrange your system. The unix path organization does make some sense, but it's also got 30 years of evolution behind it, and evolution isn't always neat and tidy.

10-03-2005, 12:08 PM	#1
giskard22 Moderator Join Date: May 2003 Posts: 4,272	More cron weirdness I was having some trouble because, in 10.4, it appears that cron doesn't use the standard PATH. It seems like this is a change from 10.3. It also appears that chown commands in scripts run by cron don't have access to non-local users. I have a user refresh script that, upon logout, deletes the contents of a user home and copies fresh files from a template. When it runs overnight via cron, it breaks. The last step in the script is to chown the new files to the user instead of root (which performed the copy). The problems seems to be that the user is in an Open Directory, and when cron runs the script chown doesn't think the user exists. The files end up still being owned by root. You can imagine how well that works when the user tries to log in. :\ Any ideas on how to fix this?

10-03-2005, 12:50 PM	#3
giskard22 Moderator Join Date: May 2003 Posts: 4,272	I guess I wasn't too clear. This script runs perfectly, dozens of times a day, from the logoutHook and from interactive shells. It only breaks when it runs via cron. I look at the systems in the morning, after the cron job runs, and the copied files are still owned by root instead of by the user. If you log in and log out (so the logoutHook runs the refresh script again), everything gets fixed. The command is 'chown -R student:staff /Users/student'. When cron runs the script, the files end up with root:staff ownership. Student is an Open Directory user. I haven't looked at it in about 5 months, but radmind is far more complicated than I need. This is an extremely simple script: move everything from /Users/student to a folder in /Library, copy files from a template to /Users/student, and chown the files. edit: I have no idea where to look for error messages generated by cron jobs.

10-03-2005, 02:04 PM	#5
giskard22 Moderator Join Date: May 2003 Posts: 4,272	Well, OK, I'll certainly try specifying the path, but given that all the other commands in 4 or 5 different scripts work as expected (ditto, cp, rm, hdiutil, chmod, etc) is there any reason to suspect that this is the problem? It may be worth noting that this doesn't always fail. In testing, I obviously have to keep editing /etc/crontab to get it to run the jobs again. In repeated attempts on the same computer, it stops having problems. But when it runs overnight, the failure is consistent. Since I think that the likelihood of problems with chown is low, is there perhaps the possibility that, after a couple hours of non-use, machines are losing their connection to the Open Directory? Also, if there's something sent to stderr during a cron job, where does it go? How can I do better diagnosis?

10-03-2005, 03:32 PM	#7
giskard22 Moderator Join Date: May 2003 Posts: 4,272	Wow. The endless layers of UNIX protecting the system from itself strike again. Thanks, hayne.

10-03-2005, 07:09 PM	#8
acme.mail.order League Commissioner Join Date: Sep 2003 Location: Tokyo Posts: 6,334	regarding the chown problem - remember that you don't have to use a name. chown accepts the user ID number even if there is no user associated. Later, when an association becomes available the proper name will reappear. In reality, chown always works on the number, it accepts a name from you as a convenience, looks up the UID number, and sets the file to that. `ls` and other processes do it in reverse. For fun on Halloween, try `chown :666 ./*` - changes the group id of all files to Satan, but doesn't affect usability unless you are dependent on groups.

10-03-2005, 07:17 PM	#9
giskard22 Moderator Join Date: May 2003 Posts: 4,272	Hehe! It was definitely a problem of the executable being outside cron's $PATH, so going through my scripts and making sure commands had absolute paths took care of things. I drew the line at putting /bin/ in front of every mv, cp, and echo though. :P This organization of executables just astonishes me. I hope Apple takes an axe to it like I did to the various methods of launching daemons and background tasks.