9 ms·

Systemd 254 released, deprecating sysvinit scripts

genmud 3y ago
Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.
- rubiquity 3y ago
  Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.
  - jmclnx 3y ago
    [flagged]
    - sidpatil 3y ago
      Which is fair, since Linux Is Not UniX.
    - rubiquity 3y ago
      I guess I didn’t get the hint that UNIX is not for me over two decades ago! Do you also dislike launchd and generally being productive?
      - jmclnx 3y ago
        I have no idea what launchd is.
  - Bombinator 3y ago
    Don't you think it does a bit too much as an init system?
    - rubiquity 3y ago
      It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!
    - op00to 3y ago
      No, it does what I want well. It never surprised me.
    - tekla 3y ago
      What does it do as an init system that is too much?
    - tptacek 3y ago
      No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.
    - diffeomorphism 3y ago
      Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.
    - akerl_ 3y ago
      Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically. I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
  - washadjeffmad 3y ago
    Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around". I mean init systems, of course.
- mqus 3y ago
  "will be removed in a future release" So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
  - bravetraveler 3y ago
    Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do. Here's the Unit, what this provides: [Unit] Description=Whatever After=network.target network-online.target [Service] Type=forking ExecStart=/etc/init.d/your_awesome_initscript start ExecStop=/etc/init.d/your_awesome_initscript stop ExecReload=/etc/init.d/your_awesome_initscript restart [Install] WantedBy=some.target For bonus points - and smaller repositories and more reliability... ... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd. It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables. Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement? It's not removed yet, there's time.
- vkazanov 3y ago
  You do realise that sysvinit scripts are much, much, much more fragile? Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
  - haolez 3y ago
    The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).
    - sophacles 3y ago
      Can you define spaghetti in this context, and point to examples in the code?
      - haolez 3y ago
        My point is that the complexity is still there, but hidden. There is good and bad code in systemd as there is good and bad sysv init scripts.
    - vkazanov 3y ago
      Yes, systemd is far from trivial. The model of its operation is rather convoluted. But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc. There some questions around binary logs, yes, but nothing truly unbearable.
    - kaba0 3y ago
      Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced. As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.
- Karellen 3y ago
  As someone else has pointed out, this is only a deprecation at this point. For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal. Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021. Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.
throwawa14223 3y ago
Instead of complaining just drop anything that contains Systemd. I did and my frustration with IT related tasks has gone way down.
- ticviking 3y ago
  I'm curious what alternative you make use of. My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
- stingraycharles 3y ago
  I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.
- Aardwolf 3y ago
  But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?
  - arjvik 3y ago
    Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.
- op00to 3y ago
  Huh. Since learning more about systemd my frustration with IT related tasks has gone way down. Unit files are far more functional for the same amount of effort as SysV scripts.
  - lloeki 3y ago
    beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.
Arnavion 3y ago
Previous discussion: https://news.ycombinator.com/item?id=36513889 https://news.ycombinator.com/item?id=36513889
j16sdiz 3y ago
told you. Just like pulsed, he won't stop until every existing, non-default config breaks. Just like pipewire, he will start a "better" alternative and restart the stuff breaking cycle
- pantalaimon 3y ago
  pipewire was not started by Lennart Poettering
  - pxc 3y ago
    and also it really is better— and quite stable already!
- stryan 3y ago
  systemd's been the default init for every major distro since 2015[0], and has existed as a project since roughly 2010. I think ten years of support for the predecessor is probably good enough. This is just a warning anyway. Lennart also didn't start Pipewire (which as far as I know, has been happily accepted by almost everyone?) and while I was just as annoyed at PulseAudio breaking my sound setup back in 2008 I think these days it's a bit remiss to keep bringing that up as an argument. At least not without talking about how a lot of the issues with it was due to Pulse revealing bugs in the sound card drivers. [0] Going by https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption and yes I'm only counting Arch,Debian,Ubuntu,Fedora,SUSE,and RHEL as the major distros. I could see an argument for Mint or Gentoo in there, but most of that table is honestly pretty useless (I still have my Knoppix floppies as coasters, but I really don't care about whether they've adopted systemd at this point) EDIT: mild edit, sorry it was Wolvix I have as floppies. Knoppix was only on CDs and I'm not sure where mine went.
- pengaru 3y ago
  [flagged]
  - laserdancepony 3y ago
    said the ignorant shill afraid of differing opinions
throw7 3y ago
Embrace, Extend, Extinguish.
- mort96 3y ago
  There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only. There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd. EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.
  - Brian_K_White 3y ago
    But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all. I had a tiny little simple 2k init script that managed lxc containers. It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k. Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself. It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc. The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor. I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for. In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs. Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary. The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say. Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1? I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid. systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture. And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
photonbeam 3y ago
Is there a good systemd book to learn it all?
- matthews2 3y ago
  It has a very good manual. Lennart's blog also has a series named systemd for Administrators: https://0pointer.de/blog/projects/systemd-for-admins-1.html https://0pointer.de/blog/projects/systemd-for-admins-1.html
  - op00to 3y ago
    I have answered all my systemd questions with the manual/manpage.
    - freedomben 3y ago
      The systemd man pages are really great. Red Hat may not be perfect but they do a really good job with documentationj. I was shocked (in a good way) with how good the NetworkManager man pages are, among some others. If you're learning something new, it's definitely worth the time to `man thing` and give it a skim.
- pkaye 3y ago
  I haven't read this myself but you can download it for free. https://opensource.com/downloads/pragmatic-guide-systemd-linux https://opensource.com/downloads/pragmatic-guide-systemd-lin...
javajosh 3y ago
Can we all just take a moment to laugh at the fact that all of this complexity is, roughly speaking, the evolution of AUTOEXEC.BAT? (Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)
- taf2 3y ago
  I want my cake and it to boot fast too.
  - TacticalCoder 3y ago
    I saw that very often but I run a very lean Devuan (a Debian fork without systemd) and it boots ultra-fast too. Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick. Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)? I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse. And people who really need super fast boot times in containers shall use Alpine without systemd anyway.
- johnday 3y ago
  That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)
  - javajosh 3y ago
    >That's not really fair Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything. (Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)
cpach 3y ago
I think systemd is quite good. For those who doesn’t like it: There are other service managers out there. IMHO the most sophisticated alternative is s6-rc. It runs on both Linux and *BSD. https://skarnet.org/software/s6-rc/ https://skarnet.org/software/s6-rc/
supriyo-biswas 3y ago
I simply don't get the outrage/criticism against this part of systemd. Instead of having to play around with `start-stop-daemon` and whatnot, a simple service is just these days: ``` [Unit] Description=my app [Service] Restart=on-failure User=webservices Group=webservices ExecStart=/usr/local/bin/my-web-service [Install] WantedBy=multi-user.target ``` It couldn't really be any simpler. There's also https://github.com/gdraheim/docker-systemctl-replacement# https://github.com/gdraheim/docker-systemctl-replacement# for anyone who needs a "lighter" alternative for tests in Docker.
- tazjin 3y ago
  Some people don't want simple and comprehensible. They want to run unnecessarily complex scripts in black terminals with green fonts. Let them be, somebody has to operate all the remaining PHP web pages out there.
  - supriyo-biswas 3y ago
    To be fair, after reading the thread about how people are voting with their feet about systemd-based distributions, I think there's a fair bit of trolling in this thread. "Dropping systemd" would mean that they either use containers in an OS that most likely uses systemd itself, or they otherwise use some niche distribution (such as Antix, Devuan) that I've never heard of being used widely in a production context. Other aspects of systemd might need getting some used to, but it's nothing that a reading of the Archlinux wiki didn't solve.
    - deleted 3y ago
      [deleted]
    - 0cf8612b2e1e 3y ago
      Voting with their feet? As a non-OS developer, I have a very limited distribution selection if I want to use a popular choice receiving more support , bug fixes, etc. Sure, I could run a less popular distribution that foregoes systemd, but what happens when I encounter an issue with wifi, sound, etc. Can I get CUDA or Steam to work on a periphery OS? Systemd is chosen for me because there is so much more to an OS.
CogitoCogito 3y ago
General question: what do most people here dislike about systemd now? Binary logs? Logind? I mean this out of general curiosity. I’ve used systemd a fair amount and I don’t really fight it, but I’m not in love with it or anything.
- TacticalCoder 3y ago
  > what do most people here dislike about systemd now Microsoft / Poettering controlling PID 1 development. As simple as that. It could be better on technical merits (I'm 100% convinced systemd ain't the be-all end-all of init/services scripts / PID1 though), I still hate Poettering's attitude. And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
  - bananapub 3y ago
    > and that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning. er...what on earth are you talking about? as far as I recall, people complained about Lennart because: 1. they didn't like his attitude (lol) 2. they didn't want "init" to do so much, which was mostly just people not bothering to actually look into systemd-the-binary vs systemd-the-project was 3. random specific technical complaints like journald not using plain text or unit files being ini files or whatever edit: typo > it's the ultimate fuck you to people who believed in Linux since the beginning. out of interest, when in the 90's do you feel this was? does it only apply to people who used slackware 1.0? or just SLS users? or does one have to have received a tarball from Lars directly?
  - pengaru 3y ago
    > And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning. I'm sure Lennart was thinking about maximizing tribal offense while evaluating his stable employment options in the midst of RedHat's obvious decline. The list of employers for a full-time upstream systemd maintainer at a competitive salary is rather short. And none of them are particularly attractive in terms of how dirty you'll feel having their logo on your paychecks.
_jal 3y ago
Personally I'm much more annoyed by taking control of how I partition my fucking drives. Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.
- tjoff 3y ago
  How does it do that?
  - _jal 3y ago
    By making Linux less attractive to me.
    - tjoff 3y ago
      I meant, how does it dictate partition layout/xxx?
      - SAI_Peregrinus 3y ago
        It doesn't. If you are using GPT instead of MBR partitioning, AND you use particular partition type UUIDs that SystemD has reserved, THEN you can skip creating an /etc/fstab, and systemd will be able to mount the partitions where their type IDs indicate. If you do choose to create an /etc/fstab that will override the partition type IDs.
  - jauntywundrkind 3y ago
    It has great optional support for Discoverable Partitions, which has made writing custom kernel cmdline's optional. https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ https://uapi-group.org/specifications/specs/discoverable_par... Systems is also are deprecating non merged-/usr.
pwdisswordfishc 3y ago
What is it exactly that is being deprecated here? systemd-sysv-generator? If the unit generator interface is stable, what's to stop downstream distributions from keeping using it regardless?
- op00to 3y ago
  I think it’s being able to have stuff in /etc/init.d that show up as services in SystemD.
- bravetraveler 3y ago
  That's my read/thought too. The generator is lost, and distributions will probably be carrying an analogue forward -- for benefit of third party relics. I don't believe it makes much more assumption than... $script {start,stop,restart} as the Exec lines in the unit The hairy part is how package scriptlets and so on that assume SysV/want old utilities -- eg: chkconfig, service. systemd captured these, and that may go away too
bananapub 3y ago
discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whinging about imagined architecture decisions (like "systemd is a monolith") and then conspiracies about Microsoft like it's a slashdot thread in 1998. notably missing: - discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable - discussion about how making containerisation/chroot/resource limits trivial is good actually - reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux etc etc
- sophacles 3y ago
  Don't forget the single biggest problem of sysvinit: Making services start in a deterministic order when the appropriate (and necessary) resources are actually available.
  - bananapub 3y ago
    dunno what you mean, my "start) sleep 15" works fine most of the time !
- ElectricalUnion 3y ago
  I would add - making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it. Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects. Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.

Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.

rubiquity 3y ago
Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.
- jmclnx 3y ago
  [flagged]
  - sidpatil 3y ago
    Which is fair, since Linux Is Not UniX.
  - rubiquity 3y ago
    I guess I didn’t get the hint that UNIX is not for me over two decades ago! Do you also dislike launchd and generally being productive?
    - jmclnx 3y ago
      I have no idea what launchd is.
- Bombinator 3y ago
  Don't you think it does a bit too much as an init system?
  - rubiquity 3y ago
    It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!
  - op00to 3y ago
    No, it does what I want well. It never surprised me.
  - tekla 3y ago
    What does it do as an init system that is too much?
  - tptacek 3y ago
    No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.
  - diffeomorphism 3y ago
    Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.
  - akerl_ 3y ago
    Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically. I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
- washadjeffmad 3y ago
  Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around". I mean init systems, of course.
mqus 3y ago
"will be removed in a future release" So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
- bravetraveler 3y ago
  Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do. Here's the Unit, what this provides: [Unit] Description=Whatever After=network.target network-online.target [Service] Type=forking ExecStart=/etc/init.d/your_awesome_initscript start ExecStop=/etc/init.d/your_awesome_initscript stop ExecReload=/etc/init.d/your_awesome_initscript restart [Install] WantedBy=some.target For bonus points - and smaller repositories and more reliability... ... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd. It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables. Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement? It's not removed yet, there's time.
vkazanov 3y ago
You do realise that sysvinit scripts are much, much, much more fragile? Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
- haolez 3y ago
  The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).
  - sophacles 3y ago
    Can you define spaghetti in this context, and point to examples in the code?
    - haolez 3y ago
      My point is that the complexity is still there, but hidden. There is good and bad code in systemd as there is good and bad sysv init scripts.
  - vkazanov 3y ago
    Yes, systemd is far from trivial. The model of its operation is rather convoluted. But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc. There some questions around binary logs, yes, but nothing truly unbearable.
  - kaba0 3y ago
    Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced. As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.
Karellen 3y ago
As someone else has pointed out, this is only a deprecation at this point. For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal. Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021. Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.

Instead of complaining just drop anything that contains Systemd. I did and my frustration with IT related tasks has gone way down.

ticviking 3y ago
I'm curious what alternative you make use of. My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
stingraycharles 3y ago
I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.
Aardwolf 3y ago
But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?
- arjvik 3y ago
  Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.
op00to 3y ago
Huh. Since learning more about systemd my frustration with IT related tasks has gone way down. Unit files are far more functional for the same amount of effort as SysV scripts.
- lloeki 3y ago
  beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.

Arnavion 3y ago

Previous discussion: https://news.ycombinator.com/item?id=36513889 https://news.ycombinator.com/item?id=36513889

j16sdiz 3y ago

told you. Just like pulsed, he won't stop until every existing, non-default config breaks. Just like pipewire, he will start a "better" alternative and restart the stuff breaking cycle

pantalaimon 3y ago
pipewire was not started by Lennart Poettering
- pxc 3y ago
  and also it really is better— and quite stable already!
stryan 3y ago
systemd's been the default init for every major distro since 2015[0], and has existed as a project since roughly 2010. I think ten years of support for the predecessor is probably good enough. This is just a warning anyway. Lennart also didn't start Pipewire (which as far as I know, has been happily accepted by almost everyone?) and while I was just as annoyed at PulseAudio breaking my sound setup back in 2008 I think these days it's a bit remiss to keep bringing that up as an argument. At least not without talking about how a lot of the issues with it was due to Pulse revealing bugs in the sound card drivers. [0] Going by https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption and yes I'm only counting Arch,Debian,Ubuntu,Fedora,SUSE,and RHEL as the major distros. I could see an argument for Mint or Gentoo in there, but most of that table is honestly pretty useless (I still have my Knoppix floppies as coasters, but I really don't care about whether they've adopted systemd at this point) EDIT: mild edit, sorry it was Wolvix I have as floppies. Knoppix was only on CDs and I'm not sure where mine went.
pengaru 3y ago
[flagged]
- laserdancepony 3y ago
  said the ignorant shill afraid of differing opinions

throw7 3y ago

Embrace, Extend, Extinguish.

mort96 3y ago
There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only. There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd. EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.
- Brian_K_White 3y ago
  But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all. I had a tiny little simple 2k init script that managed lxc containers. It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k. Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself. It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc. The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor. I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for. In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs. Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary. The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say. Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1? I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid. systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture. And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.

photonbeam 3y ago

Is there a good systemd book to learn it all?

matthews2 3y ago
It has a very good manual. Lennart's blog also has a series named systemd for Administrators: https://0pointer.de/blog/projects/systemd-for-admins-1.html https://0pointer.de/blog/projects/systemd-for-admins-1.html
- op00to 3y ago
  I have answered all my systemd questions with the manual/manpage.
  - freedomben 3y ago
    The systemd man pages are really great. Red Hat may not be perfect but they do a really good job with documentationj. I was shocked (in a good way) with how good the NetworkManager man pages are, among some others. If you're learning something new, it's definitely worth the time to `man thing` and give it a skim.
pkaye 3y ago
I haven't read this myself but you can download it for free. https://opensource.com/downloads/pragmatic-guide-systemd-linux https://opensource.com/downloads/pragmatic-guide-systemd-lin...

javajosh 3y ago

Can we all just take a moment to laugh at the fact that all of this complexity is, roughly speaking, the evolution of AUTOEXEC.BAT? (Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)

taf2 3y ago
I want my cake and it to boot fast too.
- TacticalCoder 3y ago
  I saw that very often but I run a very lean Devuan (a Debian fork without systemd) and it boots ultra-fast too. Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick. Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)? I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse. And people who really need super fast boot times in containers shall use Alpine without systemd anyway.
johnday 3y ago
That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)
- javajosh 3y ago
  >That's not really fair Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything. (Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)

cpach 3y ago

I think systemd is quite good. For those who doesn’t like it: There are other service managers out there. IMHO the most sophisticated alternative is s6-rc. It runs on both Linux and *BSD. https://skarnet.org/software/s6-rc/ https://skarnet.org/software/s6-rc/

supriyo-biswas 3y ago

I simply don't get the outrage/criticism against this part of systemd. Instead of having to play around with `start-stop-daemon` and whatnot, a simple service is just these days: ``` [Unit] Description=my app [Service] Restart=on-failure User=webservices Group=webservices ExecStart=/usr/local/bin/my-web-service [Install] WantedBy=multi-user.target ``` It couldn't really be any simpler. There's also https://github.com/gdraheim/docker-systemctl-replacement# https://github.com/gdraheim/docker-systemctl-replacement# for anyone who needs a "lighter" alternative for tests in Docker.

tazjin 3y ago
Some people don't want simple and comprehensible. They want to run unnecessarily complex scripts in black terminals with green fonts. Let them be, somebody has to operate all the remaining PHP web pages out there.
- supriyo-biswas 3y ago
  To be fair, after reading the thread about how people are voting with their feet about systemd-based distributions, I think there's a fair bit of trolling in this thread. "Dropping systemd" would mean that they either use containers in an OS that most likely uses systemd itself, or they otherwise use some niche distribution (such as Antix, Devuan) that I've never heard of being used widely in a production context. Other aspects of systemd might need getting some used to, but it's nothing that a reading of the Archlinux wiki didn't solve.
  - deleted 3y ago
    [deleted]
  - 0cf8612b2e1e 3y ago
    Voting with their feet? As a non-OS developer, I have a very limited distribution selection if I want to use a popular choice receiving more support , bug fixes, etc. Sure, I could run a less popular distribution that foregoes systemd, but what happens when I encounter an issue with wifi, sound, etc. Can I get CUDA or Steam to work on a periphery OS? Systemd is chosen for me because there is so much more to an OS.

CogitoCogito 3y ago

General question: what do most people here dislike about systemd now? Binary logs? Logind? I mean this out of general curiosity. I’ve used systemd a fair amount and I don’t really fight it, but I’m not in love with it or anything.

TacticalCoder 3y ago
> what do most people here dislike about systemd now Microsoft / Poettering controlling PID 1 development. As simple as that. It could be better on technical merits (I'm 100% convinced systemd ain't the be-all end-all of init/services scripts / PID1 though), I still hate Poettering's attitude. And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
- bananapub 3y ago
  > and that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning. er...what on earth are you talking about? as far as I recall, people complained about Lennart because: 1. they didn't like his attitude (lol) 2. they didn't want "init" to do so much, which was mostly just people not bothering to actually look into systemd-the-binary vs systemd-the-project was 3. random specific technical complaints like journald not using plain text or unit files being ini files or whatever edit: typo > it's the ultimate fuck you to people who believed in Linux since the beginning. out of interest, when in the 90's do you feel this was? does it only apply to people who used slackware 1.0? or just SLS users? or does one have to have received a tarball from Lars directly?
- pengaru 3y ago
  > And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning. I'm sure Lennart was thinking about maximizing tribal offense while evaluating his stable employment options in the midst of RedHat's obvious decline. The list of employers for a full-time upstream systemd maintainer at a competitive salary is rather short. And none of them are particularly attractive in terms of how dirty you'll feel having their logo on your paychecks.

_jal 3y ago

Personally I'm much more annoyed by taking control of how I partition my fucking drives. Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.

tjoff 3y ago
How does it do that?
- _jal 3y ago
  By making Linux less attractive to me.
  - tjoff 3y ago
    I meant, how does it dictate partition layout/xxx?
    - SAI_Peregrinus 3y ago
      It doesn't. If you are using GPT instead of MBR partitioning, AND you use particular partition type UUIDs that SystemD has reserved, THEN you can skip creating an /etc/fstab, and systemd will be able to mount the partitions where their type IDs indicate. If you do choose to create an /etc/fstab that will override the partition type IDs.
- jauntywundrkind 3y ago
  It has great optional support for Discoverable Partitions, which has made writing custom kernel cmdline's optional. https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ https://uapi-group.org/specifications/specs/discoverable_par... Systems is also are deprecating non merged-/usr.

pwdisswordfishc 3y ago

What is it exactly that is being deprecated here? systemd-sysv-generator? If the unit generator interface is stable, what's to stop downstream distributions from keeping using it regardless?

op00to 3y ago
I think it’s being able to have stuff in /etc/init.d that show up as services in SystemD.
bravetraveler 3y ago
That's my read/thought too. The generator is lost, and distributions will probably be carrying an analogue forward -- for benefit of third party relics. I don't believe it makes much more assumption than... $script {start,stop,restart} as the Exec lines in the unit The hairy part is how package scriptlets and so on that assume SysV/want old utilities -- eg: chkconfig, service. systemd captured these, and that may go away too

bananapub 3y ago

discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whinging about imagined architecture decisions (like "systemd is a monolith") and then conspiracies about Microsoft like it's a slashdot thread in 1998. notably missing: - discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable - discussion about how making containerisation/chroot/resource limits trivial is good actually - reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux etc etc

sophacles 3y ago
Don't forget the single biggest problem of sysvinit: Making services start in a deterministic order when the appropriate (and necessary) resources are actually available.
- bananapub 3y ago
  dunno what you mean, my "start) sleep 15" works fine most of the time !
ElectricalUnion 3y ago
I would add - making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it. Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects. Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.