(responses below)
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Tuesday, May 13, 2008 7:23 AM To: Scorpion7 Cc: nav-users@uninett.no Subject: Re: NAV on FreeBSD
On Fri, 9 May 2008 15:35:18 -0400 "Scorpion7" scorpion7@iqonline.net wrote:
Well, upon reading the truss output of "nav start getDeviceData", it seems that the "su" command is the one that hangs after the chdir command.
Can you successfully execute "su - navcron" as root? Does the navcron user have a valid login shell?
You can su - navcron and everything appears to work as expected. PATH is correct, etc.
There's no difference, really. The nav command is a convenience tool to do all the starting and stopping in one go (plus the added crontab manipulation). It still calls the etc/init.d scripts in the end.
Are you running both commands as root?
I have done both as root.
Wait, are you saying that "su - navcron" fails? That would be a reasonable cause for your problem. Several of the init scripts are designed to be run as root, and use su to drop privileges to navcron before executing processes that cannot drop privileges by themselves (such as java).
As I mentioned in less detail above, the navcron user must have a valid login shell for the su'ing to work.
No - for any user (except root), you may not specify the "-u" parameter when calling crontab. This is a compiled in default (out of the box). That was the only point I was trying to make. I wasn't sure if anything was trying to call "crontab -u navcron" as a non-root user during the process - as this would break the process. Ie: su - navcron; crontab -u navcron -e <-- This breaks su - navcron; crontab -e <-- This works I think somewhere I may have gotten the impression that crontab was called as "crontab -u navcron" by the navcron user. This may be incorrect on my part. :-|
there is a Python class for crontab but nothing that defines command
line
arguments (not familiar with python).
Crontab commands are hardcoded on lines 243 and 261 in startstop.py. The nav script requires root access to run properly (and will give a warning/error if executed by anyone but root).
Yes - the calls begin with root. Any "su" events would have an origination ID of root.
I've also included the strace output - as it sounded like you are
more
familiar with strace - may help to locate the issue.
Thanks, although I found the complete truss (with forks) output more helpful this time around :-)
Interesting.