5 ms·

They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want

by usrn 4y ago

They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.

Izkata 4y ago
Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
- Nursie 4y ago
  Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
  - kaba0 4y ago
    From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
    - usrn 4y ago
      Sighup already does this by default. You have tools like nohup and tmux that explicitly (as in, you won't do it accidentally) get around this and systemd breaks those. What bit me last time was running apt upgrade in tmux (I always do this so it doesn't get killed) and I came back to find that apt had been killed. There wasn't any good reason to change this. >hur dur why depend on evil systemd Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though. And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
      - kaba0 4y ago
        No, nohup and tmux are not explicit at all, they simply ignore the signal. The OS has no way of knowing whether it is a frozen process, or one that wants to run in the background. If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them. I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
        usrn 4y ago
        If you don't install a signal handler the process gets killed frozen or not. The only reason you would ever handle the hup signal is if you want exactly this behavior (user deciding when to terminate the process rather than the OS.) Give me one singular example where this isn't the case. >I recommend No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows. >That's on them No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."

by usrn 4y ago

They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.

Izkata 4y ago

Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.

Nursie 4y ago
Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
- kaba0 4y ago
  From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
  - usrn 4y ago
    Sighup already does this by default. You have tools like nohup and tmux that explicitly (as in, you won't do it accidentally) get around this and systemd breaks those. What bit me last time was running apt upgrade in tmux (I always do this so it doesn't get killed) and I came back to find that apt had been killed. There wasn't any good reason to change this. >hur dur why depend on evil systemd Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though. And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
    - kaba0 4y ago
      No, nohup and tmux are not explicit at all, they simply ignore the signal. The OS has no way of knowing whether it is a frozen process, or one that wants to run in the background. If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them. I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
      - usrn 4y ago
        If you don't install a signal handler the process gets killed frozen or not. The only reason you would ever handle the hup signal is if you want exactly this behavior (user deciding when to terminate the process rather than the OS.) Give me one singular example where this isn't the case. >I recommend No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows. >That's on them No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."