On Fri, 9 May 2008 15:35:18 -0400 "Scorpion7" scorpion7@iqonline.net wrote:
Here's what happens:
nav start getDeviceData <enter>
(execution hangs - intr won't work, have to CTRL+Z and then do a kill -9 PID to stop. The same occurs for nav start eventengine)
Attached are 4 text files (extension to show which command was utilized to generate the output. The first line of each file shows the command and arguments utilized to generate the output. In getDeviceData it appears that the last action was to chdir to the nav directory.
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?
What is the difference between 'nav start ....' and executing the process directly, ie: cd etc/init.d ./getDeviceData start
"nav start ..." fails and "./getDeviceData start" succeeds? I think the inherent difference may help us to understand what is happening and why the failure. Or at least may help me to locate more pertinent data.
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?
Besides, you say that "nav start alertengine" seems to stall, and this command will not modify the crontab, since alertengine isn't a cronjob but a daemon. It will however look at the files in the cron.d directory, and look at the navcron user's crontab with "crontab -u navcron -l".
This is an interesting point. I su'd to navcron, just to verify and this command is denied (as I expected).
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.
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).
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 :-)
(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.
On Thu, 15 May 2008 12:02:34 -0400 "Scorpion7" scorpion7@iqonline.net wrote:
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. :-|
Yes, your impression is incorrect. The nav program operates as root and uses "crontab -u navcron" to read/manipulate navcron's crontab. su is used by the shell scripts in etc/init.d/ to drop root privileges when running Java programs.
Thanks, although I found the complete truss (with forks) output more helpful this time around :-)
Interesting.
But it still doesn't make me any smarter. I can't really think of a reason why the su command would hang after a call to chdir. I've also never heard of anyone else having this problem when running NAV on FreeBSD :-/ It doesn't seem NAV related at all to me, but still...
-
Morten Brekkevold -
Scorpion7