3 ms·

it's fixing some longstanding bugs with sysvinit Honest question: I've been using sysvinit for a very long time and I have no concept of what those bugs might

• jerven 12y ago
  Simple one PID files. Assume server with lots of processes. Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. etc... Clean unmounting not depending on timeouts to be high enough. etc... Not starting a database before the filesystem with the database files is mounted. etc...
  • bkeroack 12y ago
    > Not starting a database before the filesystem with the database files is mounted. This was solved decades ago with numbered init symlinks: K20postgresql S20postgresql
    • jerven 12y ago
      Don't those correspond to runlevels? I can boot to runlevel 5 and not have all file systems present and working e.g. an NFS filesytem might not be available. So I would say it has been hacked around for decades. Not cleanly solved. But I am not the best informed here so please add more details about how numbered init symlinks guarantee file system being there before a service is started.
    • onedognight 12y ago
      This was solved in the same way that assembly languages are touring complete. It's true, but it's not useful. You need a compiler to output those meaningless numbers. What happens when you install something after booting? Who starts it? On a long running system those files are useless. Which ones have you run? Are they idempotent? Systemd attempts to solve all of these problems and more.
  • jude- 12y ago
    > Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. I created a specialized FUSE filesystem to deal with this. Processes create PID files in it, but when they die, the filesystem automatically removes them. Code: https://github.com/jcnelson/runfs https://github.com/jcnelson/runfs
    • jerven 12y ago
      Nice to see a different solution than cgroups for this The Readme is rather sparse, could you add an example how to use it from a init shell script?
  • justincormack 12y ago
    I still think 64 bit non reused pids are the best long term solution. There are other pid race conditions. (Not having pid files deleted on reboot is a different issue of course). Although the Capsicum model (in FreeBSD, slowly getting into Linux) where you can have file descriptors for processes is another different model.
    • justincormack 12y ago
      (although Posix does I believe require pid_t to be an int which is an issue)