Handle both daemonizing and foreground programs

[EvanKrall]

Some programs can daemonize themselves, some can't. This often makes a difference in how your init script should look. For example:

• Under Upstart, a program that daemonizes itself should either specify expect fork or expect daemon, depending on how many times it forks. If it runs in the foreground, neither should be specified.
• Under systemd, a daemonizing program should specify Type=forking, a foreground program would want Type=simple

• Launchd really hates programs that fork themselves:

  A daemon or agent launched by launchd MUST NOT do the following in the process directly launched by launchd:

  • Call daemon(3).
  • Do the moral equivalent of daemon(3) by calling fork(2) and have the parent process exit(3) or _exit(2).

• Sysv styles (sysv_redhat, sysv_debian) generally expect programs to daemonize themselves, and will need special attention for foreground programs

One thought is to provide a flag daemonizing or forking or something, indicating whether / how many times the daemon forks; then the init script templates could write out appropriate configs.

Another thought is to provide two command arguments: foreground_command and daemon_command. Since many programs are capable of daemonizing themselves or remaining in the foreground with a command line flag, it may be better to let the templates for each init style pick the command that is most appropriate. (i.e. foreground_command for upstart or systemd, daemon_command for sysv_*. I think this would require very similar complexity to the previous option (it'd probably be one if/else either way) but would let us create more idiomatic init scripts.

[hashbrowncipher]

I vote we do "One thought..."

I think also that this module is the right place to provide the requisite "special attention" for SysV init styles that need forking.

[EvanKrall]

I think both options will be pretty similar:

<% if @forking %>
<%= @command.shelljoin %>
<% else %>
<%= @command.shelljoin %> &
<% endif %>

Versus

<% if @background_command %>
<%= @background_command.shelljoin %>
<% else %>
<%= @foreground_command.shelljoin %> &
<% endif %>

[solarkennedy]

I vote that this thing only support foreground commands and when the module knows it needs to fork (for sysvinit), it forks.

Supporting daemon or forking in sysv is going to make it very dificult to track pids outside of our control, which is going to make status not work.

At the very least, YAGNI until there is actually a program that you find that needs this module and has no way to run in the foreground? (haproxy?)

[EvanKrall]

Most things know how to run in the foreground, I agree, but some don't know how to background.

For the programs that do know how to daemonize, we'll be able to produce more idiomatic init scripts. (If the program knows how to daemonize, why would you tell it to run in the foreground and then background it from the script?)