3 ms·

Sounds like you had junior admins at best leading your university's *NIX department. A mid-level admin in 1995 could have easily made a 100 line script to kill

by TA0x0 6y ago

Sounds like you had junior admins at best leading your university's *NIX department. A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever). systemd brought nothing to this arena.

cycloptic 6y ago
I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.
- TA0x0 6y ago
  The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.
  - cycloptic 6y ago
    If you already had that feature then you are free to use your 25-year-old solution instead of systemd.
    - TA0x0 6y ago
      You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.
      - cycloptic 6y ago
        I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. Doing "ps | grep" and "killall" is a footgun. You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.
        deleted 6y ago
        [deleted]
        TA0x0 6y ago
        >I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. In certain cases I don't disagree, but systemd does not implement this feature correctly, so using functionality that's easily reviewable from decades past makes sense. If systemd could properly implement the feature, there would be no need for the scripting. >It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. This is hilariously wrong. Lots of UNIX OSes don't even implement the ps suite of tools by using procfs. Even then, there were no race conditions in this use case anyway. >You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this. It's already implemented this way on plenty of UNIXen. ps and kill is the POSIX portable way to approach this, so you're wrong about that as well. Almost everything you said above is incorrect, or misunderstanding basic UNIX.
        cycloptic 6y ago
        If you really want systemd to add this then I'm sure they will look at your feature request or PR. I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error. In my experience BSD-based Unixes get it right and don't use procfs for ps or pkill. They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps. Linux also still does. Try unmounting proc and running ps or kill and see what happens. If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill(). POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned. There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill. This can happen on any Unix and is not some big mystery either. PID reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal. There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
  - Spivak 6y ago
    The functionality of implementing it yourself? But that’s such a useless definition because then all software “provides nothing” since it’s implementation proves that you could have written it yourself. logind is far more robust than any of the janky shell scripts I’ve seen over the years to accomplish this.
    - TA0x0 6y ago
      The functionality to gracefully end long running background processes has been a part of standard killall, pkill, etc. for quite some time. Even then, yes, the functionality of using ps and kill together has existed for 20+ years. Those tools are already implemented, providing the functionality for decades. In no universe is logind considered robust, and basic scripts from middling UNIX admins have provided this functionality for decades, untouched. Even the "janky" ones.
      - cycloptic 6y ago
        See my comment below. These tools are fundamentally broken for this use case and have never provided the functionality needed. Bash scripts are not a process manager and it is incredibly wrong to try and make it work like one.
        TA0x0 6y ago
        I responded to the comments below. These tools are not fundamentally broken, you're just ignorant in this space. They have always provided the functionality needed. Scripting can easily manage processes at a higher level, and it's basic functionality to make it work like that.

by TA0x0 6y ago

cycloptic 6y ago

I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.

TA0x0 6y ago
The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.
- cycloptic 6y ago
  If you already had that feature then you are free to use your 25-year-old solution instead of systemd.
  - TA0x0 6y ago
    You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.
    - cycloptic 6y ago
      I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. Doing "ps | grep" and "killall" is a footgun. You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.
      - deleted 6y ago
        [deleted]
      - TA0x0 6y ago
        >I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. In certain cases I don't disagree, but systemd does not implement this feature correctly, so using functionality that's easily reviewable from decades past makes sense. If systemd could properly implement the feature, there would be no need for the scripting. >It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. This is hilariously wrong. Lots of UNIX OSes don't even implement the ps suite of tools by using procfs. Even then, there were no race conditions in this use case anyway. >You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this. It's already implemented this way on plenty of UNIXen. ps and kill is the POSIX portable way to approach this, so you're wrong about that as well. Almost everything you said above is incorrect, or misunderstanding basic UNIX.
        cycloptic 6y ago
        If you really want systemd to add this then I'm sure they will look at your feature request or PR. I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error. In my experience BSD-based Unixes get it right and don't use procfs for ps or pkill. They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps. Linux also still does. Try unmounting proc and running ps or kill and see what happens. If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill(). POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned. There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill. This can happen on any Unix and is not some big mystery either. PID reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal. There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
- Spivak 6y ago
  The functionality of implementing it yourself? But that’s such a useless definition because then all software “provides nothing” since it’s implementation proves that you could have written it yourself. logind is far more robust than any of the janky shell scripts I’ve seen over the years to accomplish this.
  - TA0x0 6y ago
    The functionality to gracefully end long running background processes has been a part of standard killall, pkill, etc. for quite some time. Even then, yes, the functionality of using ps and kill together has existed for 20+ years. Those tools are already implemented, providing the functionality for decades. In no universe is logind considered robust, and basic scripts from middling UNIX admins have provided this functionality for decades, untouched. Even the "janky" ones.
    - cycloptic 6y ago
      See my comment below. These tools are fundamentally broken for this use case and have never provided the functionality needed. Bash scripts are not a process manager and it is incredibly wrong to try and make it work like one.
      - TA0x0 6y ago
        I responded to the comments below. These tools are not fundamentally broken, you're just ignorant in this space. They have always provided the functionality needed. Scripting can easily manage processes at a higher level, and it's basic functionality to make it work like that.