Hacker News new | ask | show | jobs
by TA0x0 2237 days 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.

1 comments

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.
The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.
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.

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.

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.
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.
If you already had that feature then you are free to use your 25-year-old solution instead of systemd.
You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.
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.
>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.