15 ms·

Systemd v227

66 points by vezzy-fnord 11y ago

nailer 11y ago
I really like systemd. My blog has a 10 line .service file. My app has a 10 line .service file. My load balancer has a 10 line service file. They're way less brittle than bash scripts would have been. Stdout automatically becomes logs with the service name attached. It's nice.
- ibrahima 11y ago
  Upstart is pretty similarly easy to use in my limited experience with it. Definitely a nice idea to have stdout just automatically go to a log file.
  - justizin 11y ago
    Basically DJB did this in the 90s with daemontools, which many of us now use a revamped fork of called 'runit'. You still write shell scripts, but you also still have control. Again, I'm not entirely opposed to the ideas behind systemd, but I am opposed to basically every fucking Linux server distribution breaking because of things people are doing for the desktop, which began with upstart. There is also no love left to lose between me and sysV init scripts.
    - nailer 11y ago
      I love djb's stuff - he has his own concepts of everything, though, including the FHS, which makes his stuff hard to run on regular Linux distros. If there was a djb Linux I'd definitely install it.
      - vezzy-fnord 11y ago
        systemd has its own FHS requirements, as well: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... The only difference is acceptance.
        mercurial 11y ago
        But Nixos, which doesn't follow the FHS, still uses systemd...
        vezzy-fnord 11y ago
        Sure, much in the same way you can use daemontools without strictly following its FHS requirements. Or more likely you'd be using one of its many derivatives, as vanilla daemontools is rather old by now.
- justizin 11y ago
  Your system now has millions of more lines of code that few people understand which are vulnerable to privilege escalation, unfortunately. :/ I mean, you could just use Heroku, for free, most likely, to host what you are doing. Should all UNIX become Heroku? What happens if your blog starts doing a billion page views a day? When one of the systemd processes is taking up 95% CPU, what do you do? I'm not saying it's bad, I'm saying these are the type of concerns its' critics have. I am a fan of a lot of the ideas. I have downgraded several Linux systems which I needed To Work(tm) because of systemd being completely half-assed, and there are some great audits of its' code which make it appear to have been written by kindergarten students.
  - deleted 11y ago
    [deleted]
  - nailer 11y ago
    I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality, and around 30x 50-line shell scripts.
    - vezzy-fnord 11y ago
      There we go with the false dichotomy that just won't die again. It's pretty obvious you're not actually acquainted with the problem domain. Keep using whatever makes you feel comfortable, though.
      - deleted 11y ago
        [deleted]
        vezzy-fnord 11y ago
        Anyone who brings up sysvinit and the "30x 50-line shell scripts" is clearly one whose perception is limited to the ad-hoc LSB-based sysvinit setups that once permeated GNU/Linux, but which have always been merely one relatively inefficient approach. Even back when Debian first introduced their sysv-rc, we already had IBM SRC, daemontools, simpleinit and NetBSD rc.d which showed different solutions. EDIT: Let me join in on the moaning about downvotes. Not that I understand why.
- hoodoof 11y ago
  Can you post your 10 lines for us to see?
  - rsync 11y ago
    Yes, please - genuinely interested.
    - nailer 11y ago
      Sure. [Unit] Description=Blah app [Service] ExecStart=/var/www/blah/bin/www Restart=always User=nobody Group=nobody Environment=PATH=/usr/bin:/usr/local/bin Environment=NODE_ENV=production WorkingDirectory=/var/www/blah [Install] WantedBy=multi-user.target
      - heinrich5991 11y ago
        Starting as nobody is probably not a good idea if you have more than one service which does that. They'll be able to interact.
        hoodoof 11y ago
        Could you please explain in more details the issues here and the right way to do it?
        vacri 11y ago
        With two applications running under the same user, if one is compromised, it has ready access to the other. Generally it's fairly easy to make a system user for an application if no special accesses are required - just make a custom system user for the application, and ensure it can access the various things it needs to touch (eg: logging).
        JdeBP 11y ago
        ... and if you want to learn more than has been already said, start with the famous design of qmail as a collection of mutually untrusting daemons that run under individual unprivileged user accounts, precisely to insulate each from the others using the normal operating system mechanisms that insulate one user's processes, files, directories, and so forth from another's. A good question to ask yourself: "Presume that my daemon is compromised by an attacker ... * ... what processes can it trace, debug, read/write the memory spaces and environments of, or send signals to?" * ... what files, devices, and directories can it read and write?" * ... what files, devices, and directories does it own, and can thus grant access to?" Then ask: "How does the answer change if instead of all of my daemons running as the same (even if unprivileged) user they each run as different users, some (where appropriate) having no write access to anything and owning no files nor directories at all?"
- vezzy-fnord 11y ago
  OpenBSD: #!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1 Though, it's Korn shell, not Bash, I suppose. Reliable per-service logging was largely perfected by multilog. Judging complexity by observing external configuration is nonetheless exceptionally naive. One must factor in how the key-value pairs are built into an internal representation and dispatched, which is where things become an issue. Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs.
  - justizin 11y ago
    > Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs. Yeah, also something I found annoying with Upstart's induction into Ubuntu. A predecessor at a place I worked at with a huge amount of traffic installed Ubuntu 9 on all of our memcache servers, and we found on a handful of other machines installed with Ubuntu 9 that non-deterministic boot order would randomly cause them to fail booting, and it was a coin-flip whether that would be a one-off problem or a forever problem requiring a reinstall. When you have 4 8GB machines (this was some years ago) powering memcache for a billion requests a day you don't really want a power cycle to cause 25% cache misses for hours as you wrestle with hardware and boot config. :/
    - vezzy-fnord 11y ago
      Upstart doesn't have a formal dependency system, instead it orders things based on named preconditions and postconditions called events. Though these can be used to fulfill ordering requirements, I'd wager the information wasn't granular enough for parallelization to be efficient. Actually the main problem is that a lot of modern systems do not make their dependency graphs well observable, but instead treat them as in-memory ephemera that are constantly recalculated and cannot e.g. be written to persistent storage as known-good checkpoints. This is one area where s6-rc gets it right. You have to compile a manifest of your service dependencies and consistently boot from that well-known state, so for any changes it must be regenerated. serel was an earlier example of a service dependency system and parallel launcher which directly had you specify the nodes and edges of a directed graph as an RDF manifest. Clever.
- ck2 11y ago
  Except you cannot extend them in any way, unlike a real bash script (init.d) Try having a dozen different types of config-test for different programs, there is no way to extend ala ExecConfigTest
  - wstrange 11y ago
    If you really want to wrap your service startup in a bash script, I don't think systemd precludes that approach.
    - simoncion 11y ago
      But, that's kinda the thing... Folks gush about how concise systemd unit files are. For services that require no complicated pre-start checks or configuration, equivalent service start scripts are more concise and just as legible in either OpenRC or -AIUI- Upstart. (Look at my conversion of a simple systemd unit file [0] to an OpenRC init script. [1]) What's more, for jobs that need complicated pre-start logic of one kind or another -AIUI- systemd provides no way to bundle that logic with your service description file. You have to put that logic in another script file which is then called by systemd. EDIT: I can't speak to Upstart, but even if your service has dependencies or needs to be started before or after some other service or class of service, [2] specifying them is similarly concise and legible. Add depend() { use some_optional_service need some_requred_service before some_service_or_service_class after some_other_service_or_srv_class } somewhere near the top of your script. For most services, this adds three non-whitespace lines. :) [0] https://news.ycombinator.com/item?id=10355588 https://news.ycombinator.com/item?id=10355588 [1] https://news.ycombinator.com/item?id=10357010 https://news.ycombinator.com/item?id=10357010 [2] For example: The network start scripts provide the "net" service. You might have a service that -for some reason- needs to start before or after the "net" service, but doesn't actually depend on it to start. This is what "before" and "after" are used for.
- mercurial 11y ago
  I love the systemd principles, as they were outlined by Poettering in the initial announcement. Configuration files instead of boilerplate shell script (and worse, shell script with special comments), socket-based startup, massive parallelism, cgroups, the end of PID files... I just wish systemd itself had stayed there and that the additional functionalities it keeps developing lived in separate projects with well-defined interfaces.
  - vezzy-fnord 11y ago
    I find it disputable that parallelism is all that desirable. In systemd's case it requires the introduction of the dependency system with its multifaceted job queueing modes and transaction management that easily make up its most brittle edges, at least w.r.t. to its service manager, specifically. Seemingly innocuous configurations can result in cyclical transactions and dependency loops, and the internal graph engine bookkeeping these relationships provides very little debugging context at all. Considering parallelism is about startup optimization, a much better option is to load a process from a checkpoint image, e.g. one taken by CRIU or DMTCP.
    - simoncion 11y ago
      > ...a much better option is to load a process from a checkpoint image, e.g. one taken by CRIU or DMTCP. Almost completely unrelated: Two things that came out of the LKML examination of kdbus during the 4.1 merge request were: 1) kdbus makes assumptions that break CRIU and similar projects 2) The kdbus people didn't seem to care much about this fact So... the "ultimate" systemd setup may very well preclude the use of process checkpointers to speed up startup. :(
      - vezzy-fnord 11y ago
        Wow, I wasn't aware of that. Do you have a reference?
        simoncion 11y ago
- _ak 11y ago
  Those are not unique systemd features. supervisor provides that, as well, without requiring to replace the init system underneath.
deleted 11y ago
[deleted]
- Karunamon 11y ago
  500k in systemd itself, or inclusive of all the systemd-something pieces which, when debating with most, are part of it when convenient and separate when not? It's not in question that systemd is infinitely more complicated than equivalent sysv or other script-based init system. Complexity means attack surface.
  - deleted 11y ago
    [deleted]
    - Karunamon 11y ago
      I wasn't aware it was in question a more complicated system is more difficult to throughly audit, and therefore more likely to have bugs, security bugs being a subclass of bug? Unless the systemd devs are immune to the same problems that plague literally every other software developer
      - deleted 11y ago
        [deleted]
        Karunamon 11y ago
        I do not need to point at a specific security hole to prove the statement "more complex code is more susceptible to bugs".
        deleted 11y ago
        [deleted]
        Karunamon 11y ago
        Apparently, we're speaking Lojban here, not English, so therefore I'm not allowed to use figures of speech as they may be evaluated pedantically by those who wish to win an argument in bad faith. But fine, you wanted numbers. First, systemd's LoC count is 699,342 across 1,912 files as of a git clone of their SCM[1] and gitstats five minutes ago. That number was around 550,000 back in May[2], so kindly update your knowledge before regurgitating it mindlessly. Debian's (sid) sysvinit package[3], by the same methodology, is 32,151 lines across 235 files. Systemd is therefore about 22x (21.75179621162639) more complicated than sysv. I'd go run the numbers for Upstart, but I'm not going to go download bzr and appropriate profiling tool to conclusively prove something that's common knowledge to anyone not in an internet argument. And kindly stop complaining about downvotes - it's against the site rules. [1]:http://anongit.freedesktop.org/git/systemd/systemd.git http://anongit.freedesktop.org/git/systemd/systemd.git [2]:http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM [3]:https://anonscm.debian.org/git/collab-maint/sysvinit.git https://anonscm.debian.org/git/collab-maint/sysvinit.git
ck2 11y ago
I'm expecting SystemDos any month now. Let's see he can take over cron and make it 10 times more complicated... what else is left...
- dijit 11y ago
  They have a bootloader now. I'm sure this is very beneficial for certain types of people.. my developer friends who are becoming sysadmins by way of 'devops' like systemd quite a lot. Me? I've gone to freeBSD for personal things; until Apple successfully pushes launchd upstream.. If you want to see how far spread systemd is actually becoming install arch linux using the official guides.. it's very easy to set up- but you definitely can see how it's "everything that isn't linux that your computer needs to be functional"- I'm sure they'll have a wayland fork in no time.
  - simoncion 11y ago
    > They have a bootloader now. The systemd people have a Grub/Grub2/LILO replacement!? Would you be so kind as to link to details? :)
    - creshal 11y ago
      gummiboot has been integrated as reference implementation of systemd's bootloader interface. It's (unsurprisingly) much simpler than GRUB2 (as is every other bootloader in past, present, and presumably the near future).
    - mburns 11y ago
      https://en.wikipedia.org/wiki/Gummiboot_(software) https://en.wikipedia.org/wiki/Gummiboot_(software) now called systemd-boot
  - oofabz 11y ago
    Apple shipped launchd and made it open source ten years ago. They did their part, it's now FreeBSD's job to integrate the code.
rodgerd 11y ago
Quite an interesting update. Good to see ripping and replacing of code with external deps where needed, and exposing some more kernel functionality (around cgroups especially). Pity the comments are largely the usual moronic and entirely non-technical nonsense that infests the topic at HN. Sub-reddit commentary quality.
- vezzy-fnord 11y ago
  Pity the comments are largely the usual moronic and entirely non-technical nonsense that infests the topic at HN. I'd think I and others have been trying to inject some reasonable commentary. Any objections, or are we out on a political vendetta as is usual with systemd?
  - rodgerd 11y ago
    Perhaps I missed it amongst the reasonable commentary about the "millions of lines of insecure code" or the SystemDos snark?
- codewaffle 11y ago
  The negative comments are all one guy.
eloy 11y ago
http://syste.md http://syste.md
creshal 11y ago
Am I the only one who likes systemd? No more problems with overflowing logfiles, no more debugging undocumented shell scripts for booting, no more writing init scripts, no more debugging undocumented 200+ line init scripts, no more minute-long boot delays, no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts), ... For me as sysadmin, systemd solved a lot of long-standing problems, while so far introducing no new ones.
- vezzy-fnord 11y ago
  No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. no more debugging undocumented shell scripts for booting no more writing init scripts no more debugging undocumented 200+ line init scripts Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1]. no more minute-long boot delays Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc. no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts) Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad). [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
  - creshal 11y ago
    Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).
carlosrg 11y ago
PSA: Beware people running Debian Unstable and possibly other rolling release distros, lightdm seems to fail with 227. Be ready to downgrade if needed.
JdeBP 11y ago
I did enjoy that the mention of it being policy to avoid unnecessary abbreviations was immediately followed by two unnecessary abbreviations of the word "compatibility". I suspect that to have been deliberate. (-:

66 points by vezzy-fnord 11y ago

I really like systemd. My blog has a 10 line .service file. My app has a 10 line .service file. My load balancer has a 10 line service file. They're way less brittle than bash scripts would have been. Stdout automatically becomes logs with the service name attached. It's nice.

ibrahima 11y ago
Upstart is pretty similarly easy to use in my limited experience with it. Definitely a nice idea to have stdout just automatically go to a log file.
- justizin 11y ago
  Basically DJB did this in the 90s with daemontools, which many of us now use a revamped fork of called 'runit'. You still write shell scripts, but you also still have control. Again, I'm not entirely opposed to the ideas behind systemd, but I am opposed to basically every fucking Linux server distribution breaking because of things people are doing for the desktop, which began with upstart. There is also no love left to lose between me and sysV init scripts.
  - nailer 11y ago
    I love djb's stuff - he has his own concepts of everything, though, including the FHS, which makes his stuff hard to run on regular Linux distros. If there was a djb Linux I'd definitely install it.
    - vezzy-fnord 11y ago
      systemd has its own FHS requirements, as well: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... The only difference is acceptance.
      - mercurial 11y ago
        But Nixos, which doesn't follow the FHS, still uses systemd...
        vezzy-fnord 11y ago
        Sure, much in the same way you can use daemontools without strictly following its FHS requirements. Or more likely you'd be using one of its many derivatives, as vanilla daemontools is rather old by now.
justizin 11y ago
Your system now has millions of more lines of code that few people understand which are vulnerable to privilege escalation, unfortunately. :/ I mean, you could just use Heroku, for free, most likely, to host what you are doing. Should all UNIX become Heroku? What happens if your blog starts doing a billion page views a day? When one of the systemd processes is taking up 95% CPU, what do you do? I'm not saying it's bad, I'm saying these are the type of concerns its' critics have. I am a fan of a lot of the ideas. I have downgraded several Linux systems which I needed To Work(tm) because of systemd being completely half-assed, and there are some great audits of its' code which make it appear to have been written by kindergarten students.
- deleted 11y ago
  [deleted]
- nailer 11y ago
  I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality, and around 30x 50-line shell scripts.
  - vezzy-fnord 11y ago
    There we go with the false dichotomy that just won't die again. It's pretty obvious you're not actually acquainted with the problem domain. Keep using whatever makes you feel comfortable, though.
    - deleted 11y ago
      [deleted]
      - vezzy-fnord 11y ago
        Anyone who brings up sysvinit and the "30x 50-line shell scripts" is clearly one whose perception is limited to the ad-hoc LSB-based sysvinit setups that once permeated GNU/Linux, but which have always been merely one relatively inefficient approach. Even back when Debian first introduced their sysv-rc, we already had IBM SRC, daemontools, simpleinit and NetBSD rc.d which showed different solutions. EDIT: Let me join in on the moaning about downvotes. Not that I understand why.
hoodoof 11y ago
Can you post your 10 lines for us to see?
- rsync 11y ago
  Yes, please - genuinely interested.
  - nailer 11y ago
    Sure. [Unit] Description=Blah app [Service] ExecStart=/var/www/blah/bin/www Restart=always User=nobody Group=nobody Environment=PATH=/usr/bin:/usr/local/bin Environment=NODE_ENV=production WorkingDirectory=/var/www/blah [Install] WantedBy=multi-user.target
    - heinrich5991 11y ago
      Starting as nobody is probably not a good idea if you have more than one service which does that. They'll be able to interact.
      - hoodoof 11y ago
        Could you please explain in more details the issues here and the right way to do it?
        vacri 11y ago
        With two applications running under the same user, if one is compromised, it has ready access to the other. Generally it's fairly easy to make a system user for an application if no special accesses are required - just make a custom system user for the application, and ensure it can access the various things it needs to touch (eg: logging).
        JdeBP 11y ago
        ... and if you want to learn more than has been already said, start with the famous design of qmail as a collection of mutually untrusting daemons that run under individual unprivileged user accounts, precisely to insulate each from the others using the normal operating system mechanisms that insulate one user's processes, files, directories, and so forth from another's. A good question to ask yourself: "Presume that my daemon is compromised by an attacker ... * ... what processes can it trace, debug, read/write the memory spaces and environments of, or send signals to?" * ... what files, devices, and directories can it read and write?" * ... what files, devices, and directories does it own, and can thus grant access to?" Then ask: "How does the answer change if instead of all of my daemons running as the same (even if unprivileged) user they each run as different users, some (where appropriate) having no write access to anything and owning no files nor directories at all?"
vezzy-fnord 11y ago
OpenBSD: #!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1 Though, it's Korn shell, not Bash, I suppose. Reliable per-service logging was largely perfected by multilog. Judging complexity by observing external configuration is nonetheless exceptionally naive. One must factor in how the key-value pairs are built into an internal representation and dispatched, which is where things become an issue. Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs.
- justizin 11y ago
  > Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs. Yeah, also something I found annoying with Upstart's induction into Ubuntu. A predecessor at a place I worked at with a huge amount of traffic installed Ubuntu 9 on all of our memcache servers, and we found on a handful of other machines installed with Ubuntu 9 that non-deterministic boot order would randomly cause them to fail booting, and it was a coin-flip whether that would be a one-off problem or a forever problem requiring a reinstall. When you have 4 8GB machines (this was some years ago) powering memcache for a billion requests a day you don't really want a power cycle to cause 25% cache misses for hours as you wrestle with hardware and boot config. :/
  - vezzy-fnord 11y ago
    Upstart doesn't have a formal dependency system, instead it orders things based on named preconditions and postconditions called events. Though these can be used to fulfill ordering requirements, I'd wager the information wasn't granular enough for parallelization to be efficient. Actually the main problem is that a lot of modern systems do not make their dependency graphs well observable, but instead treat them as in-memory ephemera that are constantly recalculated and cannot e.g. be written to persistent storage as known-good checkpoints. This is one area where s6-rc gets it right. You have to compile a manifest of your service dependencies and consistently boot from that well-known state, so for any changes it must be regenerated. serel was an earlier example of a service dependency system and parallel launcher which directly had you specify the nodes and edges of a directed graph as an RDF manifest. Clever.
ck2 11y ago
Except you cannot extend them in any way, unlike a real bash script (init.d) Try having a dozen different types of config-test for different programs, there is no way to extend ala ExecConfigTest
- wstrange 11y ago
  If you really want to wrap your service startup in a bash script, I don't think systemd precludes that approach.
  - simoncion 11y ago
    But, that's kinda the thing... Folks gush about how concise systemd unit files are. For services that require no complicated pre-start checks or configuration, equivalent service start scripts are more concise and just as legible in either OpenRC or -AIUI- Upstart. (Look at my conversion of a simple systemd unit file [0] to an OpenRC init script. [1]) What's more, for jobs that need complicated pre-start logic of one kind or another -AIUI- systemd provides no way to bundle that logic with your service description file. You have to put that logic in another script file which is then called by systemd. EDIT: I can't speak to Upstart, but even if your service has dependencies or needs to be started before or after some other service or class of service, [2] specifying them is similarly concise and legible. Add depend() { use some_optional_service need some_requred_service before some_service_or_service_class after some_other_service_or_srv_class } somewhere near the top of your script. For most services, this adds three non-whitespace lines. :) [0] https://news.ycombinator.com/item?id=10355588 https://news.ycombinator.com/item?id=10355588 [1] https://news.ycombinator.com/item?id=10357010 https://news.ycombinator.com/item?id=10357010 [2] For example: The network start scripts provide the "net" service. You might have a service that -for some reason- needs to start before or after the "net" service, but doesn't actually depend on it to start. This is what "before" and "after" are used for.
mercurial 11y ago
I love the systemd principles, as they were outlined by Poettering in the initial announcement. Configuration files instead of boilerplate shell script (and worse, shell script with special comments), socket-based startup, massive parallelism, cgroups, the end of PID files... I just wish systemd itself had stayed there and that the additional functionalities it keeps developing lived in separate projects with well-defined interfaces.
- vezzy-fnord 11y ago
  I find it disputable that parallelism is all that desirable. In systemd's case it requires the introduction of the dependency system with its multifaceted job queueing modes and transaction management that easily make up its most brittle edges, at least w.r.t. to its service manager, specifically. Seemingly innocuous configurations can result in cyclical transactions and dependency loops, and the internal graph engine bookkeeping these relationships provides very little debugging context at all. Considering parallelism is about startup optimization, a much better option is to load a process from a checkpoint image, e.g. one taken by CRIU or DMTCP.
  - simoncion 11y ago
    > ...a much better option is to load a process from a checkpoint image, e.g. one taken by CRIU or DMTCP. Almost completely unrelated: Two things that came out of the LKML examination of kdbus during the 4.1 merge request were: 1) kdbus makes assumptions that break CRIU and similar projects 2) The kdbus people didn't seem to care much about this fact So... the "ultimate" systemd setup may very well preclude the use of process checkpointers to speed up startup. :(
    - vezzy-fnord 11y ago
      Wow, I wasn't aware of that. Do you have a reference?
      - simoncion 11y ago
_ak 11y ago
Those are not unique systemd features. supervisor provides that, as well, without requiring to replace the init system underneath.

deleted 11y ago

[deleted]

Karunamon 11y ago
500k in systemd itself, or inclusive of all the systemd-something pieces which, when debating with most, are part of it when convenient and separate when not? It's not in question that systemd is infinitely more complicated than equivalent sysv or other script-based init system. Complexity means attack surface.
- deleted 11y ago
  [deleted]
  - Karunamon 11y ago
    I wasn't aware it was in question a more complicated system is more difficult to throughly audit, and therefore more likely to have bugs, security bugs being a subclass of bug? Unless the systemd devs are immune to the same problems that plague literally every other software developer
    - deleted 11y ago
      [deleted]
      - Karunamon 11y ago
        I do not need to point at a specific security hole to prove the statement "more complex code is more susceptible to bugs".
        deleted 11y ago
        [deleted]
        Karunamon 11y ago
        Apparently, we're speaking Lojban here, not English, so therefore I'm not allowed to use figures of speech as they may be evaluated pedantically by those who wish to win an argument in bad faith. But fine, you wanted numbers. First, systemd's LoC count is 699,342 across 1,912 files as of a git clone of their SCM[1] and gitstats five minutes ago. That number was around 550,000 back in May[2], so kindly update your knowledge before regurgitating it mindlessly. Debian's (sid) sysvinit package[3], by the same methodology, is 32,151 lines across 235 files. Systemd is therefore about 22x (21.75179621162639) more complicated than sysv. I'd go run the numbers for Upstart, but I'm not going to go download bzr and appropriate profiling tool to conclusively prove something that's common knowledge to anyone not in an internet argument. And kindly stop complaining about downvotes - it's against the site rules. [1]:http://anongit.freedesktop.org/git/systemd/systemd.git http://anongit.freedesktop.org/git/systemd/systemd.git [2]:http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM [3]:https://anonscm.debian.org/git/collab-maint/sysvinit.git https://anonscm.debian.org/git/collab-maint/sysvinit.git

ck2 11y ago

I'm expecting SystemDos any month now. Let's see he can take over cron and make it 10 times more complicated... what else is left...

dijit 11y ago
They have a bootloader now. I'm sure this is very beneficial for certain types of people.. my developer friends who are becoming sysadmins by way of 'devops' like systemd quite a lot. Me? I've gone to freeBSD for personal things; until Apple successfully pushes launchd upstream.. If you want to see how far spread systemd is actually becoming install arch linux using the official guides.. it's very easy to set up- but you definitely can see how it's "everything that isn't linux that your computer needs to be functional"- I'm sure they'll have a wayland fork in no time.
- simoncion 11y ago
  > They have a bootloader now. The systemd people have a Grub/Grub2/LILO replacement!? Would you be so kind as to link to details? :)
  - creshal 11y ago
    gummiboot has been integrated as reference implementation of systemd's bootloader interface. It's (unsurprisingly) much simpler than GRUB2 (as is every other bootloader in past, present, and presumably the near future).
  - mburns 11y ago
    https://en.wikipedia.org/wiki/Gummiboot_(software) https://en.wikipedia.org/wiki/Gummiboot_(software) now called systemd-boot
- oofabz 11y ago
  Apple shipped launchd and made it open source ten years ago. They did their part, it's now FreeBSD's job to integrate the code.

rodgerd 11y ago

Quite an interesting update. Good to see ripping and replacing of code with external deps where needed, and exposing some more kernel functionality (around cgroups especially). Pity the comments are largely the usual moronic and entirely non-technical nonsense that infests the topic at HN. Sub-reddit commentary quality.

vezzy-fnord 11y ago
Pity the comments are largely the usual moronic and entirely non-technical nonsense that infests the topic at HN. I'd think I and others have been trying to inject some reasonable commentary. Any objections, or are we out on a political vendetta as is usual with systemd?
- rodgerd 11y ago
  Perhaps I missed it amongst the reasonable commentary about the "millions of lines of insecure code" or the SystemDos snark?
codewaffle 11y ago
The negative comments are all one guy.

eloy 11y ago

http://syste.md http://syste.md

creshal 11y ago

Am I the only one who likes systemd? No more problems with overflowing logfiles, no more debugging undocumented shell scripts for booting, no more writing init scripts, no more debugging undocumented 200+ line init scripts, no more minute-long boot delays, no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts), ... For me as sysadmin, systemd solved a lot of long-standing problems, while so far introducing no new ones.

vezzy-fnord 11y ago
No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. no more debugging undocumented shell scripts for booting no more writing init scripts no more debugging undocumented 200+ line init scripts Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1]. no more minute-long boot delays Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc. no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts) Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad). [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
- creshal 11y ago
  Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).

carlosrg 11y ago

PSA: Beware people running Debian Unstable and possibly other rolling release distros, lightdm seems to fail with 227. Be ready to downgrade if needed.

JdeBP 11y ago

I did enjoy that the mention of it being policy to avoid unnecessary abbreviations was immediately followed by two unnecessary abbreviations of the word "compatibility". I suspect that to have been deliberate. (-: