8 ms·

You know, because we knew this would be controversial we made sure it was both a compile-time option and a runtime option. Yes the upstream default of both defa

You know, because we knew this would be controversial we made sure it was both a compile-time option and a runtime option. Yes the upstream default of both defaults to on, but that's just upstream. We made it very easy and supported for downstream distros to switch between opt-out and opt-in of this option for their users. We have encouraged distributions to leave it on, but we were fully aware that for compatibility reasons this is something downstreams likely wanted to turn off, and most compat-minded distros did, as we expected. Now I am used to taking blame for apparently everything that every went wrong on Linux, but you might as well blame your downstream distros for this as much you want to blame us upstream about this, as it's up to them to pick the right compile-time options matching their userbase and requirements in compatibility, and if they didn't do that to your liking, then maybe you should complain to them first. (And yes, I still consider it a weakness of UNIX that "logout" doesn't really mean "logout", but just "maybe, please, if you'd be so kind, i'd like to exit, but not quite". I mean, that's not how you build a secure system. We fixed that really, fully knowing it would depart from UNIX tradition, but that's why we made it both compile-time and runtime configurable) (Also, nobody has to "incorporate" systemd's library to avoid the automatic clean-up. In fact, there's no library we provide that could do that. What was requested though is to either run things as child of systemd --user or just register a separate PAM session, neither of which requires any systemd-specific library.) Lennart

tasuki 8y ago
Lennart, thanks for the information. Mind explaining why you chose to kill user processes on logout as the default?
- poettering 8y ago
  I think my comment above explained that already.
  - m4r35n357 8y ago
    They show that you do not understand what "log out" is for in Unix.
  - belorn 8y ago
    I think tasuki is asking you to elaborate a bit further on what kind of security issues you have solved by not using SIGHUP signal. I would personally also like to hear more in-depth details, preferable with some examples of security vulnerabilities that was caused because of that POSIX design choice.
    - poettering 8y ago
      Well, this boils down to: in a modern operating system, is it good design that an unprivileged user who logs in once can consume arbitrary runtime resources uncontrolled, unbounded forever, even after logout just because they decided to mask SIGHUP? I think not, I think the system should default to behaviour where unprivileged processes are clearly lifecycle bound, and when the user's sessions end they end comprehensively. I mean, other OSes don't really allow this unprivileged either, for good reasons: the lifecycle of the unpriv user's processes should be controlled by privileged code, and clearly be defined by the act of logging in and logging out in its lifetime. It's entirely OK if the admin then opts out specific users or even all users from this behaviour, i.e. if a privileged players decides to liberalize unbounded, unlifecycled resource consumption for unprivileged players. But a default where unprivileged code can just stick around uncontrolled and consume as much as it wants forever is just a strange choice security wise. i.e. I think the fact that SIGHUP masking is unrestricted, i.e. is not subject to privilege checks is the problem really. Something is unpriv by default that should be priv by default. And that's pretty much what this option in systemd provides you with.
      - dooglius 8y ago
        > is it good design that an unprivileged user who logs in once can consume arbitrary runtime resources uncontrolled, unbounded forever A unprivileged user can still do this by setting up an intermediary box that keeps a persistent ssh session open. Incidentally, this is exactly what I plan to do if I ever need to ssh into a server with KillUserProcesses=yes. > other OSes don't really allow this unprivileged either On Windows, if I remote desktop from a laptop into a desktop, and start a web server, then shut down the laptop, the server stays running. On iOS if I start drafting an email, and reboot my phone, I don't lose my work. On ChromeOS, my tabs will stick around after a system crash. The world is moving toward processes being _more_ persistent, not less.
majewsky 8y ago
> What was requested though is to either run things as child of systemd --user or just register a separate PAM session When you run your screen or tmux below `systemd --user`, you still would have to `loginctl enable-linger`, no? I remember having to do that when I set up a PulseAudio server on a headless machine where I don't maintain an active session.
vesak 8y ago
You've done great work as a whole, as you probably know. Try not let the lowlifes get to you.
inferiorhuman 8y ago
> Now I am used to taking blame for apparently everything that every went wrong on Linux, but you might as well blame your downstream distros for this as much you want to blame us upstream about this, as it's up to them to pick the right compile-time options matching their userbase and requirements in compatibility, and if they didn't do that to your liking, then maybe you should complain to them first. It's up to you as a systemd developer to pick sane defaults. Claiming that it's okay to introduce opt-out breaking changes upstream and then abdicate responsibility is a quite bit like walking around while waving your hands and arms around and then blaming whoever you hit for walking into you.
- izacus 8y ago
  Killing software that might be running after a valid login session is a sane default.
  - inferiorhuman 8y ago
    And that's what SIGHUP is for. The process will exit by default. If that's not the desired behavior a handler can be registered. Killing things that are explicitly designed to run after logout is a piss poor default.
    - tyingq 8y ago
      This. There's a reason the defacto way to keep running post logout was named "nohup". This wasn't some deep dark unknown secret behaviour that was broken.
      - v_lisivka 8y ago
        Because 1) maintainer can be overloaded, so (s)he will stick to defaults, 2) maintainer needs a logical reason to change default setting to something else, which is not obvious in most cases. Maintainer is not a QA team.
      - zbentley 8y ago
sfilargi 8y ago
Completely agree. The problem is not upstream, but downstream. Distros should have done better job and chosen a better default system manager and not systemd. You build your software the way you want and like. If others don’t like that it breaks POSIX they should stop using it instead of complaining. Or fork it.
inferiorhuman 8y ago
> And yes, I still consider it a weakness of UNIX that "logout" doesn't really mean "logout", but just "maybe, please, if you'd be so kind, i'd like to exit, but not quite". I mean, that's not how you build a secure system. As an aside this is the height of arrogance to suggest that the systemd is somehow a more secure alternative. Lest this be considered an empty ad hominem attack, let me quote the pwnie you won in 2017[1]: > Where you are dereferencing null pointers, or writing out > of bounds, or not supporting fully qualified domain names, > or giving root privileges to any user whose name begins with > a number, there's no chance that the CVE number will > referenced in either the change log or the commit message. > But CVEs aren't really our currency any more, and only the > lamest of vendors gets a Pwnie! 1: https://pwnies.com/archive/2017/winners/#lamestvendor https://pwnies.com/archive/2017/winners/#lamestvendor
- youdontknowtho 8y ago
  You know it's open source and that you could actually get involved? If you submit a pull request and it doesn't get merged you can take your concerns to the the larger group. As to the stuff mentioned in the pwnie. Those sound like great contributions that would be appreciated. You could also take your concerns to the distro development group. If that doesn't work you could also customize your distro with a custom build of systemd. If you still don't get satisfaction you can stop using it. If you dislike how they do thing you have options. Or, you could just be mean on a forum...
- arpa 8y ago
  > giving root privileges to any user whose name begins with > a number https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 oh my god, what a spectacular issue. And, seriously, the Poetterings' response is basically "not my job" and "not a bug". And this person develops something that sits at the core of a modern linux system...
  - inferiorhuman 8y ago
    > oh my god, what a spectacular issue. And, seriously, the Poetterings' response is basically "not my job" and "not a bug". And this person develops something that sits at the core of a modern linux system... All the while Lennart claims that he's making Linux more secure. FFS. Edit: I forgot about this https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and... > He (Theodore Ts’o) goes on to describe how he previously had to neuter policykit’s security (rendering his system very vulnerable) just to get his system working, and how he has found systemd "very difficult sometimes to figure out". And: > As for Kay Sievers, maybe he should rename himself to Kay Sewers, because that’s exactly what he smells of. He told to IETF internet area director and previously DHCP working group co-chair “Tod Lemon” to lmgtfy when he asked about a systemd related git repository. This gem sums it up perfectly though: > Yet just two days ago, we see Linus Torvalds (the creator of Linux and maintainer of the Linux kernel), launching into a tirade against – yes, you guessed it – systemd developers because of their atrocious response to a bug in systemd that is crashing the kernel and preventing it from being debugged. Linus is so upset with systemd developer Kay Sievers (gee, where I have heard that name before – oh, that’s right, he’s the moron who refused to fix udev problems) that Linus is threatening to refuse any further contributions from this Red Hat developer, not just because of this bug, but because of a pattern of this behavior – a problem for Kay because Red Hat is also foaming at the mouth to have their kernel-based, no doubt bug- and security-flaw-ridden D-Bus implementation included in our kernels. Other developers were so peeved that they suggested simply triggering a kernel panic and halting the system when systemd is so much as detected in use.
sametmax 8y ago
For what it's worth, systemd makes my life easier. When I switch distro, it's almost always systemd, and not the system du jour, so I know how it works. Creating service files is a google query away, and makes common use cases a breathe, while advanced features that were hard to bash script yourself into, are now just a few options to type. I understand that many people may have problems with systemd for their particular situation, but that's not my experience. As a dumb user with a few laptops and servers that needs an occassional daemon, I'm glad systemd won. I know you get a lot of heat since it came out, so thank you for working on it.
- nine_k 8y ago
  Sure, systemd solves a number of real problems. This is good. What is not as good: (1) systemd takes over or duplicates functionality not related directly to its primary purpose, and (2) is not solid enough to trust it in a number of cases, while (3) the developers' attitude does not give a lot of hope that the situation will materially improve. (Of course, I run a distro without systemd.)
Asooka 8y ago
So you made the default the worst possible option, because... why exactly? And now that the problem is apparent, you haven't changed the default because...? I don't know what goes through your and the rest of the systemd's team's heads, but good software engineering it is not.
loudtieblahblah 8y ago
>You know, because we knew this would be controversial we made sure it was both a compile-time option and a runtime option. This is standard from you. You knock the glass on the floor and blame the maid service for not cleaning up after you. It's everyone's faults but yours. >And yes, I still consider it a weakness of UNIX that "logout" doesn't really mean "logout", but just "maybe, please, if you'd be so kind, i'd like to exit, but not quite". Oh how hyperbolic. Nuances and caveats in terminology is not a weakness. I don't see why you're splitting hairs over this but can't be bothered to care about your UID numbering bug. Or he fact systemd-resolv is responsible for DNS leaking on VPNs. But yes, tell me more about how a functionality that enables terminal multiplexes is a "weakness" >Now I am used to taking blame for apparently everything that every went wrong on Linux, It's because of your smarmy, arrogance. You break POSIX compliance, which has a real world effect in multiple areas and you accept bug reports with the humility of Donald Trump being interviewed by MSNBC. Then when you retreat into your safe space, you play victim to the situation you created. You talk of Linux culture toxicity, smearing the likes of Linus Torvalds, while essentially being the metaphorical sibling putting your finger in people's face repeating "I'm not touching you" over and over. Then you acted attacked when someone claps back. You're a cry bully hiding behind a vaneer of professionalism acceptable for Red Hat's HR department which enables you to mark one more bug as "wontfix"; your attitude, your arrogance, your conceits that things not broken in fact, are so you can provide solutions no one asked for and no one benefits from.
- ownagefool 8y ago
  To be fair, at least poettering presented an argument and is responsible for software that helps a whole bunch of us get things done. You're just kind of yelling, and it diminishes any point you may have made.
  - zeveb 8y ago
    After awhile, anyone who deals with Lennart just starts yelling, because he is impossible to reason with. He's very intelligent, and absolutely convinced that his is the One True Correct Right Way. It doesn't matter than hundreds or thousands of voices oppose him; I don't think it would matter if every single human being on earth opposed him. What makes it worse is that he's often not completely wrong. Linux did need something like PulseAudio, something like Avahi and something like systemd. But his reach exceeds his grasp (which probably applies to us all, as I've found on my own projects), which leads to the well-known problems of PulseAudio & systemd. I don't actually want him to quit the Linux world. But I wish he would scale back his ambitions just a tad, and consider that maybe — just maybe — other people have some good points, and valid concerns. And also Windows/DOS are not terribly good design exemplars.
gerbilly 8y ago
> I still consider it a weakness of UNIX that "logout" doesn't really mean "logout" Ok, but UNIX and it's behaviour has evolved over forty years, and users have a certain set of expectations about it. Also, it should be noted, systems like UNIX are cultural artifacts. The way they are is the result of forty years of back and forth debate and negotiation and eventually compromise. I can't speak for all of them, but I think that people that are bothered by systemd are upset that all of history has been brushed aside to make place for the preferences of just a few influential developers. Whether a feature like logout is "logical" or not, is besides the point. Operating system design isn't just about logic, it's about serving users.
- toomim 8y ago
  That was the point of OP's article. That it's hard to change.
- pas 8y ago
  Yes, indeed, it's not about logic, as those same users cheer Linux instead of sticking with BSD, and then complain about not being UNIX enough.
jimrandomh 8y ago
There's a bug here, which impacts end users: a variety of programs which are clearly intended to persist in the background (nohup, tmux, etc) are failing to persist. This is a real bug. We care about it. I won't be satisfied until it appears that the bug is on track to be fixed, and a lot of other people won't either. The options for fixing the bug are: * nohup, tmux, emacs, etc all take dependencies on systemd and use the new systemd daemonization procedure. This is not a viable path because the maintainers of those utilities have refused (see https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428), and because there are too many of them. * Each distro separately works around the problem by maintaining forks of nohup, tmux, etc. This is not a viable solution because it's way too many forks; people will be finding broken distro+utility pairs forever. * Each distro separately works around the problem by putting loginctl enable-linger in /etc/profile and KillUserProcesses=no. This would effectively be overruling a systemd's decision. Some distros won't know they need to do this, and the github systemd repo becomes a trap. * Or: systemd backs down and changes the defaults so that the old daemonization APIs work again. If you have a fifth option, we'd all love to hear it. But the status quo is that there's a user-facing bug, and the bug is still there. Rather than make the case for it not being a bug, you're currently making the case for it being someone else's bug, but the "someone else" doesn't actually have the power to fix it. You are the only one with the power to fix this bug.
- inferiorhuman 8y ago
  > If you have a fifth option, we'd all love to hear it. Replace systemd with something else.
  - pas 8y ago
    Devuan
  - NullPrefix 8y ago
    There's literally nothing wrong with OpenRC
- apple4ever 8y ago
  I don't understand the issue. systemd offers the option to override the default. Its literally a config. If its such a big deal, why don't the distros just override it? Its a one time change.
yellowapple 8y ago
I feel like the kernel policy of "don't break userspace" would be a valuable one for y'all to adopt.
jjolla 8y ago
> still consider it a weakness of UNIX that "logout" doesn't really mean "logout" ... I mean, that's not how you build a secure system so, unix has been running for 20+ years laden with this security flaw? strange that nobody has been screaming out to plug it all this time. this feels like you have a bee in your bonnet that it is not a very 'pure' logout by some interpretation of what a "logout" should be. imho, "logout" should mean what it has always meant in the past.

tasuki 8y ago

Lennart, thanks for the information. Mind explaining why you chose to kill user processes on logout as the default?

poettering 8y ago
I think my comment above explained that already.
- m4r35n357 8y ago
  They show that you do not understand what "log out" is for in Unix.
- belorn 8y ago
  I think tasuki is asking you to elaborate a bit further on what kind of security issues you have solved by not using SIGHUP signal. I would personally also like to hear more in-depth details, preferable with some examples of security vulnerabilities that was caused because of that POSIX design choice.
  - poettering 8y ago
    Well, this boils down to: in a modern operating system, is it good design that an unprivileged user who logs in once can consume arbitrary runtime resources uncontrolled, unbounded forever, even after logout just because they decided to mask SIGHUP? I think not, I think the system should default to behaviour where unprivileged processes are clearly lifecycle bound, and when the user's sessions end they end comprehensively. I mean, other OSes don't really allow this unprivileged either, for good reasons: the lifecycle of the unpriv user's processes should be controlled by privileged code, and clearly be defined by the act of logging in and logging out in its lifetime. It's entirely OK if the admin then opts out specific users or even all users from this behaviour, i.e. if a privileged players decides to liberalize unbounded, unlifecycled resource consumption for unprivileged players. But a default where unprivileged code can just stick around uncontrolled and consume as much as it wants forever is just a strange choice security wise. i.e. I think the fact that SIGHUP masking is unrestricted, i.e. is not subject to privilege checks is the problem really. Something is unpriv by default that should be priv by default. And that's pretty much what this option in systemd provides you with.
    - dooglius 8y ago
      > is it good design that an unprivileged user who logs in once can consume arbitrary runtime resources uncontrolled, unbounded forever A unprivileged user can still do this by setting up an intermediary box that keeps a persistent ssh session open. Incidentally, this is exactly what I plan to do if I ever need to ssh into a server with KillUserProcesses=yes. > other OSes don't really allow this unprivileged either On Windows, if I remote desktop from a laptop into a desktop, and start a web server, then shut down the laptop, the server stays running. On iOS if I start drafting an email, and reboot my phone, I don't lose my work. On ChromeOS, my tabs will stick around after a system crash. The world is moving toward processes being _more_ persistent, not less.

majewsky 8y ago

> What was requested though is to either run things as child of systemd --user or just register a separate PAM session When you run your screen or tmux below `systemd --user`, you still would have to `loginctl enable-linger`, no? I remember having to do that when I set up a PulseAudio server on a headless machine where I don't maintain an active session.

vesak 8y ago

You've done great work as a whole, as you probably know. Try not let the lowlifes get to you.

inferiorhuman 8y ago

> Now I am used to taking blame for apparently everything that every went wrong on Linux, but you might as well blame your downstream distros for this as much you want to blame us upstream about this, as it's up to them to pick the right compile-time options matching their userbase and requirements in compatibility, and if they didn't do that to your liking, then maybe you should complain to them first. It's up to you as a systemd developer to pick sane defaults. Claiming that it's okay to introduce opt-out breaking changes upstream and then abdicate responsibility is a quite bit like walking around while waving your hands and arms around and then blaming whoever you hit for walking into you.

izacus 8y ago
Killing software that might be running after a valid login session is a sane default.
- inferiorhuman 8y ago
  And that's what SIGHUP is for. The process will exit by default. If that's not the desired behavior a handler can be registered. Killing things that are explicitly designed to run after logout is a piss poor default.
  - tyingq 8y ago
    This. There's a reason the defacto way to keep running post logout was named "nohup". This wasn't some deep dark unknown secret behaviour that was broken.
    - v_lisivka 8y ago
      Because 1) maintainer can be overloaded, so (s)he will stick to defaults, 2) maintainer needs a logical reason to change default setting to something else, which is not obvious in most cases. Maintainer is not a QA team.
    - zbentley 8y ago

sfilargi 8y ago

Completely agree. The problem is not upstream, but downstream. Distros should have done better job and chosen a better default system manager and not systemd. You build your software the way you want and like. If others don’t like that it breaks POSIX they should stop using it instead of complaining. Or fork it.

inferiorhuman 8y ago

> And yes, I still consider it a weakness of UNIX that "logout" doesn't really mean "logout", but just "maybe, please, if you'd be so kind, i'd like to exit, but not quite". I mean, that's not how you build a secure system. As an aside this is the height of arrogance to suggest that the systemd is somehow a more secure alternative. Lest this be considered an empty ad hominem attack, let me quote the pwnie you won in 2017[1]: > Where you are dereferencing null pointers, or writing out > of bounds, or not supporting fully qualified domain names, > or giving root privileges to any user whose name begins with > a number, there's no chance that the CVE number will > referenced in either the change log or the commit message. > But CVEs aren't really our currency any more, and only the > lamest of vendors gets a Pwnie! 1: https://pwnies.com/archive/2017/winners/#lamestvendor https://pwnies.com/archive/2017/winners/#lamestvendor

youdontknowtho 8y ago
You know it's open source and that you could actually get involved? If you submit a pull request and it doesn't get merged you can take your concerns to the the larger group. As to the stuff mentioned in the pwnie. Those sound like great contributions that would be appreciated. You could also take your concerns to the distro development group. If that doesn't work you could also customize your distro with a custom build of systemd. If you still don't get satisfaction you can stop using it. If you dislike how they do thing you have options. Or, you could just be mean on a forum...
arpa 8y ago
> giving root privileges to any user whose name begins with > a number https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 oh my god, what a spectacular issue. And, seriously, the Poetterings' response is basically "not my job" and "not a bug". And this person develops something that sits at the core of a modern linux system...
- inferiorhuman 8y ago
  > oh my god, what a spectacular issue. And, seriously, the Poetterings' response is basically "not my job" and "not a bug". And this person develops something that sits at the core of a modern linux system... All the while Lennart claims that he's making Linux more secure. FFS. Edit: I forgot about this https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and... > He (Theodore Ts’o) goes on to describe how he previously had to neuter policykit’s security (rendering his system very vulnerable) just to get his system working, and how he has found systemd "very difficult sometimes to figure out". And: > As for Kay Sievers, maybe he should rename himself to Kay Sewers, because that’s exactly what he smells of. He told to IETF internet area director and previously DHCP working group co-chair “Tod Lemon” to lmgtfy when he asked about a systemd related git repository. This gem sums it up perfectly though: > Yet just two days ago, we see Linus Torvalds (the creator of Linux and maintainer of the Linux kernel), launching into a tirade against – yes, you guessed it – systemd developers because of their atrocious response to a bug in systemd that is crashing the kernel and preventing it from being debugged. Linus is so upset with systemd developer Kay Sievers (gee, where I have heard that name before – oh, that’s right, he’s the moron who refused to fix udev problems) that Linus is threatening to refuse any further contributions from this Red Hat developer, not just because of this bug, but because of a pattern of this behavior – a problem for Kay because Red Hat is also foaming at the mouth to have their kernel-based, no doubt bug- and security-flaw-ridden D-Bus implementation included in our kernels. Other developers were so peeved that they suggested simply triggering a kernel panic and halting the system when systemd is so much as detected in use.

sametmax 8y ago

For what it's worth, systemd makes my life easier. When I switch distro, it's almost always systemd, and not the system du jour, so I know how it works. Creating service files is a google query away, and makes common use cases a breathe, while advanced features that were hard to bash script yourself into, are now just a few options to type. I understand that many people may have problems with systemd for their particular situation, but that's not my experience. As a dumb user with a few laptops and servers that needs an occassional daemon, I'm glad systemd won. I know you get a lot of heat since it came out, so thank you for working on it.

nine_k 8y ago
Sure, systemd solves a number of real problems. This is good. What is not as good: (1) systemd takes over or duplicates functionality not related directly to its primary purpose, and (2) is not solid enough to trust it in a number of cases, while (3) the developers' attitude does not give a lot of hope that the situation will materially improve. (Of course, I run a distro without systemd.)

Asooka 8y ago

So you made the default the worst possible option, because... why exactly? And now that the problem is apparent, you haven't changed the default because...? I don't know what goes through your and the rest of the systemd's team's heads, but good software engineering it is not.

loudtieblahblah 8y ago

>You know, because we knew this would be controversial we made sure it was both a compile-time option and a runtime option. This is standard from you. You knock the glass on the floor and blame the maid service for not cleaning up after you. It's everyone's faults but yours. >And yes, I still consider it a weakness of UNIX that "logout" doesn't really mean "logout", but just "maybe, please, if you'd be so kind, i'd like to exit, but not quite". Oh how hyperbolic. Nuances and caveats in terminology is not a weakness. I don't see why you're splitting hairs over this but can't be bothered to care about your UID numbering bug. Or he fact systemd-resolv is responsible for DNS leaking on VPNs. But yes, tell me more about how a functionality that enables terminal multiplexes is a "weakness" >Now I am used to taking blame for apparently everything that every went wrong on Linux, It's because of your smarmy, arrogance. You break POSIX compliance, which has a real world effect in multiple areas and you accept bug reports with the humility of Donald Trump being interviewed by MSNBC. Then when you retreat into your safe space, you play victim to the situation you created. You talk of Linux culture toxicity, smearing the likes of Linus Torvalds, while essentially being the metaphorical sibling putting your finger in people's face repeating "I'm not touching you" over and over. Then you acted attacked when someone claps back. You're a cry bully hiding behind a vaneer of professionalism acceptable for Red Hat's HR department which enables you to mark one more bug as "wontfix"; your attitude, your arrogance, your conceits that things not broken in fact, are so you can provide solutions no one asked for and no one benefits from.

ownagefool 8y ago
To be fair, at least poettering presented an argument and is responsible for software that helps a whole bunch of us get things done. You're just kind of yelling, and it diminishes any point you may have made.
- zeveb 8y ago
  After awhile, anyone who deals with Lennart just starts yelling, because he is impossible to reason with. He's very intelligent, and absolutely convinced that his is the One True Correct Right Way. It doesn't matter than hundreds or thousands of voices oppose him; I don't think it would matter if every single human being on earth opposed him. What makes it worse is that he's often not completely wrong. Linux did need something like PulseAudio, something like Avahi and something like systemd. But his reach exceeds his grasp (which probably applies to us all, as I've found on my own projects), which leads to the well-known problems of PulseAudio & systemd. I don't actually want him to quit the Linux world. But I wish he would scale back his ambitions just a tad, and consider that maybe — just maybe — other people have some good points, and valid concerns. And also Windows/DOS are not terribly good design exemplars.

gerbilly 8y ago

> I still consider it a weakness of UNIX that "logout" doesn't really mean "logout" Ok, but UNIX and it's behaviour has evolved over forty years, and users have a certain set of expectations about it. Also, it should be noted, systems like UNIX are cultural artifacts. The way they are is the result of forty years of back and forth debate and negotiation and eventually compromise. I can't speak for all of them, but I think that people that are bothered by systemd are upset that all of history has been brushed aside to make place for the preferences of just a few influential developers. Whether a feature like logout is "logical" or not, is besides the point. Operating system design isn't just about logic, it's about serving users.

toomim 8y ago
That was the point of OP's article. That it's hard to change.
pas 8y ago
Yes, indeed, it's not about logic, as those same users cheer Linux instead of sticking with BSD, and then complain about not being UNIX enough.

jimrandomh 8y ago

There's a bug here, which impacts end users: a variety of programs which are clearly intended to persist in the background (nohup, tmux, etc) are failing to persist. This is a real bug. We care about it. I won't be satisfied until it appears that the bug is on track to be fixed, and a lot of other people won't either. The options for fixing the bug are: * nohup, tmux, emacs, etc all take dependencies on systemd and use the new systemd daemonization procedure. This is not a viable path because the maintainers of those utilities have refused (see https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428), and because there are too many of them. * Each distro separately works around the problem by maintaining forks of nohup, tmux, etc. This is not a viable solution because it's way too many forks; people will be finding broken distro+utility pairs forever. * Each distro separately works around the problem by putting loginctl enable-linger in /etc/profile and KillUserProcesses=no. This would effectively be overruling a systemd's decision. Some distros won't know they need to do this, and the github systemd repo becomes a trap. * Or: systemd backs down and changes the defaults so that the old daemonization APIs work again. If you have a fifth option, we'd all love to hear it. But the status quo is that there's a user-facing bug, and the bug is still there. Rather than make the case for it not being a bug, you're currently making the case for it being someone else's bug, but the "someone else" doesn't actually have the power to fix it. You are the only one with the power to fix this bug.

inferiorhuman 8y ago
> If you have a fifth option, we'd all love to hear it. Replace systemd with something else.
- pas 8y ago
  Devuan
- NullPrefix 8y ago
  There's literally nothing wrong with OpenRC
apple4ever 8y ago
I don't understand the issue. systemd offers the option to override the default. Its literally a config. If its such a big deal, why don't the distros just override it? Its a one time change.

yellowapple 8y ago

I feel like the kernel policy of "don't break userspace" would be a valuable one for y'all to adopt.

jjolla 8y ago

> still consider it a weakness of UNIX that "logout" doesn't really mean "logout" ... I mean, that's not how you build a secure system so, unix has been running for 20+ years laden with this security flaw? strange that nobody has been screaming out to plug it all this time. this feels like you have a bee in your bonnet that it is not a very 'pure' logout by some interpretation of what a "logout" should be. imho, "logout" should mean what it has always meant in the past.