10 ms·

SystemD took away the pain. You no longer have to think and reinvent the demonize, logging and so on. Just just start what ever you want in a while(1) loop and

by Mave83 3y ago

SystemD took away the pain. You no longer have to think and reinvent the demonize, logging and so on. Just just start what ever you want in a while(1) loop and write to stdout and stderr. No log rotate nightmare, etc. This makes daemons easier to debug, as they run just in foreground so that you can start them from the cli to thinker with them. SystemD is highly discussed and some love and some hate it. But such improvements are unmatched and extremely helpful.

simoncion 3y ago
OpenRC, daemontools, and many other service managers provide daemonizing wrappers, and all substantially predate systemd. The Systemd Cabal are far from the first to have noticed and attempted to resolve most of the problems they tackled... they do have the most effective "developer relations" team of all of the projects in this space, though. (I do continue to love their old "It's so much better than System V Init!" talking point... as well as their "You'll never have to write a shell script to start or manage a service again! Declarative, INI-formatted Unit Files For Everyone!" one.)
- WesolyKubeczek 3y ago
  The systemd cabal one-upped all other efforts that pre-dated them by leveraging cgroups such that what rlimits your services run with is dictated by the unit file alone, and not by whatever your user session had when you issued the start or restart command.
  - stonogo 3y ago
    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.
- Izkata 3y ago
  And I think "daemonize" might have been the first? One of the earliest at least, it turns a single process into daemon but doesn't have an overall system command to handle them.

by Mave83 3y ago

simoncion 3y ago

OpenRC, daemontools, and many other service managers provide daemonizing wrappers, and all substantially predate systemd. The Systemd Cabal are far from the first to have noticed and attempted to resolve most of the problems they tackled... they do have the most effective "developer relations" team of all of the projects in this space, though. (I do continue to love their old "It's so much better than System V Init!" talking point... as well as their "You'll never have to write a shell script to start or manage a service again! Declarative, INI-formatted Unit Files For Everyone!" one.)

WesolyKubeczek 3y ago
The systemd cabal one-upped all other efforts that pre-dated them by leveraging cgroups such that what rlimits your services run with is dictated by the unit file alone, and not by whatever your user session had when you issued the start or restart command.
- stonogo 3y ago
  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.
Izkata 3y ago
And I think "daemonize" might have been the first? One of the earliest at least, it turns a single process into daemon but doesn't have an overall system command to handle them.