4 ms·

Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and commu

by gnoway 10y ago

Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team. Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention. Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.

madmax96 10y ago
I think people are upset because we're creating a lot of technical debt here. Every new "feature" we add creates a larger learning curve, makes a system that much more complex, and adds more to our maintenance costs. A simple and modular system that allows the user to combine easy-to-understand-parts in a succinct fashion to achieve functionality that __meets their requirements__ usually is superior to monolithic one-size-fits-all solutions. In short, composition generally is preferable to monoliths (after a certain point in complexity.) I think most of us agree to this, and I haven't said anything we all don't already know. We just all disagree where that complexity tipping point is, and that's why some of us hate systemd and some of us don't see the problem.
- mgbmtl 10y ago
  Speaking of technical debt, I'm not sure if "nohup as a process management scheme" is a good one. Similar to "screen/tmux as a daemon manager". (I'm not saying tmux is bad, I use it all the time. I just don't use it as a daemon manager -- If I understand correctly, they do provide a way to fix screen/tmux.) Systemd generally tries to standardize how to declare common things about a process: - should it be automatically restarted if it does? at what interval? - where are its logs? - how to tell if the process is alive or not? - can we isolate the process? (tmp files) - and now: should this process continue to run even if the user has logged out? And yep, I'm an old schooler who just got tired of dealing with duct tape solutions.
  - dkuntz2 10y ago
    You don't have to use tmux as a daemon manager to find this change annoying. The way we do development where I work is by having two people ssh into a server, and open a joint tmux session. These sessions generally last a week or more, and you generally log out of ssh daily. Or even if you're not pairing, just being disconnected over lunch is a long enough time for SSH to disconnect. Finding ways to overcome that (besides changing the systemd config) are even more duck tape fixes. Automatically terminating processes when a user logs out is a bad default. Sure, leave it as an option because there might be some people that would find it useful, but changing the default without a good reason is bad policy.
    - mgbmtl 10y ago
      As I said, I'm a huge fan of tmux. I would be concerned if they broke tmux, but it does not seem to be the case. I've seen people run "nohup [program]" and logout, not even run it in a tmux. If systemd killed their program, I would be quite happy about it.
HelloNurse 10y ago
Requiring use of systemd-specific configurations and tools is absurd. People who want to start a long-running process and check on it shouldn't even need to know the computer is running systemd. Straightforward usage of nohup, tmux, and other equally standard and/or portable tools should be the most that a system administrator who wants to kill unwanted background processes requires of end users.
- madmax96 10y ago
  I agree with this. This actually describes a lot of my problems with Docker as well: I __hate__ that I have to use `docker ps`, etc. This is due to a weakness in traditional UNIX architectures. I ran HURD in a virtual machine a while back and it has the solution to this problem: translators. I can't wait until they hit a 1.0 release of HURD.
- gnoway 10y ago
  Well I thought it was obvious, but my reply was intended to be sarcastic. For it to be taken at face value by anyone kind of highlights the problem with the systemd approach, IMO.
  - JdeBP 10y ago
    > Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client. The problem with your sarcasm is that it actually matches current reality. This is how various programs are busily being rearchitected to operate, or indeed already have been rearchitected to operate. Take gnome-terminal, for example. Nowadays, a gnome-terminal-server service runs under the per-user systemd service manager, and requests to open more terminals generated by the gnome-terminal program arrive at it over the per-user Desktop Bus. gnome-terminal is a Desktop Bus client. The gnome-terminal-server service used to be Desktop Bus activated, rather than simply run as a per-user systemd service. Ironically, given the headline on this page, this too hit a problem with a systemd release turning things on a while back. systemd version 228, in fact. All of the terminal emulator processes and the shells and login sessions that they spawned ended up sharing a single 512 maximum threads limit. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129 And yes, gnome-terminal-server too suffered from the kills-screen-and-tmux problem: * https://lists.freedesktop.org/archives/dbus/2015-January/016504.html https://lists.freedesktop.org/archives/dbus/2015-January/016...

by gnoway 10y ago

madmax96 10y ago

I think people are upset because we're creating a lot of technical debt here. Every new "feature" we add creates a larger learning curve, makes a system that much more complex, and adds more to our maintenance costs. A simple and modular system that allows the user to combine easy-to-understand-parts in a succinct fashion to achieve functionality that __meets their requirements__ usually is superior to monolithic one-size-fits-all solutions. In short, composition generally is preferable to monoliths (after a certain point in complexity.) I think most of us agree to this, and I haven't said anything we all don't already know. We just all disagree where that complexity tipping point is, and that's why some of us hate systemd and some of us don't see the problem.

mgbmtl 10y ago
Speaking of technical debt, I'm not sure if "nohup as a process management scheme" is a good one. Similar to "screen/tmux as a daemon manager". (I'm not saying tmux is bad, I use it all the time. I just don't use it as a daemon manager -- If I understand correctly, they do provide a way to fix screen/tmux.) Systemd generally tries to standardize how to declare common things about a process: - should it be automatically restarted if it does? at what interval? - where are its logs? - how to tell if the process is alive or not? - can we isolate the process? (tmp files) - and now: should this process continue to run even if the user has logged out? And yep, I'm an old schooler who just got tired of dealing with duct tape solutions.
- dkuntz2 10y ago
  You don't have to use tmux as a daemon manager to find this change annoying. The way we do development where I work is by having two people ssh into a server, and open a joint tmux session. These sessions generally last a week or more, and you generally log out of ssh daily. Or even if you're not pairing, just being disconnected over lunch is a long enough time for SSH to disconnect. Finding ways to overcome that (besides changing the systemd config) are even more duck tape fixes. Automatically terminating processes when a user logs out is a bad default. Sure, leave it as an option because there might be some people that would find it useful, but changing the default without a good reason is bad policy.
  - mgbmtl 10y ago
    As I said, I'm a huge fan of tmux. I would be concerned if they broke tmux, but it does not seem to be the case. I've seen people run "nohup [program]" and logout, not even run it in a tmux. If systemd killed their program, I would be quite happy about it.

HelloNurse 10y ago

Requiring use of systemd-specific configurations and tools is absurd. People who want to start a long-running process and check on it shouldn't even need to know the computer is running systemd. Straightforward usage of nohup, tmux, and other equally standard and/or portable tools should be the most that a system administrator who wants to kill unwanted background processes requires of end users.

madmax96 10y ago
I agree with this. This actually describes a lot of my problems with Docker as well: I __hate__ that I have to use `docker ps`, etc. This is due to a weakness in traditional UNIX architectures. I ran HURD in a virtual machine a while back and it has the solution to this problem: translators. I can't wait until they hit a 1.0 release of HURD.
gnoway 10y ago
Well I thought it was obvious, but my reply was intended to be sarcastic. For it to be taken at face value by anyone kind of highlights the problem with the systemd approach, IMO.
- JdeBP 10y ago
  > Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client. The problem with your sarcasm is that it actually matches current reality. This is how various programs are busily being rearchitected to operate, or indeed already have been rearchitected to operate. Take gnome-terminal, for example. Nowadays, a gnome-terminal-server service runs under the per-user systemd service manager, and requests to open more terminals generated by the gnome-terminal program arrive at it over the per-user Desktop Bus. gnome-terminal is a Desktop Bus client. The gnome-terminal-server service used to be Desktop Bus activated, rather than simply run as a per-user systemd service. Ironically, given the headline on this page, this too hit a problem with a systemd release turning things on a while back. systemd version 228, in fact. All of the terminal emulator processes and the shells and login sessions that they spawned ended up sharing a single 512 maximum threads limit. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129 And yes, gnome-terminal-server too suffered from the kills-screen-and-tmux problem: * https://lists.freedesktop.org/archives/dbus/2015-January/016504.html https://lists.freedesktop.org/archives/dbus/2015-January/016...