7 ms·

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it de

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.

Spivak 6y ago
You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.
- 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.
- anilakar 6y ago
  While it's a valid argument, it's also a prime example of a special case that should not be the default - especially so because in my university, people were instructed to use the Linux workstations remotely for long-running tasks.
mbreese 6y ago
I don’t know if these even exist anymore, but I’m imagining a class that meets in a room of workstations. Students can login to any workstation in the room. In this kind of shared environment, you may not want to have a student start a screen session and use the resources of a workstation when they logout. They could be sucking up cpu time from the next person to log in (from the next class). It’s a scenario that might make sense here. But then again, having a watchdog script just kill leftover processes has been doing this same job for forever. Including this use case in systemd seems like overreach.
- dooglius 6y ago
  Yeah, these still exist, though they're becoming more rare. I think what you actually want though is for processes to be killed at the end of class/lab period (even then, I think this should be done by students manually to avoid losing unsaved work). For example, say a student is running some big batch job as part of a lab. Now, if he wants to, say, go to the bathroom or go to the whiteboard to consult with other students, he has to either leave the computer unlocked (possibly leaving neighbors access to private student account data) or kill the running job.
- throw0101a 6y ago
  > It’s a scenario that might make sense here. Perhaps. I have worked half my career in academia & research, going back to when Solaris (SPARC) workstations were a thing, and this was never a problem.

Spivak 6y ago

You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.

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.
anilakar 6y ago
While it's a valid argument, it's also a prime example of a special case that should not be the default - especially so because in my university, people were instructed to use the Linux workstations remotely for long-running tasks.

mbreese 6y ago

I don’t know if these even exist anymore, but I’m imagining a class that meets in a room of workstations. Students can login to any workstation in the room. In this kind of shared environment, you may not want to have a student start a screen session and use the resources of a workstation when they logout. They could be sucking up cpu time from the next person to log in (from the next class). It’s a scenario that might make sense here. But then again, having a watchdog script just kill leftover processes has been doing this same job for forever. Including this use case in systemd seems like overreach.

dooglius 6y ago
Yeah, these still exist, though they're becoming more rare. I think what you actually want though is for processes to be killed at the end of class/lab period (even then, I think this should be done by students manually to avoid losing unsaved work). For example, say a student is running some big batch job as part of a lab. Now, if he wants to, say, go to the bathroom or go to the whiteboard to consult with other students, he has to either leave the computer unlocked (possibly leaving neighbors access to private student account data) or kill the running job.
throw0101a 6y ago
> It’s a scenario that might make sense here. Perhaps. I have worked half my career in academia & research, going back to when Solaris (SPARC) workstations were a thing, and this was never a problem.