James Berry <jberry@macports.org> writes:
exec: daemondo will remember the pid generated from execution of the .executable or .start command, and will use this to track operation of the daemon. If a pidfile is also specified, then daemondo will also write a pidfile to contain the pid (note that this is only for your sake, as daemondo doesn't need this for its own operation).
exec = manual? The man page (and new docs) use "manual". And I don't understand under which circumstances this option is likely to work. I suppose if remembering pids could be done in all circumstances, we wouldn't need pidfiles at all.
Yes, exec should be "manual". Sorry, I confused myself in mapping between the parameters that daemondo takes, and those that the startupitem.pidfile command takes.
Okay, but I still don't understand under what circumstances (for "manual" pidfiles) a child process that is started could be remembered. It seems like that never happens (when not using .executable) and that is why we use .pidfiles.
I understand that startupitems.executable is preferred and the reason why (due to your previous explanations), but the nedi daemons are perl scripts. I thought startupitem.executable could only be used with compiled commands, and wouldn't work for stuff like perl scripts. If that does work startupitem.executable would be better, and I'd think we'd use it for most everything. As it is, there are few scripts that use statupitem.executables.
The determinant is not whether or not the item is itself a script or a binary (this factor is irrelevant), but whether or not the item to be executed is a process that will continue to run.
Think of it this way:
- If the script/binary that you execute is _the thing_ that you want to keep running, then you may and should use startupitem.executable (daemondo will grab, hang onto, and monitor the process id of the process it starts, even if it's a shell of some sort).
- If the script/binary that you execute is not going to continue to execute, but is going to turn around and launch something else that will continue to run, then use startupitem.start (daemondo won't hang onto the process id of what it starts; to find out what it needs to monitor it really needs to read a pidfile).
And yes, startupitem.executable is sorely under-utilized, probably because people don't understand what it is, or because it's somewhat more difficult to figure out, in many cases, what and how the ultimate executable actually needs to be run. Things would be a lot smoother if .executable was used more.
I get it now. It is different than I thought, so I will use startupitem.executable for nedi. And I'll rewrite the docs to reflect it as I understand it now. It seems very clear to me now after having worked through it and getting your explanations. If I can get this documented fairly well, perhaps you won't need to explain it again later. :) I really appreciate your patience and thoroughness in explaining it all. Mark