5 ms·

The RC system was simple, I'll give you that. I love not having to track down pid files. I love not having to check if the pid file contents match a valid inst

The RC system was simple, I'll give you that. I love not having to track down pid files. I love not having to check if the pid file contents match a valid instance of the expected binary. The RC system was simple and also full of exceptions and corner cases.

tluyben2 5y ago
What is the use case for that? I never had these needs on servers. Maybe you are doing something very different from me, so I am curious. I use RC on servers and systemd on clients; things run robustly for 15+ years on many servers for me (with security updates included).
- fullstop 5y ago
  Let's say that you're starting Apache Tomcat. You have to dig into the tomcat startup scripts and figure out where, if anywhere, it writes the pid file to disk so that you can later use it to determine if the process is running or not. If java happened to crash, though, this pid file is stale and might not point to a valid process. There's a chance that the pid has been reused, and it could have been reused by anything -- even another java process! This is important, because this pid file is used to determine which process receives the kill signal. If you get it wrong, and have the right permissions, you can accidentally kill something that you did not intend to kill. This is further complicated if you want to run multiple instances of Tomcat because now you need to have a unique path for this pid file per tomcat instance. If the thing that you're trying to run doesn't fork, you then have to execute it in the background and then store the result of $! somewhere so that you know how to kill the process later on. It's all very error prone and the process for each daemon is often different.
  - herpderperator 5y ago
    > Let's say that you're starting Apache Tomcat. You have to dig into the tomcat startup scripts and figure out where, if anywhere, it writes the pid file to disk so that you can later use it to determine if the process is running or not. https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html https://tomcat.apache.org/tomcat-8.5-doc/windows-service-how... The commandline argument is --PidFile and --LogPath. Most, if not all, programs allow you to customise this. It should never be a guessing game, especially when you are the one creating the init file, therefore you are the one in control of the running program.
    - fullstop 5y ago
      Those arguments are for the Windows service and don't appear to have a corresponding Linux option. On the Linux side, if things are still done the same way as they were in the past, you had to set CATALINA_PID before starting the java process. It's still a guessing game, though, even with CATALINA_PID. It is entirely possible for Java to crash (something which RC scripts do not handle, at all) and another java process starting up which happens to be assigned the same process id as the dead java process. This can not happen with systemd units because each service unit is its own Linux cgroup and it can tell which processes belong to the service.
      - toast0 5y ago
        You could just run every daemon in its own jail. You don't need to chroot (unless you want to), and don't need to do any jail specific network config (unless you want to), but you could use the jail name to ensure no more than one tomcat (or tomcat-config) process, and you could use the jail name/id to capture process tree to kill it without ambiguity. With respect to servers that crash, approaches differ, but you could use an off the shelf, single purpose daemon respawner, or you could change the whole system, or you could endeavor to not have crashing servers, such that if it crashes, it's worth a human taking a look.
        throwawaysysd 5y ago
        Sure, you can do all that and set it up manually. I'd love to be corrected here but last I checked this was not done automatically in any BSD. Systemd recognizes this is so common that it does it automatically for every service using the Linux equivalent (cgroups). IMO now that we have these tools, every sysadmin is always going to want to use cgroups/jails for every service all the time and never want to use pidfiles because pidfiles are tremendously broken, error-prone and racy.
        _0w8t 5y ago
        Even with systemd one may need to deal with pid files for services with more than one process. Systemd has heuristics to detect the main process to send the kill signal or detect a crash, but it can guess wrong. Telling it the pid file location makes things reliable. Plus creation of a pid file serves as a synchronization point that systemd uses to know that the process is ready. The latter is useful when the service does not support systemd native API for state transition notifications. And the best thing is that even if systemd has to be told about pid files, one never needs to deal with stalled files or pid reuse. Systemd automatically removes them on process shutdown.
  - trasz 5y ago
    Your description is fine, but it’s missing one crucial detail: it’s specific to Linux. In FreeBSD this is already taken care of by rc infrastructure; there is no need for the user or sysadmin to mess with it.
    - fullstop 5y ago
      I fully agree that it is a Linux only solution, but that's kind of the topic here. This still doesn't handle restarting crashed services, and it still is true if you need to make init scripts for your own services outside of the ports tree. It took me a long time to come to terms with systemd, but I am very glad that I did. For me it makes defining services both easy and reliable.
      - trasz 5y ago
        Not the solution - the problem is specific to Linux. In FreeBSD pidfiles are something taken care of a decade ago, you don’t need to think about them.
        fullstop 5y ago
        We're almost in agreement -- FreeBSD does handle pidfiles better and more uniformly than Linux does. It doesn't help you if you want to run two instances of the same service. I looked at one of my FreeBSD servers to see how it was handled in the case of ZNC, an IRC bouncer that I use. ZNC doesn't produce a pid file on startup, so the FreeBSD RC framework tries to find a matching process in the output of 'ps'. [1] As soon as you attempt to run multiple instances of a given service, this falls over completely. [1] daemon(8) helps -- it handles restarting of processes if they crash, and it can manage pid files and prevent them from getting stale. Nothing on my FreeBSD system uses it. The unbound (dns cache) port uses the pidfile option for rc.subr(8). Looking at how check_pidfile is implemented, it attempts to verify that the process represented by the pidfile matches the process name. Pids also wrap on FreeBSD, so you have a chance of a false positive match if you run multiple instances of a given daemon. I could, of course, change unbound's rc scripts to use daemon, but that feels like a lot of thinking about pidfiles for something that was taken care of a decade ago. I do like FreeBSD, don't get me wrong, and I use it in my every day life. systemd solves problems for me, and I really like the way it manages process groups by utilizing kernel features. 1. https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daemon 2. https://unix.stackexchange.com/questions/503150/rc-scripts-for-multiple-zope-instances-in-freebsd
- Spivak 5y ago
  You have to do it for correctness. Every use case needs this handled. Okay so you have a PID file somewhere /var/myservice/myservice.pid. The contents of that file is a number which is supposed to correspond to a process you can find in proc. But PIDs are recycled or more likely your PID files didn't get cleaned up on reboot. So you look at your file and it says 2567, you look up 2567 and see a running process! Done right? Well it just so happenes that a random other process was assigned that PID and your service isn't actually running. pidfd's are the real real solution to this but the short and long tail of software uses pidfiles.
  - capitainenemo 5y ago
    How about keeping pidfiles on tmpfs mounts so they do get cleaned up? I guess that'd be an organisational thing to get all the apps to change to a consistent /var/tmp so you could mount it..
    - fullstop 5y ago
      That's still not good enough. pids wrap and eventually it could point to something valid, especially on a busy system. systemd uses linux cgroups so that it knows exactly which pids belong to the group. The defaults have surely changed over the years, but pid_max used to be ~32K by default. On the system I'm typing this comment on, /proc/sys/kernel/pid_max is set to 4194304.
      - cesarb 5y ago
        > The defaults have surely changed over the years, but pid_max used to be ~32K by default. On the system I'm typing this comment on, /proc/sys/kernel/pid_max is set to 4194304. The commit which changed the defaults is this one: https://github.com/systemd/systemd/commit/45497f4d3b212307569fc06bdab6a35a3e2dab07 https://github.com/systemd/systemd/commit/45497f4d3b21230756...
      - lmm 5y ago
        How does systemd make sure it never reuses a cgroup, OOI? If you're worried about PIDs wrapping, surely that applies to anything randomly-generated as well.
- znpy 5y ago
  Your nice shell-scripts in /etc/rc.d just won't handle a service crashing for any reason, at all (systemd does that) Your nice shell-scripts in /etc/rc.d will start EVERYTHING and ANYTHING just in, case, even if you don't always need it (systemd does support socket activation) Your nice shell-scripts can't handle parallelism (systemd can) Your nice shell-scripts can't reorder stuff at boot, you have to specify it by hand (systemd can via Needs/RequiredBy etc) Your nice shell-scripts are worthless if you need to run more than one instance of a service per server (with systemd having many instances of the same service is a feature, not an after-thought) Your nice shell-scripts won't help you troubleshoot a failing service (systemd will, via systemctl status AND journalctl).
  - folmar 5y ago
    SysV-RC handles all that apart from socket activation, which is the job of inetd. This is all before systemd. I must say that now it has more features and the configuration format, while could be simpler, is way better than sysvrc magic comments. I'd suggest it should be XML with a simple config file equivalent for simple cases, as the subtree update in YAML-like is a hell anyway.
  - inkyoto 5y ago
    Service restart has been a solved problem in UNIX for over 40 years. It is called inetd. It is not perfect, and it was originally created for a slightly different operating model, but it does restart crashed «services». They are, in fact, called daemons. Shell scripts are for manual service starts, stops and restarts (when the daemon does not support a restart on SIGHUP), they are not meant for the automated service restarts. Different UNIX systems have gone on to replace inetd to address specific shortcomings of the inetd model with launchd, service management facility, systemd, SAM, but the service restart is not an innovation that systemd has brought along. It is a further, fine-grained, improvement over a decade old concept and a tool + ecosystem that has implemented the concept (inetd + rc scripts).
  - anthk 5y ago
    If your service crashes, either your service or your build sucks. OpenBSD does this stuff right. You keep pushing faulty and buggy crap over and over.
ybloviator 5y ago
This speaks more to the issues regarding the "made of many little pieces without coordination" spelled out in the linked post than to using simple scripts for service management. Also the idea that you would have pid files scattered all over instead of /var/run seems like the sort of chaos linux spawns. The *BSD rc systems are robust and rely on a framework that abstracts stuff out, you're never going to be digging in there for a pid file's location.
- fullstop 5y ago
  I looked into how the RC system works on one of my FreeBSD servers. You might be surprised to see how rc.subr does this -- it parses the output of 'ps' to look for the process name and matches it to what's listed in the script. This only works in the simplest of cases. If the script lists a pidfile, it finds that pid and makes sure that the process name of that pid matches what is in the script. You don't need to dig for the pid file's location, I'll give you that, but it's also possible for this robust rc subsystem to kill the wrong process under the right circumstances. My system runs unbound (dns cache), so I looked for its pidfile. It's not in /var/run, but rather wherever it happens to be specified in the config. The default is /usr/local/etc/unbound/unbound.pid. In mainstream Linux distributions, things in /var/run are likely sane if you live in the packaged world. My tomcat example was about adding software outside of the packaged world / ports tree, which is why you would have to track down the pid file to make a service. Given that unbound places its pid file outside of /var/run, which is more chaotic? I like FreeBSD, and I use it daily! I also very much like the features and organization that systemd brings to the table. 1. https://cgit.freebsd.org/ports/tree/dns/unbound/files/unbound.in?id=6eb036d0d6656a72d27b34557ed4bf1feb1cd4f0
rbanffy 5y ago
> The RC system was simple, I'll give you that. A lot of the staying power of Unix is that it's based on a very small set of simple, yet powerful, concepts. RC is one of them.

tluyben2 5y ago

What is the use case for that? I never had these needs on servers. Maybe you are doing something very different from me, so I am curious. I use RC on servers and systemd on clients; things run robustly for 15+ years on many servers for me (with security updates included).

fullstop 5y ago
Let's say that you're starting Apache Tomcat. You have to dig into the tomcat startup scripts and figure out where, if anywhere, it writes the pid file to disk so that you can later use it to determine if the process is running or not. If java happened to crash, though, this pid file is stale and might not point to a valid process. There's a chance that the pid has been reused, and it could have been reused by anything -- even another java process! This is important, because this pid file is used to determine which process receives the kill signal. If you get it wrong, and have the right permissions, you can accidentally kill something that you did not intend to kill. This is further complicated if you want to run multiple instances of Tomcat because now you need to have a unique path for this pid file per tomcat instance. If the thing that you're trying to run doesn't fork, you then have to execute it in the background and then store the result of $! somewhere so that you know how to kill the process later on. It's all very error prone and the process for each daemon is often different.
- herpderperator 5y ago
  > Let's say that you're starting Apache Tomcat. You have to dig into the tomcat startup scripts and figure out where, if anywhere, it writes the pid file to disk so that you can later use it to determine if the process is running or not. https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html https://tomcat.apache.org/tomcat-8.5-doc/windows-service-how... The commandline argument is --PidFile and --LogPath. Most, if not all, programs allow you to customise this. It should never be a guessing game, especially when you are the one creating the init file, therefore you are the one in control of the running program.
  - fullstop 5y ago
    Those arguments are for the Windows service and don't appear to have a corresponding Linux option. On the Linux side, if things are still done the same way as they were in the past, you had to set CATALINA_PID before starting the java process. It's still a guessing game, though, even with CATALINA_PID. It is entirely possible for Java to crash (something which RC scripts do not handle, at all) and another java process starting up which happens to be assigned the same process id as the dead java process. This can not happen with systemd units because each service unit is its own Linux cgroup and it can tell which processes belong to the service.
    - toast0 5y ago
      You could just run every daemon in its own jail. You don't need to chroot (unless you want to), and don't need to do any jail specific network config (unless you want to), but you could use the jail name to ensure no more than one tomcat (or tomcat-config) process, and you could use the jail name/id to capture process tree to kill it without ambiguity. With respect to servers that crash, approaches differ, but you could use an off the shelf, single purpose daemon respawner, or you could change the whole system, or you could endeavor to not have crashing servers, such that if it crashes, it's worth a human taking a look.
      - throwawaysysd 5y ago
        Sure, you can do all that and set it up manually. I'd love to be corrected here but last I checked this was not done automatically in any BSD. Systemd recognizes this is so common that it does it automatically for every service using the Linux equivalent (cgroups). IMO now that we have these tools, every sysadmin is always going to want to use cgroups/jails for every service all the time and never want to use pidfiles because pidfiles are tremendously broken, error-prone and racy.
        _0w8t 5y ago
        Even with systemd one may need to deal with pid files for services with more than one process. Systemd has heuristics to detect the main process to send the kill signal or detect a crash, but it can guess wrong. Telling it the pid file location makes things reliable. Plus creation of a pid file serves as a synchronization point that systemd uses to know that the process is ready. The latter is useful when the service does not support systemd native API for state transition notifications. And the best thing is that even if systemd has to be told about pid files, one never needs to deal with stalled files or pid reuse. Systemd automatically removes them on process shutdown.
- trasz 5y ago
  Your description is fine, but it’s missing one crucial detail: it’s specific to Linux. In FreeBSD this is already taken care of by rc infrastructure; there is no need for the user or sysadmin to mess with it.
  - fullstop 5y ago
    I fully agree that it is a Linux only solution, but that's kind of the topic here. This still doesn't handle restarting crashed services, and it still is true if you need to make init scripts for your own services outside of the ports tree. It took me a long time to come to terms with systemd, but I am very glad that I did. For me it makes defining services both easy and reliable.
    - trasz 5y ago
      Not the solution - the problem is specific to Linux. In FreeBSD pidfiles are something taken care of a decade ago, you don’t need to think about them.
      - fullstop 5y ago
        We're almost in agreement -- FreeBSD does handle pidfiles better and more uniformly than Linux does. It doesn't help you if you want to run two instances of the same service. I looked at one of my FreeBSD servers to see how it was handled in the case of ZNC, an IRC bouncer that I use. ZNC doesn't produce a pid file on startup, so the FreeBSD RC framework tries to find a matching process in the output of 'ps'. [1] As soon as you attempt to run multiple instances of a given service, this falls over completely. [1] daemon(8) helps -- it handles restarting of processes if they crash, and it can manage pid files and prevent them from getting stale. Nothing on my FreeBSD system uses it. The unbound (dns cache) port uses the pidfile option for rc.subr(8). Looking at how check_pidfile is implemented, it attempts to verify that the process represented by the pidfile matches the process name. Pids also wrap on FreeBSD, so you have a chance of a false positive match if you run multiple instances of a given daemon. I could, of course, change unbound's rc scripts to use daemon, but that feels like a lot of thinking about pidfiles for something that was taken care of a decade ago. I do like FreeBSD, don't get me wrong, and I use it in my every day life. systemd solves problems for me, and I really like the way it manages process groups by utilizing kernel features. 1. https://docs.freebsd.org/en/articles/rc-scripting/#rcng-daemon 2. https://unix.stackexchange.com/questions/503150/rc-scripts-for-multiple-zope-instances-in-freebsd
Spivak 5y ago
You have to do it for correctness. Every use case needs this handled. Okay so you have a PID file somewhere /var/myservice/myservice.pid. The contents of that file is a number which is supposed to correspond to a process you can find in proc. But PIDs are recycled or more likely your PID files didn't get cleaned up on reboot. So you look at your file and it says 2567, you look up 2567 and see a running process! Done right? Well it just so happenes that a random other process was assigned that PID and your service isn't actually running. pidfd's are the real real solution to this but the short and long tail of software uses pidfiles.
- capitainenemo 5y ago
  How about keeping pidfiles on tmpfs mounts so they do get cleaned up? I guess that'd be an organisational thing to get all the apps to change to a consistent /var/tmp so you could mount it..
  - fullstop 5y ago
    That's still not good enough. pids wrap and eventually it could point to something valid, especially on a busy system. systemd uses linux cgroups so that it knows exactly which pids belong to the group. The defaults have surely changed over the years, but pid_max used to be ~32K by default. On the system I'm typing this comment on, /proc/sys/kernel/pid_max is set to 4194304.
    - cesarb 5y ago
      > The defaults have surely changed over the years, but pid_max used to be ~32K by default. On the system I'm typing this comment on, /proc/sys/kernel/pid_max is set to 4194304. The commit which changed the defaults is this one: https://github.com/systemd/systemd/commit/45497f4d3b212307569fc06bdab6a35a3e2dab07 https://github.com/systemd/systemd/commit/45497f4d3b21230756...
    - lmm 5y ago
      How does systemd make sure it never reuses a cgroup, OOI? If you're worried about PIDs wrapping, surely that applies to anything randomly-generated as well.
znpy 5y ago
Your nice shell-scripts in /etc/rc.d just won't handle a service crashing for any reason, at all (systemd does that) Your nice shell-scripts in /etc/rc.d will start EVERYTHING and ANYTHING just in, case, even if you don't always need it (systemd does support socket activation) Your nice shell-scripts can't handle parallelism (systemd can) Your nice shell-scripts can't reorder stuff at boot, you have to specify it by hand (systemd can via Needs/RequiredBy etc) Your nice shell-scripts are worthless if you need to run more than one instance of a service per server (with systemd having many instances of the same service is a feature, not an after-thought) Your nice shell-scripts won't help you troubleshoot a failing service (systemd will, via systemctl status AND journalctl).
- folmar 5y ago
  SysV-RC handles all that apart from socket activation, which is the job of inetd. This is all before systemd. I must say that now it has more features and the configuration format, while could be simpler, is way better than sysvrc magic comments. I'd suggest it should be XML with a simple config file equivalent for simple cases, as the subtree update in YAML-like is a hell anyway.
- inkyoto 5y ago
  Service restart has been a solved problem in UNIX for over 40 years. It is called inetd. It is not perfect, and it was originally created for a slightly different operating model, but it does restart crashed «services». They are, in fact, called daemons. Shell scripts are for manual service starts, stops and restarts (when the daemon does not support a restart on SIGHUP), they are not meant for the automated service restarts. Different UNIX systems have gone on to replace inetd to address specific shortcomings of the inetd model with launchd, service management facility, systemd, SAM, but the service restart is not an innovation that systemd has brought along. It is a further, fine-grained, improvement over a decade old concept and a tool + ecosystem that has implemented the concept (inetd + rc scripts).
- anthk 5y ago
  If your service crashes, either your service or your build sucks. OpenBSD does this stuff right. You keep pushing faulty and buggy crap over and over.

ybloviator 5y ago

This speaks more to the issues regarding the "made of many little pieces without coordination" spelled out in the linked post than to using simple scripts for service management. Also the idea that you would have pid files scattered all over instead of /var/run seems like the sort of chaos linux spawns. The *BSD rc systems are robust and rely on a framework that abstracts stuff out, you're never going to be digging in there for a pid file's location.

fullstop 5y ago
I looked into how the RC system works on one of my FreeBSD servers. You might be surprised to see how rc.subr does this -- it parses the output of 'ps' to look for the process name and matches it to what's listed in the script. This only works in the simplest of cases. If the script lists a pidfile, it finds that pid and makes sure that the process name of that pid matches what is in the script. You don't need to dig for the pid file's location, I'll give you that, but it's also possible for this robust rc subsystem to kill the wrong process under the right circumstances. My system runs unbound (dns cache), so I looked for its pidfile. It's not in /var/run, but rather wherever it happens to be specified in the config. The default is /usr/local/etc/unbound/unbound.pid. In mainstream Linux distributions, things in /var/run are likely sane if you live in the packaged world. My tomcat example was about adding software outside of the packaged world / ports tree, which is why you would have to track down the pid file to make a service. Given that unbound places its pid file outside of /var/run, which is more chaotic? I like FreeBSD, and I use it daily! I also very much like the features and organization that systemd brings to the table. 1. https://cgit.freebsd.org/ports/tree/dns/unbound/files/unbound.in?id=6eb036d0d6656a72d27b34557ed4bf1feb1cd4f0

rbanffy 5y ago

> The RC system was simple, I'll give you that. A lot of the staying power of Unix is that it's based on a very small set of simple, yet powerful, concepts. RC is one of them.