6 ms·

> Because it's a bug for some, and intended behavior for others. Look, you make it as if they introduced a bug on purpose to screw with some people. It's clearl

by shakna 8y ago

> Because it's a bug for some, and intended behavior for others. Look, you make it as if they introduced a bug on purpose to screw with some people. It's clearly not the case, there was a specific tradeoff involved. They broke userland. It doesn't matter what tradeoff they made - they went against POSIX behaviour, and as a result, broke numerous utilities, both past and future. Let's say that again - systemd introduced breaking behaviour on userland, against POSIX, and instead of backing down and allowing for expected and specified behaviour, they said it's everyone else's problem. That is neither professional, nor responsible. When you make a mistake, a mistake that breaks the behaviour of POSIX, and POSIX utilities like _cron_, you apologise, and fix the problem. You don't turn around and say that all the sysutils should incorporate your new idea.

xyzzyz 8y ago
> They broke userland. So? "We don't break userland" is a Linux kernel thing. Systemd is not kernel, it's userland, and userland things break other userland things all the time. They already broke lots of existing stuff when they replaced /etc/init.d/ scripts with systemd definition files, should systemd also have not done that? > It doesn't matter what tradeoff they made - they went against POSIX behaviour, and as a result, broke numerous utilities, both past and future. Linux is not POSIX, so I don't see how that's relevant. For what it's worth, I don't even know what part of POSIX it broke. Care to enlighten me?
- jimrandomh 8y ago
  Right; the Linux kernel has a "we don't break userland" policy, systemd doesn't. That's a selling point for the Linux kernel, and a strike against systemd. Both systemd and the Linux kernel are infrastructure projects which, if they're doing their jobs well, will never cause me problems so I get to ignore them. Systemd has been causing other people problems, and doesn't seem to understand that in the role they're trying to fill, preventing that from happening is their first and most important responsibility.
  - majewsky 8y ago
    Like it or not, the Linux kernel is clearly the outlier in terms of backwards compatibility. For example, Postgres changes their data format in most non-bugfix releases. Would you consider that "a strike against" Postgres?
    - dooglius 8y ago
      They provide an upgrade process that makes this invisible to the end user, so it's not a fair comparison. If it started deleting tables when I exit a session, that would definitely be a strike against it.
      - m45t3r 8y ago
        Systemd offer a compile and runtime option to turn this option off, so it is a fair comparison.
      - SahAssar 8y ago
        Postgres has session-bound resources, and in most cases no way to disable those from being deleted when exiting a session. For example in postgres you can't persist a prepared statement, but you can of course persist data within a table. Any function running will be killed when you exit (or at least not complete since the transaction is cancelled). IMO when a user has logged out and has not had the permissions/foresight to setup a task in the system to run without a session it should be killed. I get that this has not been the default behavior in linux/UNIX, but to me it seems like the sensible one. And that's before we ever argue about the possibility to turn it off.
- shakna 8y ago
  I think you're completely missing the point. If you ruin everyone else's day, and change behaviour everyone else is expecting, then it's probably your own fault. Approaching it as if everyone should simply change and do what you want, is the height of arrogance. You are generating work for others. And in this particular case, not only are you generating work for others, you are eradicating a category of software. When a distribution adopts systemd, they let everyone know how things are changing, and slowly transition things over, releasing when stable. We know systemd replaces init.d. It was difficult, but distributions using systemd got over that hurdle, but it did take time. However, this is not the same. Yes, systemd is userland, however it is also PID 1. It is a layer between most userland and the kernel, and so needs to reflect the responsibility of it's position. Ignoring how NOHUP is supposed to be interpreted, is a _bad idea_, and yes, a violation of POSIX, specifically signals (SIGHUP and nohup), and how they are supposed to be handled. Moreso, it greatly heightens the difficulty of many utilities that are expected to work. Why should cron (all implementations of cron), suddenly need to rely on another userland library to maintain it's function? You just broke most Linux automation. Across an entire industry. Why should screen (all implementations of screen), suddenly need to rely on a userland library much bigger than most implementations, to continue it's base function? You just broke an entire category of background systems - including systems communicating with embedded hardware. You might have caused a factory-floor fault. Which could cause injury, or worse. A breaking change of this level can cause industry-wide ramifications that are not just limited to the digital. Unexpected behaviour is exceptional, and should take time and considerable thought before occurring. Systemd has responsibility that no other userland system has. It's PID 1. If they're going to require a massive change in process behaviour, then they are going to require consultation, awareness within the industry, and transition time. They should be working with distributions, aware of the man-hours they're generating, before they put something in place.
  - jodrellblank 8y ago
    Aren't we just a few weeks after Rich Hickey's "you have no right to make demands of open source software" rant? Systemd has responsibility that no other userland system has. It's PID 1. No, you have the responsibility to check what the software you are installing does, and if you don't approve, change it or reject it. Or, don't check, and deal with it. Systemd developers do not owe you working POSIX, working cron, industry wide working Linux automation, screen, separate userland for everything. They don't owe you anything. If you don't like their thing, don't use their thing.
poettering 8y ago
First of all, as mentioned above, we made this compile-time as well as runtime-configurable, so that downstream distros can choose whether they want to make this opt-in or opt-out. Hence blame your distros if you picked it in a way you didn't like. Moreover, this doesn't affect cron at all. Cron creates its own PAM session for each job it runs which means those jobs are independent from any real login session (i.e. ssh, graphical, tty login), and thus also don't get cleaned up by them. This affected stuff that is forked off a login session and then stays around as "orphan" if you so will, i.e. with all session resources released, except for these processes that try hard to avoid clean-up (usually by double forking + detaching explicitly from any TTY/ignoring SIGHUP).
- youdontknowtho 8y ago
  This has more to do with feelings about you and the perception of you as a "bad guy" than it does about the technical discussion. I tend to agree with the idea that the choice of defaults belongs to the distro's. If the distro's are deferring to the upstream project on default settings for a critical system component then they need to be more thorough and validate what they are shipping.
  - v_lisivka 8y ago
    Maintaining of all these special cases requires lot of knowledge. If maintainer is responsible for just systemd package, then it's not a problem, but when number of packages per maintainer is measured in hundreds, maintainer will stick to defaults, unless users will complain loudly enough to sacrifice whole working day on the problem.
    - Redoubts 8y ago
      > Maintaining of all these special cases requires lot of knowledge. Distro maintainers need to have a lot of knowledge about their init system. There's no way out of that. It's probably something everyone should know a little about as well.
      - 8y ago
zbentley 8y ago
> They broke userland. That alludes to kernel development, which systemd is largely uninvolved with. A userland program chosen by various distributions failed to support conventions from a different userland program. That's all. Were the programs involved fundamental and highly important to many users' experience? Sure. Is busting out "you broke userland" like some magical shibboleth useful as a means of your conveying your unhappiness that your distribution maintainers chose to replace a widely-depended-upon program with a different program useful? I think not. > they went against POSIX behaviour Which? There's "tradition" and "specified behaviour". Both are important in different situations and in different degrees. > You don't turn around and say that all the sysutils should incorporate your new idea. Why not? They're no more privileged by the POSIX specification, or by the user/kernel -space divide than any other program.
pas 8y ago
POSIX was broken first. It's insecure by default. Intel, the kernel, even Chrome broke my userland by mitigating Spectre. It happens. CRON was and is run as a system service, in its own scope. If you run your own cron instance, but forgot to set it up as a system service, yeah, it gets cleaned up as you exit your shell/session/scope.

by shakna 8y ago

xyzzyz 8y ago

> They broke userland. So? "We don't break userland" is a Linux kernel thing. Systemd is not kernel, it's userland, and userland things break other userland things all the time. They already broke lots of existing stuff when they replaced /etc/init.d/ scripts with systemd definition files, should systemd also have not done that? > It doesn't matter what tradeoff they made - they went against POSIX behaviour, and as a result, broke numerous utilities, both past and future. Linux is not POSIX, so I don't see how that's relevant. For what it's worth, I don't even know what part of POSIX it broke. Care to enlighten me?

jimrandomh 8y ago
Right; the Linux kernel has a "we don't break userland" policy, systemd doesn't. That's a selling point for the Linux kernel, and a strike against systemd. Both systemd and the Linux kernel are infrastructure projects which, if they're doing their jobs well, will never cause me problems so I get to ignore them. Systemd has been causing other people problems, and doesn't seem to understand that in the role they're trying to fill, preventing that from happening is their first and most important responsibility.
- majewsky 8y ago
  Like it or not, the Linux kernel is clearly the outlier in terms of backwards compatibility. For example, Postgres changes their data format in most non-bugfix releases. Would you consider that "a strike against" Postgres?
  - dooglius 8y ago
    They provide an upgrade process that makes this invisible to the end user, so it's not a fair comparison. If it started deleting tables when I exit a session, that would definitely be a strike against it.
    - m45t3r 8y ago
      Systemd offer a compile and runtime option to turn this option off, so it is a fair comparison.
    - SahAssar 8y ago
      Postgres has session-bound resources, and in most cases no way to disable those from being deleted when exiting a session. For example in postgres you can't persist a prepared statement, but you can of course persist data within a table. Any function running will be killed when you exit (or at least not complete since the transaction is cancelled). IMO when a user has logged out and has not had the permissions/foresight to setup a task in the system to run without a session it should be killed. I get that this has not been the default behavior in linux/UNIX, but to me it seems like the sensible one. And that's before we ever argue about the possibility to turn it off.
shakna 8y ago
I think you're completely missing the point. If you ruin everyone else's day, and change behaviour everyone else is expecting, then it's probably your own fault. Approaching it as if everyone should simply change and do what you want, is the height of arrogance. You are generating work for others. And in this particular case, not only are you generating work for others, you are eradicating a category of software. When a distribution adopts systemd, they let everyone know how things are changing, and slowly transition things over, releasing when stable. We know systemd replaces init.d. It was difficult, but distributions using systemd got over that hurdle, but it did take time. However, this is not the same. Yes, systemd is userland, however it is also PID 1. It is a layer between most userland and the kernel, and so needs to reflect the responsibility of it's position. Ignoring how NOHUP is supposed to be interpreted, is a _bad idea_, and yes, a violation of POSIX, specifically signals (SIGHUP and nohup), and how they are supposed to be handled. Moreso, it greatly heightens the difficulty of many utilities that are expected to work. Why should cron (all implementations of cron), suddenly need to rely on another userland library to maintain it's function? You just broke most Linux automation. Across an entire industry. Why should screen (all implementations of screen), suddenly need to rely on a userland library much bigger than most implementations, to continue it's base function? You just broke an entire category of background systems - including systems communicating with embedded hardware. You might have caused a factory-floor fault. Which could cause injury, or worse. A breaking change of this level can cause industry-wide ramifications that are not just limited to the digital. Unexpected behaviour is exceptional, and should take time and considerable thought before occurring. Systemd has responsibility that no other userland system has. It's PID 1. If they're going to require a massive change in process behaviour, then they are going to require consultation, awareness within the industry, and transition time. They should be working with distributions, aware of the man-hours they're generating, before they put something in place.
- jodrellblank 8y ago
  Aren't we just a few weeks after Rich Hickey's "you have no right to make demands of open source software" rant? Systemd has responsibility that no other userland system has. It's PID 1. No, you have the responsibility to check what the software you are installing does, and if you don't approve, change it or reject it. Or, don't check, and deal with it. Systemd developers do not owe you working POSIX, working cron, industry wide working Linux automation, screen, separate userland for everything. They don't owe you anything. If you don't like their thing, don't use their thing.

poettering 8y ago

First of all, as mentioned above, we made this compile-time as well as runtime-configurable, so that downstream distros can choose whether they want to make this opt-in or opt-out. Hence blame your distros if you picked it in a way you didn't like. Moreover, this doesn't affect cron at all. Cron creates its own PAM session for each job it runs which means those jobs are independent from any real login session (i.e. ssh, graphical, tty login), and thus also don't get cleaned up by them. This affected stuff that is forked off a login session and then stays around as "orphan" if you so will, i.e. with all session resources released, except for these processes that try hard to avoid clean-up (usually by double forking + detaching explicitly from any TTY/ignoring SIGHUP).

youdontknowtho 8y ago
This has more to do with feelings about you and the perception of you as a "bad guy" than it does about the technical discussion. I tend to agree with the idea that the choice of defaults belongs to the distro's. If the distro's are deferring to the upstream project on default settings for a critical system component then they need to be more thorough and validate what they are shipping.
- v_lisivka 8y ago
  Maintaining of all these special cases requires lot of knowledge. If maintainer is responsible for just systemd package, then it's not a problem, but when number of packages per maintainer is measured in hundreds, maintainer will stick to defaults, unless users will complain loudly enough to sacrifice whole working day on the problem.
  - Redoubts 8y ago
    > Maintaining of all these special cases requires lot of knowledge. Distro maintainers need to have a lot of knowledge about their init system. There's no way out of that. It's probably something everyone should know a little about as well.
    - 8y ago

zbentley 8y ago

> They broke userland. That alludes to kernel development, which systemd is largely uninvolved with. A userland program chosen by various distributions failed to support conventions from a different userland program. That's all. Were the programs involved fundamental and highly important to many users' experience? Sure. Is busting out "you broke userland" like some magical shibboleth useful as a means of your conveying your unhappiness that your distribution maintainers chose to replace a widely-depended-upon program with a different program useful? I think not. > they went against POSIX behaviour Which? There's "tradition" and "specified behaviour". Both are important in different situations and in different degrees. > You don't turn around and say that all the sysutils should incorporate your new idea. Why not? They're no more privileged by the POSIX specification, or by the user/kernel -space divide than any other program.

pas 8y ago

POSIX was broken first. It's insecure by default. Intel, the kernel, even Chrome broke my userland by mitigating Spectre. It happens. CRON was and is run as a system service, in its own scope. If you run your own cron instance, but forgot to set it up as a system service, yeah, it gets cleaned up as you exit your shell/session/scope.