3 ms·

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. Hon

by dekhn 2y ago

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.

lgas 2y ago
`inetd` was an early attempt at avoiding every process having to write their own daemonization code.
- PaulDavisThe1st 2y ago
  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.
  - erik_seaberg 2y ago
    I thought inetd let you conserve memory because rarely-used daemons don't need to run continually.
matheusmoreira 2y ago
This is the process advocated in this wiki: https://mywiki.wooledge.org/ProcessManagement 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.
- dekhn 2y ago
  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.
  - matheusmoreira 2y ago
    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.

by dekhn 2y ago

lgas 2y ago

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

PaulDavisThe1st 2y ago
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.
- erik_seaberg 2y ago
  I thought inetd let you conserve memory because rarely-used daemons don't need to run continually.

matheusmoreira 2y ago

This is the process advocated in this wiki: https://mywiki.wooledge.org/ProcessManagement 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.

dekhn 2y ago
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.
- matheusmoreira 2y ago
  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.