7 ms·

And they did so by sweeping the entire UNIX landscape into the dustbin, only supporting linux, and in return giving us a management system that can't be sure an

And they did so by sweeping the entire UNIX landscape into the dustbin, only supporting linux, and in return giving us a management system that can't be sure anything is running[1]. systemd is leaps and bounds better than most of the init systems that came before it, but it's not a good daemon supervisor, and the developers have basically declared that it's "good enough" so improvements are unwelcome. 1 - http://ewontfix.com/15/ http://ewontfix.com/15/

WesolyKubeczek 3y ago
Well, do systems like, say, FreeBSD even support facilities functionally equivalent to control groups? Even if they do (which they don’t), it would be a whole new separate implementation, and there’s not enough interest from anyone who can do it to roll their sleeves and work on it.
- stonogo 3y ago
  FreeBSD, specifically, has had jails and Capsicum longer than systemd has existed, and rctl (aka Resource Limits) for about a decade now. Like I said, systemd is a great init system but it really did not bring anything to the table as far as service management. Apple's abdication of the problem makes sense since they're tightly focused on workstation ever since killing the Xserve line in 2011.
  - WesolyKubeczek 3y ago
    Can rctl give me an ability to run two instances of the same executable with different limits?
    - zare_st 3y ago
      Yes
- zare_st 3y ago
  Answer to question - yes, and more. Jails+rctl (available since 2012) is not cgroups it's cgroups+SELinux+APParmor. Vanilla linux container is not a security barrier, vanilla FreeBSD jail is. In practice this means more seamless 'isolation' in Linux case but that isolation is weak. Which perfectly corresponds to FreeBSD looking at server uses 99% of the time and Linux looking at the desktop too. About your conclusion, I don't think that's based on anything so please do write on what facts do you base the assessment that FreeBSD has no resource limiting and isolation features, and that it would be a 'separate implementation', as FreeBSD always tends to upgrade and not change tools and interfaces, and that there is not enough interest from anyone to implement it, as most major FreeBSD features are actually paid for by FreeBSD sponsors.
  - WesolyKubeczek 3y ago
    I don’t assess FreeBSD doesn’t have resource limits. I’m stating the fact that prior to systemd, issuing a service restart command under any Unix at all was prone to inheriting any rlimits your shell session happened to have, which could in turn lead to unforeseen consequences like sudden memory/file handles failures or sluggish I/O, depending on how shell sessions are being set up. Implementing a service manager that can understand and interpret systemd unit files for FreeBSD would require it to be based on completely different kernel mechanisms than Linux, feature parity aside. I can easily see that people with enough skill won’t see the need to be bothered to write such a piece of software, and those who don’t will just shrug and stay on Linux.
    - simoncion 3y ago
      > I’m stating the fact that prior to systemd, issuing a service restart command under any Unix at all was prone to inheriting any rlimits your shell session happened to have... IFF the service manager you used was either incompetently written, or had this behavior as an intentional feature. This is a problem (like many other problems that the Systemd Cabal addressed) that was known and resolved by many other folks substantially before systemd came along. Like, think about it for a second. You're saying that systemd has a mechanism to avoid this problem. Systemd uses tools that have been available in Linux for a long time. (I think the newest tool it uses is control groups, which are like seventeen years old.) Are you really saying that none of the big players in the space (nor any of the sysadmins that got REALLY pissed off at the bullshit unreliable behavior that you describe) ever hit upon the technique that systemd uses to avoid this problem? As I (and many other) keep saying, systemd did solve many problems... but it was also not the first to solve many of those problems. > Implementing a service manager that can understand and interpret systemd unit files for FreeBSD... Unit files kinda suck, and so much of the behavior of the various options inside of them are underspecified. (How do I know? I've gotten badly burned in production repeatedly by underspecified behavior shifting out from under me as the software implementation changed.) There's no good reason to use Unit files outside of systemd... especially when services with non-trivial startup and/or shutdown procedures have to have systemd run helper programs because it's just impossible for systemd to handle every conceivable startup and/or shutdown requirement without embedding a general-purpose scripting language inside of systemd (which would just be fucking stupid).
WesolyKubeczek 3y ago
Also, do you happen to know how, say, macOS manages service dependencies with launchd and makes sure everything is running? It doesn’t. It explicitly says in the scarce documentation that it doesn’t care, and that interdependent services should use IPC and in general figure it out between themselves. launchd only launches the processes as soon as it can, and restarts them based on a boolean flag if they die. That’s all. systemd at least gives you something to base your expectations on.
- saurik 3y ago
  Adding a mechanism for dependencies which kind of sometimes sort of works but doesn't actually work is much much worse than just not implementing anything at all as you are much less likely to get anyone too put in the work required to do the hard thing they need to do for it to actually work.
  - WesolyKubeczek 3y ago
    It does work: an init system shouldn’t have a knowledge of what constitutes a process being "ready", but it knows damn well if its executable is running or not. Any dependent/client task should be able to wait or retry. If it cannot retry on its own, systemd has a facility for this, too. At this point it really looks like after having some nice things you are running out of legitimate complaints and want a pony on top.
viraptor 3y ago
What link is a bit weird. https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html https://www.freedesktop.org/software/systemd/man/latest/sd_n... documents exactly what is sent and how. You can implement that function yourself very easily. Their edge cases are solved by opening the notification socket before you chroot. Writing to a socket would be just as systemd-specific as the current solution if that's what systemd would expect.

WesolyKubeczek 3y ago

Well, do systems like, say, FreeBSD even support facilities functionally equivalent to control groups? Even if they do (which they don’t), it would be a whole new separate implementation, and there’s not enough interest from anyone who can do it to roll their sleeves and work on it.

stonogo 3y ago
FreeBSD, specifically, has had jails and Capsicum longer than systemd has existed, and rctl (aka Resource Limits) for about a decade now. Like I said, systemd is a great init system but it really did not bring anything to the table as far as service management. Apple's abdication of the problem makes sense since they're tightly focused on workstation ever since killing the Xserve line in 2011.
- WesolyKubeczek 3y ago
  Can rctl give me an ability to run two instances of the same executable with different limits?
  - zare_st 3y ago
    Yes
zare_st 3y ago
Answer to question - yes, and more. Jails+rctl (available since 2012) is not cgroups it's cgroups+SELinux+APParmor. Vanilla linux container is not a security barrier, vanilla FreeBSD jail is. In practice this means more seamless 'isolation' in Linux case but that isolation is weak. Which perfectly corresponds to FreeBSD looking at server uses 99% of the time and Linux looking at the desktop too. About your conclusion, I don't think that's based on anything so please do write on what facts do you base the assessment that FreeBSD has no resource limiting and isolation features, and that it would be a 'separate implementation', as FreeBSD always tends to upgrade and not change tools and interfaces, and that there is not enough interest from anyone to implement it, as most major FreeBSD features are actually paid for by FreeBSD sponsors.
- WesolyKubeczek 3y ago
  I don’t assess FreeBSD doesn’t have resource limits. I’m stating the fact that prior to systemd, issuing a service restart command under any Unix at all was prone to inheriting any rlimits your shell session happened to have, which could in turn lead to unforeseen consequences like sudden memory/file handles failures or sluggish I/O, depending on how shell sessions are being set up. Implementing a service manager that can understand and interpret systemd unit files for FreeBSD would require it to be based on completely different kernel mechanisms than Linux, feature parity aside. I can easily see that people with enough skill won’t see the need to be bothered to write such a piece of software, and those who don’t will just shrug and stay on Linux.
  - simoncion 3y ago
    > I’m stating the fact that prior to systemd, issuing a service restart command under any Unix at all was prone to inheriting any rlimits your shell session happened to have... IFF the service manager you used was either incompetently written, or had this behavior as an intentional feature. This is a problem (like many other problems that the Systemd Cabal addressed) that was known and resolved by many other folks substantially before systemd came along. Like, think about it for a second. You're saying that systemd has a mechanism to avoid this problem. Systemd uses tools that have been available in Linux for a long time. (I think the newest tool it uses is control groups, which are like seventeen years old.) Are you really saying that none of the big players in the space (nor any of the sysadmins that got REALLY pissed off at the bullshit unreliable behavior that you describe) ever hit upon the technique that systemd uses to avoid this problem? As I (and many other) keep saying, systemd did solve many problems... but it was also not the first to solve many of those problems. > Implementing a service manager that can understand and interpret systemd unit files for FreeBSD... Unit files kinda suck, and so much of the behavior of the various options inside of them are underspecified. (How do I know? I've gotten badly burned in production repeatedly by underspecified behavior shifting out from under me as the software implementation changed.) There's no good reason to use Unit files outside of systemd... especially when services with non-trivial startup and/or shutdown procedures have to have systemd run helper programs because it's just impossible for systemd to handle every conceivable startup and/or shutdown requirement without embedding a general-purpose scripting language inside of systemd (which would just be fucking stupid).

WesolyKubeczek 3y ago

Also, do you happen to know how, say, macOS manages service dependencies with launchd and makes sure everything is running? It doesn’t. It explicitly says in the scarce documentation that it doesn’t care, and that interdependent services should use IPC and in general figure it out between themselves. launchd only launches the processes as soon as it can, and restarts them based on a boolean flag if they die. That’s all. systemd at least gives you something to base your expectations on.

saurik 3y ago
Adding a mechanism for dependencies which kind of sometimes sort of works but doesn't actually work is much much worse than just not implementing anything at all as you are much less likely to get anyone too put in the work required to do the hard thing they need to do for it to actually work.
- WesolyKubeczek 3y ago
  It does work: an init system shouldn’t have a knowledge of what constitutes a process being "ready", but it knows damn well if its executable is running or not. Any dependent/client task should be able to wait or retry. If it cannot retry on its own, systemd has a facility for this, too. At this point it really looks like after having some nice things you are running out of legitimate complaints and want a pony on top.

viraptor 3y ago

What link is a bit weird. https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html https://www.freedesktop.org/software/systemd/man/latest/sd_n... documents exactly what is sent and how. You can implement that function yourself very easily. Their edge cases are solved by opening the notification socket before you chroot. Writing to a socket would be just as systemd-specific as the current solution if that's what systemd would expect.