12 ms·

Count me as a systemd convert

116 points by KKKKkkkk1 10y ago

api 10y ago
IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess. An improvement would be something with modern syntax, sparse features, and good docs.
- secstate 10y ago
  Amen sir. Seems crazy that the tipping point for the OP was being able to require certain services to have come up before others. That seems a fairly elementary aspect of process supervision. For my money, runit gets the nod for modern syntax, sparse feature ... docs are coming along ;)
- exabrial 10y ago
  My personal opinion is it's Redhat's way of seizing control of the Linux ecosystem... But that's a fringe theory
  - felixgallo 10y ago
    hardly fringe -- it's straight out of the unix wars historical playbook. Every unix vendor tried to make their own conflicting systems in order to promote lock-in. Solaris, AIX, DG/UX, SCO, everyone, all the time. That it's taken so long in the Linux space is pretty amazing, but of course that it's happening is super depressing.
    - marcosdumay 10y ago
      That requires the systems to be proprietary, and, well, conflicting. Systemd isn't proprietary, and with everybody's adoption it's now universal, not conflicting. I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.
      - michaelmrose 10y ago
        Conway's law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories. Its simultaneously possible that such a complex solution is sub optimal for other parties. They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions. Its entirely possible for two parties to disagree without either being evil.
        digi_owl 10y ago
        In regards to this, i ran into a blog posting over at blogs.gnome.org, about Fedora's workstation project. That alone should raise some red flags about mixing roles. But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts. But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.
      - nickpsecurity 10y ago
        "That requires the systems to be proprietary, and, well, conflicting." No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.
        zanny 10y ago
        But this kind of competition, or even intent behind a product, is thus not unethical or harmful to the users. Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it. Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.
  - AckSyn 10y ago
    Personally, I'm waiting for Linus Torvalds to make his own init system in the event he's fed up with all the sysvinit and systemd bullshit. Linux Kernel. Git. $torvaldsinitsystem ?
    - ktRolster 10y ago
      He's not going to because it doesn't affect him personally. And let's be honest, systemd isn't that bad, and has some benefits. It's not worth getting religious over. You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.
    - deleted 10y ago
      [deleted]
    - txutxu 10y ago
      I could see sysvinit as $torvaldsinitsystem because it has been booting linux around the world... Git did start as a tool, and has been extended, a lot. The same than the kernel booting was extended across the years to cover usage cases. If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.
    - TheyW0ntL1sten 10y ago
      He's actually said that he doesn't think that systemd is that bad. He didn't like the way that they submitted patches initially. He said that he doesn't have a problem with the approach and he said that people make too much of the "unix philosophy" because passing bits of text between programs really hasn't been the way that unix systems have been designed for several decades.
- pmoriarty 10y ago
  Have you tried runit?[1] [1] - http://smarden.org/runit/ http://smarden.org/runit/
- SEJeff 10y ago
  On your Linux system, type: man -k systemd There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post. Also, the syntax is consistent and documented. It is infinitely simpler than sysvinit. Either you're trolling, or know very little about systemd. Note that I'm a fan, but far from an apologist.
  - ktRolster 10y ago
    Here's the documentation for systemd-random-seed: https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html https://www.freedesktop.org/software/systemd/man/systemd-ran... What are the command-line options that are available to that tool? Without looking in the source code. >Note that I'm a fan, but far from an apologist. An apologist is merely someone who offers a defense of something. It comes from the greek word ἀπολογία, "speaking in defense". Thus you are an apologist, even though you're not dogmatic.
    - SEJeff 10y ago
      Ok I'll give you that. Also up vote for the pedantic retort. Well written, and I don't know Greek, so I learned something new. Look at the docs for something like systemd-service or -exec or -tmpfiles, etc. You found one that as bad. I'm sure you can find a few more. Now find docs for some random 1000 line shell scripts that aren't the code. At least there is a very obvious and consistent way to set the ulimit for my services, even if they don't support pam_limits via systemd, or an obvious way to extend the start script without hacking up the init file, etc. Please allow me to rephrase and say the documentation overall is so far ahead of th documentation for any implementation of init scripts and sysvinit it isn't funny. And this is coming from someone who spent most of his career as a UNIX / Linux SysAdmin.
      - ktRolster 10y ago
        Also up vote for the pedantic retort. Nah, it wasn't meant as a retort. It was merely an aside that I thought you might find interesting. And apparently you did :)
- ams6110 10y ago
  http://man.openbsd.org/rcctl http://man.openbsd.org/rcctl
  - JdeBP 10y ago
    Because the BSDs don't agree amongst themselves on how services are configured in /etc/rc.conf , OpenBSD (whose tool this is) being a major outlier, this tool does not interoperate at all well with anything other than OpenBSD. For those with OpenBSD habits, there is a compatibility shim in the nosh toolset that translates to native nosh mechanisms. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/rcctl.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
- lomnakkus 10y ago
  > IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess. This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts. > An improvement would be something with modern syntax, sparse features, and good docs. This is getting pretty silly and it just looks like you're reaching for anything to criticize here. What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration? What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.) You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!). Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.) [1] http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
  - snuxoll 10y ago
    Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).
    - nitrogen 10y ago
      Ubuntu's Upstart was also pretty nice in this regard.
      - themartorana 10y ago
- txutxu 10y ago
  When I was a child, I did translate knoppix boot messages, to my mother language, for a local project. In colours. For me was great and rewarding, a nice learning experience, about livecd's initialization and linux in general at the time. I don't feel like I could have accomplished the same experience trying to do the same with systemd (with my age and knowledge and resources at the time). Still more difficult, being a Debian user, where systemd is not in the same shape than RHEL based distros, and documentation is out of sync, or missed in blogs... What you propose reminds me to openrc or the gentoo dependency based init system. I Love too the BSD/Slackware/busybox init style (single script init). But I'm a scripting mad. One of my reasons to live, of and for, opensource, is the ethics and freedom behind it. Other one was being more K.I.S.S. on my system interactions than with MS based products. I feel capital interests hurts some things very hard to obtain, in voluntary groups of people, using guerrilla warfare, and without any care. Eventually I've deployed some Debian stable (Jessie) systems with sysvinit this same year, and I'm grateful that people in Debian did that option possible. I'm not sure if a third, or a new option with modern syntax and sparse features as you say, could be better than the years we've been moving the world using sysvinit or upstart or others... but we, the tech people, seem to like new things! Totally agree about the docs care, specially when there are distributors involved. When there are changes in opensource, there should be a lot of more care IMHO than in closed products, and this is not always the case. Unfortunately people, by brain nature, is driven a lot by media and marketing, two weapons of venture capital techs. And if service providers insert X and media inserts X, people who did never maintain a critical and complex deployments using X and did integrate a lot of things with them, starts talking about the smell of the clouds. What implementation do you suggest, to reach what you propose? I think is not easy :) My main feature request could be: reliable and malleable (not easy too). > An improvement would be something with modern syntax, sparse features, and good docs. Loved your tower of babel mess definition, upvoted just by that comparison. Have a nice day.
  - JdeBP 10y ago
    > I'm not sure if a third, or a new option [...] as you say, could be better than the years we've been moving the world using sysvinit or upstart or others * 1. System 5 rc * 2. upstart * 3. systemd * 4. "third, new, option" The "Uselessd Guy" critiqued the thinking that underlies this strange way of counting to three that is being employed here, in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ . See also https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page.
pkaye 10y ago
I have to say that it is super fast to boot up with systemd. Maybe 2-3 seconds to boot to my Ubuntu desktop (excluding bios time.) I do use an SSD however.
- nitrogen 10y ago
  On embedded devices in the SheevaPlug family, it's a bit slower than the old init, presumably because it's doing a lot more stuff (and the OS is either on slow flash or a slow USB-to-SD card interface). It doesn't seem to scale down to small systems very well. I do like the colors, though.
  - ashitlerferad 10y ago
    systemd has boot profiling functionality, you might want to check out which part is slow.
    - nitrogen 10y ago
      There's always lots of text flying by on the console; it might not be traceable to one single slow part.
      - pkaye 10y ago
        Try "systemd-analyze plot >boot.svg" and it will produce a nice svg graph of how much time each step takes.
        briffle 10y ago
        I never knew that.. thanks, that is very interesting..
        majewsky 10y ago
        Also check out the other subcommands. For example, to find out why a certain service is taking long to start up, "systemd-analyze critical-chain $service"
oconnore 10y ago
I think the systemd complaints can essentially be reduced to "my init system now knows about cgroups, sockets, dbus, [and other things that didn't used to exist]". I haven't heard anyone offer a replacement that accounts for these features while maintaining "the Unix way".
- pdkl95 10y ago
  None of those feature require systemd. > cgroups Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect. > sockets We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business. > dbus Isn't necessary in the init process, though you're free to use it if you wish. > didn't used to exist Such as? > replacement for these features The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features. The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution. If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.
  - dredmorbius 10y ago
    Downvote brigades on factually correct posts you happen not to agree with aren't cricket.
    - TheyW0ntL1sten 10y ago
      Except that they are on this site and have been so I quit using a single account to ever post anything. If you are actually a contrarian good luck ever even getting to the point where you can downvote other posts.
      - dredmorbius 10y ago
        I do all right. State my piece, supply evidence, and avoid idiotic fights. There's always someone wrong on the Internet. #386.
combatentropy 10y ago
The choice isn't binary: sysvinit or systemd. There is a third way. I'm not much of a sysadmin, but I'm intrigued when I read of daemontools and its ilk. http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dae... http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
- deleted 10y ago
  [deleted]
- ashitlerferad 10y ago
  There are many more than 3 init systems. There are tens of them.
  - combatentropy 10y ago
    I meant three families, but you still may be right.
    - r0fls 10y ago
      Where does upstart stand in this? That's what I've used so far.
      - ashitlerferad 10y ago
        It is dead and gone, Canonical/Ubuntu abandoned it after Debian chose systemd and then Ubuntu did too.
  - vocatus_gate 10y ago
    There are dozens of us!!
- beagle3 10y ago
  There's also http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh/ http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... - a daemontools compatible, partially-systemd compatible init system.
toomanythings2 10y ago
>I still have serious misgivings I guess that kinda tells us more than anything else he said.
- kl4m 10y ago
  You cut the quote to change the meaning. "Although I still have serious misgivings about the systemd upstream’s attitude, I’ve got to say I find the system rather refreshing and useful in practice."
  - toomanythings2 10y ago
    There are misgivings none-the-less. A new system being "refreshing" is not a reason to use it. "Useful" is hardly a ringing endorsement. What disturbs me the most is that systemd takes Linux farther away from being a Unix-like system. Linux is now "Linux" and incompatible with anything else.
bbayles 10y ago
I didn't really know anything about init systems until 2014 (so I all but missed the systemd wars) when I found myself in need of process synchronization and supervision on various platforms. My task was pretty straightforward: I had a group of processes that need to start in a certain order, restart if they die, run as a non-root user, and write logs somewhere. I needed to support RHEL 5, 6, and 7, which all use different init systems (sysvinit, upstart, and systemd). I worked with all of them and also experimented with alternatives (runit, s6, Supervisor). For my task systemd was a pleasure to work with compared to the others. There was a bit of a learning curve, but once I mapped out what I needed to do the solution was obvious. I found upstart to be almost good, but the version that ships with RHEL 6 is lacking compared to the later versions that came with Ubuntu. The Python-based Supervisor was surprisingly good. I sort of saw why some people might like s6, but runit's charm was lost on me. sysvinit was by far the worst. I wound up using sysvinit to hand off to Supervisor in order to not spend my life worrying about the number of forks and pidfile locations. I can't speak to systemd's shortcomings and perceived hegemony in other areas, but when it comes to acting like an init system it is miles ahead of everything else.
nickysielicki 10y ago
This is maybe pedantic, but something that irks me about systemd is the way that systemctl commands are composed. I find myself doing this frequently > systemctl status someservice > systemctl stop someservice > systemctl edit someservice > systemctl daemon-reload > systemctl start someservice > systemctl status someservice > systemctl enable someservice Why make the operation the middle parameter? I understand that "systemctl start foo" more closely resembles the English sentence, "SystemD, please start the foo service", but I couldn't give two shits about that, and it's a dumb design decision. Any time that I am entering a systemctl command, I'm probably entering a series of 3 or more of them, and they're probably all related to the same service. Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument. It's a mess!
- chm 10y ago
  In Debian I use "service X action" which I also find preferable for the exact same reason you mention.
- dredmorbius 10y ago
  One-liner lists are handy: for service in <list> do; systemctl <action> <service>; done E.g., for system in foo bar baz; do systemctl stop $system; systemctl start $system; done ... will stop and start each of your named services. (This clearly extends far beyond systemd.)
  - hueving 10y ago
    But it accepts a list, so rather than write the loop: systemctl stop foo bar baz; systemctl start foo bar baz
    - vidarh 10y ago
      With the caveat that yours and the version above are not the same. With properly written systemd units (e.g. using the notification API to signal when it's actually operational) the former will have fully started foo again before stopping bar (ignoring the lack of error handling in both examples..). Which may or may not matter.
digi_owl 10y ago
One "interesting" tidbit about systemd is that the init part will keel over if dbus goes down, and if pid1 keels over you are looking at a kernel panic...
- kinkdr 10y ago
  I was bitten by this once. A typo in dbus configuration rendered my machine unbootable.
  - ZenoArrow 10y ago
    I wonder if issues like this were part of the reason the release of kdbus (dbus as a kernel module) was delayed.
    - tremon 10y ago
      kdbus is mainly delayed because the kernel devs are unconvinced. In the last thread I read (which was likely over a year ago), there were architectural issues with the design that nobody on the kdbus side was willing/able to fix or explain.
      - ZenoArrow 10y ago
        I thought one of the main kdbus devs was gregkh (one of the most senior Linux kernel maintainers), is that not the case? I did hear that there was due to be a redesign, but not sure what the issues were.
        lomnakkus 10y ago
        I believe this is the redesign: https://github.com/bus1/bus1 https://github.com/bus1/bus1 EDIT: Replaced with better link. (Old link: http://www.bus1.org/index.html http://www.bus1.org/index.html )
        JdeBP 10y ago
digi_owl 10y ago
https://news.ycombinator.com/item?id=11639659 https://news.ycombinator.com/item?id=11639659 Found this regarding programming languages (and JS in particular) a bit interesting in the middle of the whole systemd debate, as i wonder if it can be applied to unix as well. This in that unix have from the early days been made up of loosely coupled parts. This then allowed new parts to be introduced, tested, and either adopted widely or discarded as seen fit. Maybe even adopted in some areas but ignored in others. But you rarely ran into deep dependency chains. Systemd on the other hand is tightly coupled, continually sprouting new stuff, and foisted on the world via deep dependencies.
- creshal 10y ago
  > Systemd on the other hand is tightly coupled Not really. All its various components are loosely coupled over DBus, and most are entirely optional. There's no technical reason why people can't e.g. implement journald's API in syslog. Or replace the various userspace *ctls (timedatectl, hostnamectl, …), or reimplement logind on top of some BSD (already done, actually), …
  - digi_owl 10y ago
    You seem to be confusing the interface between systemd components and third parties, with internal interfaces. The latter are expressly non-documented, and non-stable, to allow the systemd devs to change them as they see fit. As for logind on BSD, got a link? Last i recall they were struggling because it was a sprawling and moving target (Consolekit2 is also having that problem). One example is that recently logind took over much fo the job upower used to do, with upower now being a compatibility wrapper around logind. Oh btw, dbus is massively more opaque that being able to run a command, look at the output, and then pipe that to another with the proper flags and such.
  - TheyW0ntL1sten 10y ago
    Dude, there's literally nothing you can say that will change people's mind on this subject. It has long since crossed into some kind of identity subject.
  - 10y ago
B1FF_PSUVM 10y ago
> I was debugging the boot on a server recently. It mounts a bunch of NFS filesystems Don't do that. It's a bag of hurt. (Still sore about the hours that workstations with not-working-fs mounts spent waiting for each other on boot after power failures, ages ago. Nevermore.)
- deleted 10y ago
  [deleted]
- ibotty 10y ago
  So you just don't use remote filesystems? That's a solution! Honestly, whenever the init system is configured correctly, you don't run into these problems all ops know a story about. It helps that systemd makes it easier to configure dependencies so that only the units depending on remote fs stall when it is unavailable.
  - TheyW0ntL1sten 10y ago
    One time I was writing this long story in a text editor that crashed so I stopped writing. Nevermore.
  - jabl 10y ago
    > So you just don't use remote filesystems? That's a solution! No, you mount them with autofs, of course.
    - snuxoll 10y ago
      autofs is great, combined with NFS4 and FreeIPA it's even not a total pain in the butt to configure on a whole farm of servers (having my home directory easily available with my ZSH configuration from every system I log into is great.)
    - karlshea 10y ago
      I found out about autofs when I was trying to figure out some SMB issues while mounting NAS shares on a media server. It was so ridiculously easy to set up. All of the "copy and paste" newbie answers always involve modifying fstab and there are always issues on boot, but autofs just works. It makes me wonder why it's not recommended as often.

116 points by KKKKkkkk1 10y ago

api 10y ago

IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess. An improvement would be something with modern syntax, sparse features, and good docs.

secstate 10y ago
Amen sir. Seems crazy that the tipping point for the OP was being able to require certain services to have come up before others. That seems a fairly elementary aspect of process supervision. For my money, runit gets the nod for modern syntax, sparse feature ... docs are coming along ;)
exabrial 10y ago
My personal opinion is it's Redhat's way of seizing control of the Linux ecosystem... But that's a fringe theory
- felixgallo 10y ago
  hardly fringe -- it's straight out of the unix wars historical playbook. Every unix vendor tried to make their own conflicting systems in order to promote lock-in. Solaris, AIX, DG/UX, SCO, everyone, all the time. That it's taken so long in the Linux space is pretty amazing, but of course that it's happening is super depressing.
  - marcosdumay 10y ago
    That requires the systems to be proprietary, and, well, conflicting. Systemd isn't proprietary, and with everybody's adoption it's now universal, not conflicting. I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.
    - michaelmrose 10y ago
      Conway's law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories. Its simultaneously possible that such a complex solution is sub optimal for other parties. They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions. Its entirely possible for two parties to disagree without either being evil.
      - digi_owl 10y ago
        In regards to this, i ran into a blog posting over at blogs.gnome.org, about Fedora's workstation project. That alone should raise some red flags about mixing roles. But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts. But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.
    - nickpsecurity 10y ago
      "That requires the systems to be proprietary, and, well, conflicting." No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.
      - zanny 10y ago
        But this kind of competition, or even intent behind a product, is thus not unethical or harmful to the users. Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it. Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.
- AckSyn 10y ago
  Personally, I'm waiting for Linus Torvalds to make his own init system in the event he's fed up with all the sysvinit and systemd bullshit. Linux Kernel. Git. $torvaldsinitsystem ?
  - ktRolster 10y ago
    He's not going to because it doesn't affect him personally. And let's be honest, systemd isn't that bad, and has some benefits. It's not worth getting religious over. You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.
  - deleted 10y ago
    [deleted]
  - txutxu 10y ago
    I could see sysvinit as $torvaldsinitsystem because it has been booting linux around the world... Git did start as a tool, and has been extended, a lot. The same than the kernel booting was extended across the years to cover usage cases. If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.
  - TheyW0ntL1sten 10y ago
    He's actually said that he doesn't think that systemd is that bad. He didn't like the way that they submitted patches initially. He said that he doesn't have a problem with the approach and he said that people make too much of the "unix philosophy" because passing bits of text between programs really hasn't been the way that unix systems have been designed for several decades.
pmoriarty 10y ago
Have you tried runit?[1] [1] - http://smarden.org/runit/ http://smarden.org/runit/
SEJeff 10y ago
On your Linux system, type: man -k systemd There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post. Also, the syntax is consistent and documented. It is infinitely simpler than sysvinit. Either you're trolling, or know very little about systemd. Note that I'm a fan, but far from an apologist.
- ktRolster 10y ago
  Here's the documentation for systemd-random-seed: https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html https://www.freedesktop.org/software/systemd/man/systemd-ran... What are the command-line options that are available to that tool? Without looking in the source code. >Note that I'm a fan, but far from an apologist. An apologist is merely someone who offers a defense of something. It comes from the greek word ἀπολογία, "speaking in defense". Thus you are an apologist, even though you're not dogmatic.
  - SEJeff 10y ago
    Ok I'll give you that. Also up vote for the pedantic retort. Well written, and I don't know Greek, so I learned something new. Look at the docs for something like systemd-service or -exec or -tmpfiles, etc. You found one that as bad. I'm sure you can find a few more. Now find docs for some random 1000 line shell scripts that aren't the code. At least there is a very obvious and consistent way to set the ulimit for my services, even if they don't support pam_limits via systemd, or an obvious way to extend the start script without hacking up the init file, etc. Please allow me to rephrase and say the documentation overall is so far ahead of th documentation for any implementation of init scripts and sysvinit it isn't funny. And this is coming from someone who spent most of his career as a UNIX / Linux SysAdmin.
    - ktRolster 10y ago
      Also up vote for the pedantic retort. Nah, it wasn't meant as a retort. It was merely an aside that I thought you might find interesting. And apparently you did :)
ams6110 10y ago
http://man.openbsd.org/rcctl http://man.openbsd.org/rcctl
- JdeBP 10y ago
  Because the BSDs don't agree amongst themselves on how services are configured in /etc/rc.conf , OpenBSD (whose tool this is) being a major outlier, this tool does not interoperate at all well with anything other than OpenBSD. For those with OpenBSD habits, there is a compatibility shim in the nosh toolset that translates to native nosh mechanisms. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/rcctl.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
lomnakkus 10y ago
> IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess. This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts. > An improvement would be something with modern syntax, sparse features, and good docs. This is getting pretty silly and it just looks like you're reaching for anything to criticize here. What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration? What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.) You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!). Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.) [1] http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
- snuxoll 10y ago
  Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).
  - nitrogen 10y ago
    Ubuntu's Upstart was also pretty nice in this regard.
    - themartorana 10y ago
txutxu 10y ago
When I was a child, I did translate knoppix boot messages, to my mother language, for a local project. In colours. For me was great and rewarding, a nice learning experience, about livecd's initialization and linux in general at the time. I don't feel like I could have accomplished the same experience trying to do the same with systemd (with my age and knowledge and resources at the time). Still more difficult, being a Debian user, where systemd is not in the same shape than RHEL based distros, and documentation is out of sync, or missed in blogs... What you propose reminds me to openrc or the gentoo dependency based init system. I Love too the BSD/Slackware/busybox init style (single script init). But I'm a scripting mad. One of my reasons to live, of and for, opensource, is the ethics and freedom behind it. Other one was being more K.I.S.S. on my system interactions than with MS based products. I feel capital interests hurts some things very hard to obtain, in voluntary groups of people, using guerrilla warfare, and without any care. Eventually I've deployed some Debian stable (Jessie) systems with sysvinit this same year, and I'm grateful that people in Debian did that option possible. I'm not sure if a third, or a new option with modern syntax and sparse features as you say, could be better than the years we've been moving the world using sysvinit or upstart or others... but we, the tech people, seem to like new things! Totally agree about the docs care, specially when there are distributors involved. When there are changes in opensource, there should be a lot of more care IMHO than in closed products, and this is not always the case. Unfortunately people, by brain nature, is driven a lot by media and marketing, two weapons of venture capital techs. And if service providers insert X and media inserts X, people who did never maintain a critical and complex deployments using X and did integrate a lot of things with them, starts talking about the smell of the clouds. What implementation do you suggest, to reach what you propose? I think is not easy :) My main feature request could be: reliable and malleable (not easy too). > An improvement would be something with modern syntax, sparse features, and good docs. Loved your tower of babel mess definition, upvoted just by that comparison. Have a nice day.
- JdeBP 10y ago
  > I'm not sure if a third, or a new option [...] as you say, could be better than the years we've been moving the world using sysvinit or upstart or others * 1. System 5 rc * 2. upstart * 3. systemd * 4. "third, new, option" The "Uselessd Guy" critiqued the thinking that underlies this strange way of counting to three that is being employed here, in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ . See also https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page.

pkaye 10y ago

I have to say that it is super fast to boot up with systemd. Maybe 2-3 seconds to boot to my Ubuntu desktop (excluding bios time.) I do use an SSD however.

nitrogen 10y ago
On embedded devices in the SheevaPlug family, it's a bit slower than the old init, presumably because it's doing a lot more stuff (and the OS is either on slow flash or a slow USB-to-SD card interface). It doesn't seem to scale down to small systems very well. I do like the colors, though.
- ashitlerferad 10y ago
  systemd has boot profiling functionality, you might want to check out which part is slow.
  - nitrogen 10y ago
    There's always lots of text flying by on the console; it might not be traceable to one single slow part.
    - pkaye 10y ago
      Try "systemd-analyze plot >boot.svg" and it will produce a nice svg graph of how much time each step takes.
      - briffle 10y ago
        I never knew that.. thanks, that is very interesting..
      - majewsky 10y ago
        Also check out the other subcommands. For example, to find out why a certain service is taking long to start up, "systemd-analyze critical-chain $service"

oconnore 10y ago

I think the systemd complaints can essentially be reduced to "my init system now knows about cgroups, sockets, dbus, [and other things that didn't used to exist]". I haven't heard anyone offer a replacement that accounts for these features while maintaining "the Unix way".

pdkl95 10y ago
None of those feature require systemd. > cgroups Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect. > sockets We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business. > dbus Isn't necessary in the init process, though you're free to use it if you wish. > didn't used to exist Such as? > replacement for these features The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features. The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution. If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.
- dredmorbius 10y ago
  Downvote brigades on factually correct posts you happen not to agree with aren't cricket.
  - TheyW0ntL1sten 10y ago
    Except that they are on this site and have been so I quit using a single account to ever post anything. If you are actually a contrarian good luck ever even getting to the point where you can downvote other posts.
    - dredmorbius 10y ago
      I do all right. State my piece, supply evidence, and avoid idiotic fights. There's always someone wrong on the Internet. #386.

combatentropy 10y ago

The choice isn't binary: sysvinit or systemd. There is a third way. I'm not much of a sysadmin, but I'm intrigued when I read of daemontools and its ilk. http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dae... http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/

deleted 10y ago
[deleted]
ashitlerferad 10y ago
There are many more than 3 init systems. There are tens of them.
- combatentropy 10y ago
  I meant three families, but you still may be right.
  - r0fls 10y ago
    Where does upstart stand in this? That's what I've used so far.
    - ashitlerferad 10y ago
      It is dead and gone, Canonical/Ubuntu abandoned it after Debian chose systemd and then Ubuntu did too.
- vocatus_gate 10y ago
  There are dozens of us!!
beagle3 10y ago
There's also http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh/ http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... - a daemontools compatible, partially-systemd compatible init system.

toomanythings2 10y ago

>I still have serious misgivings I guess that kinda tells us more than anything else he said.

kl4m 10y ago
You cut the quote to change the meaning. "Although I still have serious misgivings about the systemd upstream’s attitude, I’ve got to say I find the system rather refreshing and useful in practice."
- toomanythings2 10y ago
  There are misgivings none-the-less. A new system being "refreshing" is not a reason to use it. "Useful" is hardly a ringing endorsement. What disturbs me the most is that systemd takes Linux farther away from being a Unix-like system. Linux is now "Linux" and incompatible with anything else.

bbayles 10y ago

I didn't really know anything about init systems until 2014 (so I all but missed the systemd wars) when I found myself in need of process synchronization and supervision on various platforms. My task was pretty straightforward: I had a group of processes that need to start in a certain order, restart if they die, run as a non-root user, and write logs somewhere. I needed to support RHEL 5, 6, and 7, which all use different init systems (sysvinit, upstart, and systemd). I worked with all of them and also experimented with alternatives (runit, s6, Supervisor). For my task systemd was a pleasure to work with compared to the others. There was a bit of a learning curve, but once I mapped out what I needed to do the solution was obvious. I found upstart to be almost good, but the version that ships with RHEL 6 is lacking compared to the later versions that came with Ubuntu. The Python-based Supervisor was surprisingly good. I sort of saw why some people might like s6, but runit's charm was lost on me. sysvinit was by far the worst. I wound up using sysvinit to hand off to Supervisor in order to not spend my life worrying about the number of forks and pidfile locations. I can't speak to systemd's shortcomings and perceived hegemony in other areas, but when it comes to acting like an init system it is miles ahead of everything else.

nickysielicki 10y ago

This is maybe pedantic, but something that irks me about systemd is the way that systemctl commands are composed. I find myself doing this frequently > systemctl status someservice > systemctl stop someservice > systemctl edit someservice > systemctl daemon-reload > systemctl start someservice > systemctl status someservice > systemctl enable someservice Why make the operation the middle parameter? I understand that "systemctl start foo" more closely resembles the English sentence, "SystemD, please start the foo service", but I couldn't give two shits about that, and it's a dumb design decision. Any time that I am entering a systemctl command, I'm probably entering a series of 3 or more of them, and they're probably all related to the same service. Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument. It's a mess!

chm 10y ago
In Debian I use "service X action" which I also find preferable for the exact same reason you mention.
dredmorbius 10y ago
One-liner lists are handy: for service in <list> do; systemctl <action> <service>; done E.g., for system in foo bar baz; do systemctl stop $system; systemctl start $system; done ... will stop and start each of your named services. (This clearly extends far beyond systemd.)
- hueving 10y ago
  But it accepts a list, so rather than write the loop: systemctl stop foo bar baz; systemctl start foo bar baz
  - vidarh 10y ago
    With the caveat that yours and the version above are not the same. With properly written systemd units (e.g. using the notification API to signal when it's actually operational) the former will have fully started foo again before stopping bar (ignoring the lack of error handling in both examples..). Which may or may not matter.

digi_owl 10y ago

One "interesting" tidbit about systemd is that the init part will keel over if dbus goes down, and if pid1 keels over you are looking at a kernel panic...

kinkdr 10y ago
I was bitten by this once. A typo in dbus configuration rendered my machine unbootable.
- ZenoArrow 10y ago
  I wonder if issues like this were part of the reason the release of kdbus (dbus as a kernel module) was delayed.
  - tremon 10y ago
    kdbus is mainly delayed because the kernel devs are unconvinced. In the last thread I read (which was likely over a year ago), there were architectural issues with the design that nobody on the kdbus side was willing/able to fix or explain.
    - ZenoArrow 10y ago
      I thought one of the main kdbus devs was gregkh (one of the most senior Linux kernel maintainers), is that not the case? I did hear that there was due to be a redesign, but not sure what the issues were.
      - lomnakkus 10y ago
        I believe this is the redesign: https://github.com/bus1/bus1 https://github.com/bus1/bus1 EDIT: Replaced with better link. (Old link: http://www.bus1.org/index.html http://www.bus1.org/index.html )
        JdeBP 10y ago

digi_owl 10y ago

https://news.ycombinator.com/item?id=11639659 https://news.ycombinator.com/item?id=11639659 Found this regarding programming languages (and JS in particular) a bit interesting in the middle of the whole systemd debate, as i wonder if it can be applied to unix as well. This in that unix have from the early days been made up of loosely coupled parts. This then allowed new parts to be introduced, tested, and either adopted widely or discarded as seen fit. Maybe even adopted in some areas but ignored in others. But you rarely ran into deep dependency chains. Systemd on the other hand is tightly coupled, continually sprouting new stuff, and foisted on the world via deep dependencies.

creshal 10y ago
> Systemd on the other hand is tightly coupled Not really. All its various components are loosely coupled over DBus, and most are entirely optional. There's no technical reason why people can't e.g. implement journald's API in syslog. Or replace the various userspace *ctls (timedatectl, hostnamectl, …), or reimplement logind on top of some BSD (already done, actually), …
- digi_owl 10y ago
  You seem to be confusing the interface between systemd components and third parties, with internal interfaces. The latter are expressly non-documented, and non-stable, to allow the systemd devs to change them as they see fit. As for logind on BSD, got a link? Last i recall they were struggling because it was a sprawling and moving target (Consolekit2 is also having that problem). One example is that recently logind took over much fo the job upower used to do, with upower now being a compatibility wrapper around logind. Oh btw, dbus is massively more opaque that being able to run a command, look at the output, and then pipe that to another with the proper flags and such.
- TheyW0ntL1sten 10y ago
  Dude, there's literally nothing you can say that will change people's mind on this subject. It has long since crossed into some kind of identity subject.
- 10y ago

B1FF_PSUVM 10y ago

> I was debugging the boot on a server recently. It mounts a bunch of NFS filesystems Don't do that. It's a bag of hurt. (Still sore about the hours that workstations with not-working-fs mounts spent waiting for each other on boot after power failures, ages ago. Nevermore.)

deleted 10y ago
[deleted]
ibotty 10y ago
So you just don't use remote filesystems? That's a solution! Honestly, whenever the init system is configured correctly, you don't run into these problems all ops know a story about. It helps that systemd makes it easier to configure dependencies so that only the units depending on remote fs stall when it is unavailable.
- TheyW0ntL1sten 10y ago
  One time I was writing this long story in a text editor that crashed so I stopped writing. Nevermore.
- jabl 10y ago
  > So you just don't use remote filesystems? That's a solution! No, you mount them with autofs, of course.
  - snuxoll 10y ago
    autofs is great, combined with NFS4 and FreeIPA it's even not a total pain in the butt to configure on a whole farm of servers (having my home directory easily available with my ZSH configuration from every system I log into is great.)
  - karlshea 10y ago
    I found out about autofs when I was trying to figure out some SMB issues while mounting NAS shares on a media server. It was so ridiculously easy to set up. All of the "copy and paste" newbie answers always involve modifying fstab and there are always issues on boot, but autofs just works. It makes me wonder why it's not recommended as often.