Hacker News Reader

Comment by dekhn | Hacker News Reader

I would be totally fine if Unix programs never detached themselves from their invoking terminal/process and that restart was handled by an external system. Honestly, that seems much more consistent with the unix philosophy than having a billion different services all with their own daemonization code.

This belief is mainly because after many years of debugging services, the very first thing I do is run the service outside of the daemon manager, with debugging enabled, so I can strace the process from its beginning.

View on HN

This is the process advocated in this wiki:

https://mywiki.wooledge.org/ProcessManagement

Seems reasonable to me. Restarting processes is just something like this:

  #!/bin/sh
  # service.sh

  while :; do
    /my/service >> /var/log/service 2>&1
  done

  service.sh &

The service is just a normal program. If run directly, the inputs and outputs are attached to the terminal. If not, they're redirected to log files. Programs shouldn't care much what their outputs are connected to. Maybe they should turn off terminal escape codes in the outputs if they're not terminals but that's about it.

This approach has many problems; in particular, it lacks an intelligent backoff. A looping service will get continuously restarted.

It doesn't handle service dependencies. What if I only want my service to run when I'm on network and VPN is disabled?

And I can think of a lot more. All these things have been implemented in init, or in systemd, for decades.

I agree with you. I use systemd myself and think it's great.

It was just an example of how simple things can be when programs don't daemonize. Supervising and managing the processes is systemd's job and it does it well. Daemonizing makes its job harder and is not necessary to begin with.

`inetd` was an early attempt at avoiding every process having to write their own daemonization code.

not really. inetd was an early attempt at avoiding every process dealing with the basics of waiting on a socket for a connection, forking off some process to deal with it and managing the socket and the connection.

inetd waited on "all" the sockets; when a connection came in, it started the configured application to deal with it.

daemonization didn't really figure into it, AFAIR.

I thought inetd let you conserve memory because rarely-used daemons don't need to run continually.

Reply on news.ycombinator.com