3 ms·

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 ubu

by 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."
      - kaba0 4y ago
        What if the program does install a signal handler, but it has a race condition and enters an infinite loop? What situation does that correspond to from the POV of the OS? Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
- eadmund 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. Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right? This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly. Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
  - kaba0 4y ago
    Please check out my sibling comment on this thread.
- Nursie 4y ago
  > From a theoretical view, why is it a bad thing? Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed. > 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? Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes. > I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone. I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes? > But these are trivially portable OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working. > some manageable breaking changes instead. This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case. They didn't think and things broke. You don't get to paint that as innovation.

by Nursie 4y ago

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."
    - kaba0 4y ago
      What if the program does install a signal handler, but it has a race condition and enters an infinite loop? What situation does that correspond to from the POV of the OS? Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
eadmund 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. Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right? This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly. Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
- kaba0 4y ago
  Please check out my sibling comment on this thread.
Nursie 4y ago
> From a theoretical view, why is it a bad thing? Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed. > 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? Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes. > I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone. I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes? > But these are trivially portable OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working. > some manageable breaking changes instead. This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case. They didn't think and things broke. You don't get to paint that as innovation.