-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
job stuck in an infinite loop #59
Comments
The job launches sysadm-server, which then launches a child named sysadm-binary. It is the child process (sysadm-binary) that exhibits the bad behavior. It appears that sysadm-server dies, and this causes sysadm-binary to spin trying to talk to it. Here is how sysadm-server was being spawned by rc(8):
When spawned like this, it opens the following files:
I suspect that it is unhappy that launchd opens stdin/out/err to /dev/null, rather than /dev/pts/0. |
Here is the procstat output for volmand(8) that shows it redirects stdio descriptors to /dev/null
There is a "-f" flag to daemon(8) that will do the standard I/O redirection, so I think it is normal and proper for daemons to work this way. |
Turns out /dev/null isn't the issue. I was able to run sysadm-server with stdio redirected to null via this command:
note the "-f" was added to the original command. Maybe it's environment variables? |
Here's the environment variables when started under daemon(8):
If I modify the job manifest to set these variables, the job works fine.
|
Here are the default variables currently set by launchd(8) for a different job:
I think for daemons it would be wise to make launchd emit the same variables as daemon(8). |
…on(8) does it on FreeBSD. (Fixes bug #59) Also, stop ignoring SIGCHLD, and restore signal handlers using signal(2).
sysadm goes to 100% CPU when launched by launchd. At first I thought it was signal related, but now I suspect a stray file descriptor. According to truss(1) it's in an infinite loop polling a set of file descriptors. This line is repeated:
Here are the files it has open:
This is possibly related to bug #54
The text was updated successfully, but these errors were encountered: