4 ms·

Unix is kind of crap with process management. That doesn't even begin to cover the issues. Eg, PIDs may be quickly reused, so having a PID is no guarantee that

Unix is kind of crap with process management. That doesn't even begin to cover the issues. Eg, PIDs may be quickly reused, so having a PID is no guarantee that you're going to send a signal to the right process. Signals suck. Handles get passed to children, which can cause weird issues. Information about processes is racy -- if you want to know something about a process you have to look in /proc, and you could have that data disappear if the process exits, or get replaced with a different one mid-execution. On a higher level, things aren't much better. Bash is a constant annoyance if you want to actually accurately pass arguments to commands, and not have things break from an extra space. What surprises me the most is that until systemd there was very little effort made to improve the situation. You'd think that after decades and thousands of init scripts dealing with the same PID file nonsense and other things that go in init scripts often in buggy ways somebody would think that a fix is needed, but no, it took until 2010.

gavinhoward 3y ago
systemd was hardly the only one working on the problem. It was actually not even first. It just won. And it's still not ideal. Not even close.
- dale_glass 3y ago
  It's not ideal, but it's the best solution I know of. systemd actually went for as complete of a redesign as it could. Rather than just patch one issue up it tried to improve almost everything at once. Which is a fresh approach compared to what we've had before -- every distro having their own flavor of SysV helper scripts, which only do part of the job and all slightly differently.
  - gavinhoward 3y ago
    Other projects tried to do that too. And before systemd. The unfortunate lesson of systemd is that playing politics will help you win over your competitors.
    - dale_glass 3y ago
      > Other projects tried to do that too. And before systemd. Which ones you mean? > The unfortunate lesson of systemd is that playing politics will help you win over your competitors. The way I see it, systemd knew who the "customers" were. Not so much normal end-users, as distro maintainers. It heavily appealed to people sick of writing hundreds of init scripts
jcranmer 3y ago
pidfd does a bit to help with various PID issues, but obviously it's nowhere near a complete solution. A better solution that would fix much more things is if the various syscalls that affected process attributes let you change those attributes on another process. Then you could have just a simple syscall that was "make new process with exe, argv, envp, and immediately put in stop phase before executing", and you could use the other syscalls to modify what you needed to before letting it start running via init. Basically like posix_spawn, but instead of having to enumerate all the stuff you want to do to the process before spawning it, you can do that at your leisure before telling it to start running. > On a higher level, things aren't much better. Bash is a constant annoyance if you want to actually accurately pass arguments to commands, and not have things break from an extra space. It seems to me that the Unix answer to this was "having spaces in arguments is clearly a user bug, what's wrong with you?"

gavinhoward 3y ago

systemd was hardly the only one working on the problem. It was actually not even first. It just won. And it's still not ideal. Not even close.

dale_glass 3y ago
It's not ideal, but it's the best solution I know of. systemd actually went for as complete of a redesign as it could. Rather than just patch one issue up it tried to improve almost everything at once. Which is a fresh approach compared to what we've had before -- every distro having their own flavor of SysV helper scripts, which only do part of the job and all slightly differently.
- gavinhoward 3y ago
  Other projects tried to do that too. And before systemd. The unfortunate lesson of systemd is that playing politics will help you win over your competitors.
  - dale_glass 3y ago
    > Other projects tried to do that too. And before systemd. Which ones you mean? > The unfortunate lesson of systemd is that playing politics will help you win over your competitors. The way I see it, systemd knew who the "customers" were. Not so much normal end-users, as distro maintainers. It heavily appealed to people sick of writing hundreds of init scripts

jcranmer 3y ago

pidfd does a bit to help with various PID issues, but obviously it's nowhere near a complete solution. A better solution that would fix much more things is if the various syscalls that affected process attributes let you change those attributes on another process. Then you could have just a simple syscall that was "make new process with exe, argv, envp, and immediately put in stop phase before executing", and you could use the other syscalls to modify what you needed to before letting it start running via init. Basically like posix_spawn, but instead of having to enumerate all the stuff you want to do to the process before spawning it, you can do that at your leisure before telling it to start running. > On a higher level, things aren't much better. Bash is a constant annoyance if you want to actually accurately pass arguments to commands, and not have things break from an extra space. It seems to me that the Unix answer to this was "having spaces in arguments is clearly a user bug, what's wrong with you?"