
You don't need to daemonize - vezzy-fnord
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/daemonize.html
======
scurvy
We still run daemontools even in systemd systems. The OS packaged cruft runs
in systemd. Everything important runs in daemontools. Still the best "services
manager" out there.

~~~
otterley
Why? It's no longer necessary.

Also, daemontools suffers from the same problem as other non-systemd service
managers; it can't manage processes that daemonize themselves for good reason
(like nginx or Unicorn). systemd can handle it because it creates a unique
cgroup for every service; if the service needs to be stopped, all processes in
the cgroup are terminated.

~~~
scurvy
We run both nginx and unicorn through daemontools. Both have options to
prevent daemonization.

Why run something terrible (systemd) when we already have something that works
really well (daemontools)?

~~~
KirinDave
> Why run something terrible (systemd)

It is terrible only because you say it is. It's been a massive help for us in
adopting it, and accepting the help it offers makes custom software systems a
lot easier to write in a robust way.

It's only "terrible" if you have axe to grind about the "right" way and then
define that as daemontools.

~~~
scurvy
I have an axe to grind about the way it was introduced. Fedora and Red Hat
massively mis-managed it. Previously, they introduced various things in tech
preview releases, and it either stayed or went with subsequent releases.

systemd was thrust upon us by an axe-grinding developer.

~~~
rodgerd
So, stupid politics rather than technical merit.

------
joshribakoff
I've used the python package supervisord with good success. Out of the box it
manages stdout & stderr, rotates log files, restarts crashed processes, and
has plugins for things like REST APIs to restart the process (for example,
during an automated deploy). Another plugin can monitor memory usage & take
some action when thresholds are reached. I find it very easy to use. You can
commit your configuration file for supervisor into your app's repo, and
symlink it in to supervisor's conf.d directory. Other plugins add stuff like
web based dash boards. Its great for everything from managing a single process
on a single machine, or a large cluster of worker processes on multiple
servers.

~~~
kzahel
I like supervisord for these reasons too. It's really handy.

------
ah-
Seeing then FQDN with the trailing dot I wonder how much software breaks when
you use it. I bet the duplicate check here doesn't treat
homepage.ntlworld.com. and homepage.ntlworld.com as equal.

~~~
vezzy-fnord
JdeBP is famous for his ungodly pedantry, so it'd be blasphemous for me not to
honor RFC 1738 [1].

[1]
[http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/we...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/web-
fully-qualified-domain-name.html)

~~~
bshimmin
He's also famous enough that whenever I see ntlworld.com [1] I immediately
think, "Ah, must be JdBP - that'll be worth reading."

[1] It's actually slightly astonishing his hosting still works at that URL
given that NTL was consumed by Virgin nearly a decade ago.

~~~
darkr
I must admit, I felt a pang of nostalgia seeing that domain name. Must have
been nearly 15 years ago that we got our super-fast 64k connection with free
ntlworld.com web hosting, and we could finally have always-on internet at
home. Oh how things have changed..

------
lealanko
The problem with automatic daemonization is that there is no way to indicate
startup failure: you just fire and forget the process in the background. If
the process dies, there's no clear way of knowing whether it was due to an
error in startup conditions (possibly as simple as a configuration error) or a
runtime failure at a later time. In the first case, restarting makes no sense.
In the latter case it might be a reasonable option.

With manual daemonization, the process can delay forking until it has ensured
that its configuration is sound and it has the resources it needs. This way
the parent process can indicate with its exit status whether the service was
successfully launched.

~~~
twic
If the program exits with a special status to indicate non-restartable
failure, you could, in principle, recognize that in the process manager and
handle it differently, by not restarting. Is there any way to do this in
systemd, or in any other process manager?

~~~
icebraining
Yes, systemd has "RestartPreventExitStatus" to configure a list of exit codes
which prevent the automatic restart.

~~~
digi_owl
Was there not a recent blog/article that mused about the likelihood of systemd
spawning all manner of special case entries?

And now i ponder likening systemd with CISC...

------
pjungwir
For Rails apps I've been using god to manage unicorn and delayed_job/resque
processes in recent years. I've been mildly skeptical of systemd---not really
out of true knowledge but because keeping things simple matters to me, and
that seems to be the gist of the criticisms. But if systemd would let me do
away with god, that would be nice! I agree that pidfiles are a hack and often
cause problems. It seems like I'm going to need to learn systemd soon anyway,
so I'll be looking into whether it can do what I need for Rails apps.

------
snorkel
I don't understand. If I write a server app that listens for client
connections, why not daemonize that? Is systemd doing all of the listening
then invoking the server app if a client connects?

~~~
ninkendo
Run in the foreground and systemd will do the right thing.

Your app is still the one listening for connections, systemd just calls wait()
until you exit, then launches you again.

There's no need for you to do a fork() or setsid() or whatever, that was a
relic of the "just run all these init files as scripts" nature of sysv init.

~~~
joevandyk
How does that work with nginx or haproxy, which support zero-downtime
restarts?

~~~
ninkendo
That's a really interesting question, actually. (This was posted a day ago so
I'm not sure anyone will read this any more, but...)

If the job of a process "supervisor" is to launch you, wait(2), launch you
again, repeat... who has the role of doing zero-downtime restarts?

I'll define a zero-downtime restart in this instance as: a new process must be
launched while the old process is still running, so it can negotiate a handoff
of responsibility (via migrating who owns the port and draining connections in
the case of nginx or haproxy), and the old process only dies once the handoff
is complete.

If you wanted this behavior with systemd/upstart/etc as a supervisor (where
processes are foregrounded and monitored), the supervisor would require a
special case for "restart" which would just start a new process and monitor
that one instead, and not bother with killing the old one.

I have no idea if systemd can accommodate for this without switching to a non-
supervised process management mode (which is definitely possible.) I don't
have much familiarity with advanced systemd or upstart, although I have plenty
of familiarity with mesos schedulers, which can be kind of a datacenter-level
version of systemd, and in this instance we do "rolling restarts" where new
instances are launched, we wait for them to pass health checks, and then we
drain the old ones, while a load balancer is responsible for routing incoming
connections to the healthy instances. It's an interesting notion for what a
single machine's process supervisor should do in this case.

------
jebblue
I wrote a Java server that blocks spam based on my criteria and set it to run
like this:

[http://manpages.ubuntu.com/manpages/trusty/man8/update-
rc.d....](http://manpages.ubuntu.com/manpages/trusty/man8/update-rc.d.8.html)

I didn't do any daemonzing like we used to do in the C days so I'm not sure
that the systemd approach mentioned in the article does it better (not against
the idea, maybe it's needed on non-Ubuntu systems?).

I just needed to write a simple shell script with the basics and this:

...

    
    
      case "$1" in
          start)
              startup
          ;;
          stop)
              shutdown
          ;;
          restart)
              restartit
          ;;
      esac
    

...

~~~
fbuilesv
If all you're doing is start/stop/restart on Ubuntu you should take a look at
Upstart[0]. See a simple example here:
[http://askubuntu.com/a/251581](http://askubuntu.com/a/251581)

[0] [http://upstart.ubuntu.com/](http://upstart.ubuntu.com/)

~~~
hactually
upstart is deprecated.

~~~
vezzy-fnord
Not that I know of. ChromeOS still uses it and though Ubuntu is phasing it
out, they haven't completely gotten rid of it as a session manager yet AFAIK.
They need to support it for a few more years anyway due to 14.04 LTS.

~~~
hobarrera
That's exactly the difference between deprecated an obsolete. The former means
it's on it's way to the latter. Putting work into upstart just means you'll
have work migrating to systemd in less than a year or two.

------
quicksilver03
I tend to always use daemonize to start a Java program because typically I
need to pass several startup options (like Xms, Xmx, etc.) and systemd unit
files cannot perform even the simplest variable interpolation needed [1].

Someday systemd will go beyond simple key-value substitution, and on that day
I'll stop using daemonize.

[1]: [http://www.opsfordevelopers.com/2015/05/startup-scripts-
for-...](http://www.opsfordevelopers.com/2015/05/startup-scripts-for-java-
based-services/)

~~~
hactually
What's wrong with doing something like the following:

...

[Service]

Type=forking

EnvironmentFile=-/usr/local/myJavaConfig

ExecStart=/bin/sh -c '${JAVA_HOME} ${JAVA_OPTS}'

Or if you're after passing things in, use the other technique that lets you
use systemctl myservice@your_sub.service

~~~
JdeBP
Two things are wrong, neither of which, however, make daemonize appropriate.
First, and trivially, there's a missing /bin/java (-: Second, that's a
potential readiness protocol and a main PID mismatch. See
[http://unix.stackexchange.com/a/200365/5132](http://unix.stackexchange.com/a/200365/5132)
for details. And then
[http://askubuntu.com/a/624871/43344](http://askubuntu.com/a/624871/43344) .
Remembering to exec is another lesson to bring along from the daemontools
world.

------
kazinator
You can run a daemon-like process with its stdin/out firmly attached to a TTY:
a virtual TTY inside a screen or tmux session that can be detached and
reattached.

~~~
Animats
As was pointed out a few days ago, if the output stream exerts backpressure,
write calls will stall. Stopping scrolling at the output end is enough to do
that.

~~~
__david__
But that's the whole point of screen and tmux—It's always got a terminal to
suck up stdout.

------
__david__
I've been using daemon-manager for the past couple years—its most interesting
point to me is that you can start and stop user daemons without require root
privileges, which make it nice for non-root scripts/bots (for the paranoid
age) and for multi-user systems (admittedly decreasingly common in the AWS and
Docker age).

~~~
icebraining
"systemd offers users the ability to manage services under the user's control
with a per-user systemd instance, enabling users to start, stop, enable, and
disable their own units."

[https://wiki.archlinux.org/index.php/Systemd/User](https://wiki.archlinux.org/index.php/Systemd/User)

