9 ms·

Why systemd?

235 points by jamesog 12y ago

nextos 12y ago
We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the real-deal for small development tasks (not for production!). Just one command: systemd-nspawn, and you're ready to go. Docker is currently a bit more complicated to set up. Arguably, many features, including containers, should be moved out of systemd. Right now, more than a monolithic architecture, I think systemd is rather shipping too many things under the same project umbrella.
- jude- 12y ago
  > Lastly, lightweight containers are the real-deal for small development tasks (not for production!). Just one command: systemd-nspawn, and you're ready to go. You might be interested in firejail [1]. It makes finer-grained use of Linux namespaces, and doesn't depend on systemd (or much of anything, for that matter). [1] http://l3net.wordpress.com/projects/firejail/ http://l3net.wordpress.com/projects/firejail/
- elehack 12y ago
  > However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Writing daemon startup files was somehting I always dreaded, and never really did well. Before systemd, if I needed to run services I'd try to use daemontools (for auto-restart, and logging), but then I had two service-starting services running my system. Upstart had some of the features, but was still finicky (and the versions I had available didn't consistently have good service supervision support). systemd just fix that. Also, with systemd, for the first time I feel like I'm really using Linux, not just a random *Nix that has adequate drivers.
  - zobzu 12y ago
    so you're saying without systemd linux isnt linux.
    - elehack 12y ago
      Not quite. I'm saying that systemd makes the Linux kernel's feature set and capabilities visibly usable from user-space. For (nearly) the first time, it feels like it matters that I'm using Linux. Linux is still Linux without systemd, it just doesn't provide as much benefit (aside from device support and compatibility) over, say, FreeBSD without software that takes advantage of its feature set.
      - jude- 12y ago
        What stopped you from using Linux-specific features before systemd? They were accessible from userspace well before systemd came along.
        elehack 12y ago
        The lack of documented software that used them to enable useful (to me) functionality. I was using some of them, such as kvm for my virtualization and lvm for disk management. But systemd still had a substantial 'oh, wow, Linux lets process management be this easy and powerful?' factor, showing me something new that I hadn't seen in my use of any other system (FreeBSD, OpenBSD, Windows, a touch of Mac).
        zobzu 12y ago
        the documentation directory of the kernel source is actually pretty nice. theres a bunch of utilities for things like cgroups, namespaces, etc. they're not well known but they work perfectly fine. I suspect its not well known because there was no commercial, marketing drive behind them. Nowadays at least one of these seems to be needed to even gain visibility. People don't go search what's cool/good where it is. They wait for HN or some other news website to tell them Just like the regular news really. Turns out it doesn't work all that great.
- bwood 12y ago
  > Lastly, lightweight containers are the real-deal for small development tasks (not for production!). I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?
  - vacri 12y ago
    I'm just familiarising with docker at the moment (specifically docker, not 'containers'). I'm finding that there's a lot of glitz and glamour around it that's good for devs, but us ops guys like mundane things like logs and status messages. For example, I get the same message whether I start or stop a container: the arg I used to refer to the container. No information. I've run into a few shortcuts like this. It's pretty magical, don't get me wrong, but it's still in adolescence. I've heard some banks are using it in production (no idea of what for, though) - which is a feather in docker's cap - but there's still some things that need to be polished.
  - e12e 12y ago
    If we (fairly or unfairly) group Linux' LXC (eg: docker) and * bsd's jails, the main contrast with "proper" hypervisors (xen/kvm/vmware/bhyve(? That new thing in freebsd 10?) is (the possibility of) full resource accounting/limitation. Go ahead run you pi-digit-finder at "100%" cpu, pipe /dev/zero over an ssh pipe to /dev/null on some box and pipe it to a local file as well: no other vm or the host will notice. You only get 1mbs, x cycles of cpu and x mb of disk. Secondly, assuming a bug in the kernel, one might assume root in a container can lead to root on the host. Bsd jails have been pretty solid for the last few years afaik - but hardware support for virtualization might still get more of both separation/safety and speed. There have been som bad bugs in (as i recall) the io system in xen, leading to similar issues ... but again the last time i saw anything on that was years ago. Ymmv - generally docker doesn't have "run untrusted code, safely, as root" as a design-goal (yet, afaik) (not entirely sure about lxc, née vserver -- the underlying technology) -- so don't expect it to do that. Isolation and security (esp. without sacrificing performance) is very hard to get right. Or so a long series of privilege escalation exploits across many different os' seem to indicate.
- edwintorok 12y ago
  Boot time again. In a server environment it happens that the various DRAC/BIOS(es) are initialized and the bootloader reached is far longer (several minutes sometimes) than the boot time of sysvinit. So optimizing boot time in the Linux part on a server is probably moot for me. On the laptop you can suspend/hibernate as others have said if you care about startup time. I have full-disk encryption and need to type in password to boot so few seconds more or less doesn't matter anyway. So that leaves the desktop, where I might care about boot times (the UEFI/BIOS is actually saner than in servers and reaches the bootloader very fast). It turns out that my desktop boots faster than my router with sysvinit already, so having faster boot times on my desktop would get me nowhere, I still wouldn't be able to use the internet until the router has booted. So faster boot times ... I didn't need all the pain systemd is causing just for that. Debian has haid makefile/startpar based concurrent boot already, I don't think systemd would improve on that much ... Meanwhile not using systemd breaks things that used to work on a KDE desktop (USB mounting, VPN config, etc.), so having an app support systemd is a net-negative for me.
  - UnoriginalGuy 12y ago
    Holy heck, I get being defensive, but you've let logic totally fall by the wayside here. Where do I start... The fact that BIOS/DRAC/RAID initialisation is slow on some servers is irrelevant. Linux's init and the firmware initialisation don't run concurrently, therefore if init takes longer the whole boot takes longer. Additionally many servers manufacturers have improved boot times in the last few years (down from 10+ minutes, to 5+ minutes, to less). Most routers don't take as long to boot as you claim. The entire OS is about 8 MB (uncompressed) and RAM is only 32 MB, and the medium that the OS is stored on is faster than a computer's hard drive. So just looking at IO should tell you your supposition is flawed. In my experience most Linux based routers boot the RJ-45 interface (LAN side) in under 20 seconds unless it is allocating slowly on the WAN interface (e.g. unable to get an IP, etc). If you set a static WAN IP/gateway/etc, then boot times comes down substantially. Additionally the whole concept that every time your PC turns off you'll also turn off your router at the mains is, uhh, strange. Sure there are power cuts but that isn't the only time you shutdown your PC throughout the year. The concept that your PC needs to wait for the server is equally flawed. Again, yes, power cuts. But PCs get shut down significantly more often than servers and if we're playing that game then wouldn't a "server" have a UPS anyway? So overall your argument for why boot times don't matter lacks any kind of substance. It is also purely based on a PC->Server->Router infrastructure where nothing is on a UPS and everything suffers from a power cut (then "races" to all come back up). In the real world my phone has Linux, our "Tivo" has Linux, our printer has Linux, our car's entertainment system has Linux, etc. So bad Linux boot times will be noticed day to day. It matters to a lot of people and while I don't know if systemd is the solution, I do know that progress is needed relative to the classic UNIX init system (per the article).
- dalias 12y ago
  If your boot time was bad before and decent now, this is not thanks to the goodness of systemd but rather the badness of whatever hideous system your distro was using before, and/or because your distro is starting a bunch of useless junk that shouldn't be running in the first place. I've been using flat /etc/rc (all commands in one file, & at the end of anything non-essential) for years (decades?) now, and have always had a login prompt faster than the display can synchronize to the video mode change.
deleted 12y ago
[deleted]
dsr_ 12y ago
The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that it will take over via politicking.
- audidude 12y ago
  > In order to fix a system, a person needs to understand it as well as be able to make a change in it. So if I follow you, it would be easier to grok the whole system if all the code was in different places?
  - nisa 12y ago
    Opaque C code that sits in lots of spread binaries and some end-user documentation in man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other complex systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r <error>` is often the first step on the way to understand and learn something and fix the problem. This is more difficult if you have a lot of abstractions and binaries lying around. You need to start reading (often nonexistent) documentation and abstract C-code... It likely does not matter for 95% of users and I've rarely had to do something like this but you are losing some control as developer/sysadmin. For some it's important as their productivity and job depends on solving such issues fast, others will never have this problem... I've never had a problem with systemd through. But if you have it's difficult to fix it on your own.
    - audidude 12y ago
      > Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r <error>` is often the first step on the way to understand and learn something and fix the problem. What's opaque about Free and Open Source C code? Some might argue (this guy included) that statically typed, statically analyzed C code will result in fewer people having to debug their system code than the equivalent code written in a particular variant of shell code.
ultramancool 12y ago
Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single regret so far.
- AceJohnny2 12y ago
  > dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?
  - drdaeman 12y ago
    What's wrong with old good Unix pipes?
    - audidude 12y ago
      The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. They aren't introspect-able to see what the peer supports. They make it super easy to not maintain ABI. I could go on.
      - nisa 12y ago
        > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. (It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/ http://www.ubuntu.com/usn/usn-2352-1/
      - 12y ago
mhogomchungu 12y ago
Lots of people do not seem to understand the criticism of systemd. systemd = init system + a whole lot of other things. When people complain about systemd,they usually do not complain about what it does or how it does it in the init system part.That part is pretty solid as far as functionality is concerned. When people complain about systemd,they usually complain about the "whole lot of other things" part.Lots of people have different complains and my biggest one is on udev. udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab.They could have left udev as an independent project and just create a dependency on it. The "whole lot of other things part" will,by definition,make any other project that is just an init system seem very much deficient in functionality when compared to systemd.
- audidude 12y ago
  > udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab. I think this is a bit of a stretch. It's not like they did a hostile take over of udev. The maintainers also thought systemd was the right place for that code to live. As for bloat, there certainly have been some new features, but so much of the systemd code (from what I can tell) was existing code that now lives in one place. That means it's free to consolidate the utility code it uses (every project has helpers for what (g)libc does not provide). In the grand scheme of things, less duplicated code is a good thing.
  - nisa 12y ago
    > It's not like they did a hostile take over of udev. http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... (via http://redd.it/2a2tz5 http://redd.it/2a2tz5): > Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.
Sanddancer 12y ago
I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself would want to -- it sets the signal handlers and masks appropriately, double forks, creates a session, sets PIDs unless you tell it not to, and changes to the root directory unless you tell it not to. Glibc's misses important steps, like the signal manipulations, tries too hard to create a typical null device, and otherwise completely misses the point. The biggest problem I see with system is that the developers don't play well with others. Instead of working with various parties, like the glibc maintainers, to fix deficiencies elsewhere, they expect developers everywhere to drop what they're doing to redesign how their projects work, when they work just fine for the many, many other unix architectures out there. Too much of systemd is based on magical pixie dust, compatibility be damned, and not enough on actually making things better.
- m45t3r 12y ago
  Well, the problem is, you only changed the problem. Now instead of depending of a specific init system, you're depending of a specific implementation of daemon() function (which I imagine is not really standard, since if it was glibc would implement it correctly). Maybe you could create daemon_correctly() function that was guarantee to implement daemon as it should, but you would incur the risk of having the case of strlcpy() again (glibc didn't added this function since the maintainer said it was messy and bloated, so almost no software used it). And anyway, correctly daemonizing is only part of what systemd got right. I think the fact that you don't need to track services with random programs anymore (since systemd knows each and every process parent thanks to cgroups) is something much more interesting than just getting daemon() right.
- cbsmith 12y ago
  > double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism. Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.
uselessdguy 12y ago
Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager then defines a basic framework for stopping, starting, restarting and checking status for services, at a minimum. The process supervisor then applies resource limits (or even has those as separate tools, like perp does with its runtools), process monitoring (whether through ptrace(2), cgroups, PID files, jails or whatnot), autorestart, inotify(7)/kqueue handlers, system load diagnostics and so forth. The shutdown stage is another separate part, often handled either in the initd or the process manager. Often, it just hooks to the argv[0] of standard tools like halt, reboot, poweroff, shutdown to execute killall routines, detach mount points, etc. To stuff everything in the init system, I'd argue, is bad design. One must delegate, whether to auxiliary daemons, shell scripts, configuration syntax (in turn read and processed by daemons) or what have you. sysvinit is certainly inadequate. The inittab is cryptic and clunky, and runlevels are a needlessly restrictive concept to express what is essentially a named service group that can be isolated/overlayed. Of course, to start services on socket connections, you either use (x)inetd, or you reimplement a subset or (partial or otherwise) superset of it. There's no way around this, it's choosing to handle more on your own rather than delegate. In systemd's case, they do this to support socket families like AF_NETLINK. As for systemd being documented, I'd say it's quote mediocre. The manpages proved to be inconsistent and incomplete, and for anyone but an end user or a minimally invested sysadmin, of little use whatsoever. Quantity is nice, but the quality department is lacking. sysvinit's baroque and arduous shell scripts are not the fault of using shell scripts as a service medium, but have to deal with sysvinit's aforementioned cruft (inittab and runlevels) and the historical lack of any standard modules. BSD init has the latter in the form of /etc/rc.subr, which implements essential functions like rc_cmd and wait_for_pids. Exact functions vary from BSD to BSD, but more often than not, BSD init services are even shorter than systemd services: averaging 3-4 lines of code. A unified logging sink is nothing novel, it's just that systemd is the first of its kind that gained momentum, but with its own unique set of issues. syslogd and kmsg were still passable, and the former also seamlessly integrated itself with databases. Once again, changing the execution environment is a separate stage and has multiple ways of being done. Init-agnostic tools that wrap around syscalls are probably my favorite, but YMMV. As for containers, it's about time Linux caught up to Solaris and FreeBSD.
callesgg 12y ago
I think systemd actually clears up a loot of stuff. As the article describes. The main thing that scares me is the binary loging format I can think of some benefits but mostly it just seams scary. I guess I will get go se later if the benifits outweighs the rest.
- tracker1 12y ago
  I was actually pretty happy with the way upstart handles logging... it's about as transparent, and easier to deal with.
dschiptsov 12y ago
Out of confused mind.) There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that. Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way. btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons. There is actually nothing to talk about, except some ambitions and bad designs.
- icebraining 12y ago
  btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons. I'm pretty sure /sbin/init runs in userspace even on *BSDs and Solaris, and does process supervision.
  - dschiptsov 12y ago
    You would be surprised how a few processes it supervises. getties (remember these?) what else? initscripts has nothing to do with /sbin/init, surprise?
- _delirium 12y ago
  Solaris guys certainly wouldn't tell you that, unless they haven't used Solaris in the last decade. Since Solaris 10 (2005), it has a unified process supervision and init system, with declarative config files, dependency boot, and all that other good stuff that's just now coming to Linux. It's part of the Service Management Facility (SMF), which replaced the old init-script-based system. The Illumos distributions all use SMF as well, not BSD or SysV-style init/rc scripts. A few design decisions are now seen as warts (today, XML probably wouldn't have been chosen for the config files), but I think SMF is pretty widely seen as an improvement vs. managing services with shell scripts.
  - dschiptsov 12y ago
    Please tell us about these improvements over shell init scripts. Let's say a have a program to run - nginx - very popular program. Tell us, please, what improvements the good stuff gives me? BTW, in my opinion, the SMF has been written "because we can" (use XML for configs and Java for its processing) not because shell init scripts has been broken. There are many strange reasons why some programs were written or has been adopted.
contingencies 12y ago
Case in point .. today .. rebuilding an X11 desktop system on Gentoo, some weird set of dependencies around gnome beneath the window manager wants to pull in systemd. I finally work out a way around it, but it wastes half an hour of my time. My take: Containers are not well managed by general, daemon-oriented process supervisors with a localhost-oriented purview. However, those supervisors would do well to use container-related features to better secure and manage daemons as appropriate. In future, processes will be more likely managed across clusters by parallel capable supervisory systems with high availability goals and network infrastructure configuration, load and topology knowledge. Less and less people will even see the init system, except perhaps behind a logo or as it flashes past while booting their device in debug mode. (Edit: stumbled on http://www.gossamer-threads.com/lists/gentoo/user/284741 http://www.gossamer-threads.com/lists/gentoo/user/284741 which explains the scenario .. would hate to be on BSD)
stephen_g 12y ago
There's a lot of negativity going on here... As far as my experience goes, I've found it actually works really well on all the servers I've moved to CentOS 7 and on the Fedora desktop I play around with (my main dev machines are Macs) it's significantly improved boot time... I'm sure there are some valid concerns about design and such, but as far as my usage in production goes, I can't say I've had a single problem with it... It makes it a lot easier when I need to write files then the messy init scripts before also.
fsniper 12y ago
I'm new on the boat about systemd debate so I'm still reading and reviewing the situation. But the more I read the more I'm getting away from systemd. In principal everybody is on terms with the need for a new and modern init system. But yet I'm not even sold on this issue. sysvinit is still holding stance with extra tools and doing it's job cleanly. By introducing a fully reimplemented and still controversial system with many dependencies and with need for many reimplementation on our existing software we are not helping the issue but blurring the waters. And What's the fascination about boot times? Nowadays on desktops nobody boots. You just boot once and hibernate/suspend forever. And for servers, if you are rebooting you are doing something wrong. So pulling efforts from building controversial init systems to optimize hibernate/suspend in the kernel would be a better effort on this field.
- johnny22 12y ago
  boot times are the least important reason to use systemd.
dancecodes 12y ago
Perhaps to see topic on HN: "Why not systemd?" or something else: "Do you need systemd?"

235 points by jamesog 12y ago

We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the real-deal for small development tasks (not for production!). Just one command: systemd-nspawn, and you're ready to go. Docker is currently a bit more complicated to set up. Arguably, many features, including containers, should be moved out of systemd. Right now, more than a monolithic architecture, I think systemd is rather shipping too many things under the same project umbrella.

jude- 12y ago
> Lastly, lightweight containers are the real-deal for small development tasks (not for production!). Just one command: systemd-nspawn, and you're ready to go. You might be interested in firejail [1]. It makes finer-grained use of Linux namespaces, and doesn't depend on systemd (or much of anything, for that matter). [1] http://l3net.wordpress.com/projects/firejail/ http://l3net.wordpress.com/projects/firejail/
elehack 12y ago
> However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Writing daemon startup files was somehting I always dreaded, and never really did well. Before systemd, if I needed to run services I'd try to use daemontools (for auto-restart, and logging), but then I had two service-starting services running my system. Upstart had some of the features, but was still finicky (and the versions I had available didn't consistently have good service supervision support). systemd just fix that. Also, with systemd, for the first time I feel like I'm really using Linux, not just a random *Nix that has adequate drivers.
- zobzu 12y ago
  so you're saying without systemd linux isnt linux.
  - elehack 12y ago
    Not quite. I'm saying that systemd makes the Linux kernel's feature set and capabilities visibly usable from user-space. For (nearly) the first time, it feels like it matters that I'm using Linux. Linux is still Linux without systemd, it just doesn't provide as much benefit (aside from device support and compatibility) over, say, FreeBSD without software that takes advantage of its feature set.
    - jude- 12y ago
      What stopped you from using Linux-specific features before systemd? They were accessible from userspace well before systemd came along.
      - elehack 12y ago
        The lack of documented software that used them to enable useful (to me) functionality. I was using some of them, such as kvm for my virtualization and lvm for disk management. But systemd still had a substantial 'oh, wow, Linux lets process management be this easy and powerful?' factor, showing me something new that I hadn't seen in my use of any other system (FreeBSD, OpenBSD, Windows, a touch of Mac).
        zobzu 12y ago
        the documentation directory of the kernel source is actually pretty nice. theres a bunch of utilities for things like cgroups, namespaces, etc. they're not well known but they work perfectly fine. I suspect its not well known because there was no commercial, marketing drive behind them. Nowadays at least one of these seems to be needed to even gain visibility. People don't go search what's cool/good where it is. They wait for HN or some other news website to tell them Just like the regular news really. Turns out it doesn't work all that great.
bwood 12y ago
> Lastly, lightweight containers are the real-deal for small development tasks (not for production!). I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?
- vacri 12y ago
  I'm just familiarising with docker at the moment (specifically docker, not 'containers'). I'm finding that there's a lot of glitz and glamour around it that's good for devs, but us ops guys like mundane things like logs and status messages. For example, I get the same message whether I start or stop a container: the arg I used to refer to the container. No information. I've run into a few shortcuts like this. It's pretty magical, don't get me wrong, but it's still in adolescence. I've heard some banks are using it in production (no idea of what for, though) - which is a feather in docker's cap - but there's still some things that need to be polished.
- e12e 12y ago
  If we (fairly or unfairly) group Linux' LXC (eg: docker) and * bsd's jails, the main contrast with "proper" hypervisors (xen/kvm/vmware/bhyve(? That new thing in freebsd 10?) is (the possibility of) full resource accounting/limitation. Go ahead run you pi-digit-finder at "100%" cpu, pipe /dev/zero over an ssh pipe to /dev/null on some box and pipe it to a local file as well: no other vm or the host will notice. You only get 1mbs, x cycles of cpu and x mb of disk. Secondly, assuming a bug in the kernel, one might assume root in a container can lead to root on the host. Bsd jails have been pretty solid for the last few years afaik - but hardware support for virtualization might still get more of both separation/safety and speed. There have been som bad bugs in (as i recall) the io system in xen, leading to similar issues ... but again the last time i saw anything on that was years ago. Ymmv - generally docker doesn't have "run untrusted code, safely, as root" as a design-goal (yet, afaik) (not entirely sure about lxc, née vserver -- the underlying technology) -- so don't expect it to do that. Isolation and security (esp. without sacrificing performance) is very hard to get right. Or so a long series of privilege escalation exploits across many different os' seem to indicate.
edwintorok 12y ago
Boot time again. In a server environment it happens that the various DRAC/BIOS(es) are initialized and the bootloader reached is far longer (several minutes sometimes) than the boot time of sysvinit. So optimizing boot time in the Linux part on a server is probably moot for me. On the laptop you can suspend/hibernate as others have said if you care about startup time. I have full-disk encryption and need to type in password to boot so few seconds more or less doesn't matter anyway. So that leaves the desktop, where I might care about boot times (the UEFI/BIOS is actually saner than in servers and reaches the bootloader very fast). It turns out that my desktop boots faster than my router with sysvinit already, so having faster boot times on my desktop would get me nowhere, I still wouldn't be able to use the internet until the router has booted. So faster boot times ... I didn't need all the pain systemd is causing just for that. Debian has haid makefile/startpar based concurrent boot already, I don't think systemd would improve on that much ... Meanwhile not using systemd breaks things that used to work on a KDE desktop (USB mounting, VPN config, etc.), so having an app support systemd is a net-negative for me.
- UnoriginalGuy 12y ago
  Holy heck, I get being defensive, but you've let logic totally fall by the wayside here. Where do I start... The fact that BIOS/DRAC/RAID initialisation is slow on some servers is irrelevant. Linux's init and the firmware initialisation don't run concurrently, therefore if init takes longer the whole boot takes longer. Additionally many servers manufacturers have improved boot times in the last few years (down from 10+ minutes, to 5+ minutes, to less). Most routers don't take as long to boot as you claim. The entire OS is about 8 MB (uncompressed) and RAM is only 32 MB, and the medium that the OS is stored on is faster than a computer's hard drive. So just looking at IO should tell you your supposition is flawed. In my experience most Linux based routers boot the RJ-45 interface (LAN side) in under 20 seconds unless it is allocating slowly on the WAN interface (e.g. unable to get an IP, etc). If you set a static WAN IP/gateway/etc, then boot times comes down substantially. Additionally the whole concept that every time your PC turns off you'll also turn off your router at the mains is, uhh, strange. Sure there are power cuts but that isn't the only time you shutdown your PC throughout the year. The concept that your PC needs to wait for the server is equally flawed. Again, yes, power cuts. But PCs get shut down significantly more often than servers and if we're playing that game then wouldn't a "server" have a UPS anyway? So overall your argument for why boot times don't matter lacks any kind of substance. It is also purely based on a PC->Server->Router infrastructure where nothing is on a UPS and everything suffers from a power cut (then "races" to all come back up). In the real world my phone has Linux, our "Tivo" has Linux, our printer has Linux, our car's entertainment system has Linux, etc. So bad Linux boot times will be noticed day to day. It matters to a lot of people and while I don't know if systemd is the solution, I do know that progress is needed relative to the classic UNIX init system (per the article).
dalias 12y ago
If your boot time was bad before and decent now, this is not thanks to the goodness of systemd but rather the badness of whatever hideous system your distro was using before, and/or because your distro is starting a bunch of useless junk that shouldn't be running in the first place. I've been using flat /etc/rc (all commands in one file, & at the end of anything non-essential) for years (decades?) now, and have always had a login prompt faster than the display can synchronize to the video mode change.

deleted 12y ago

[deleted]

dsr_ 12y ago

The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that it will take over via politicking.

audidude 12y ago
> In order to fix a system, a person needs to understand it as well as be able to make a change in it. So if I follow you, it would be easier to grok the whole system if all the code was in different places?
- nisa 12y ago
  Opaque C code that sits in lots of spread binaries and some end-user documentation in man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other complex systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r <error>` is often the first step on the way to understand and learn something and fix the problem. This is more difficult if you have a lot of abstractions and binaries lying around. You need to start reading (often nonexistent) documentation and abstract C-code... It likely does not matter for 95% of users and I've rarely had to do something like this but you are losing some control as developer/sysadmin. For some it's important as their productivity and job depends on solving such issues fast, others will never have this problem... I've never had a problem with systemd through. But if you have it's difficult to fix it on your own.
  - audidude 12y ago
    > Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r <error>` is often the first step on the way to understand and learn something and fix the problem. What's opaque about Free and Open Source C code? Some might argue (this guy included) that statically typed, statically analyzed C code will result in fewer people having to debug their system code than the equivalent code written in a particular variant of shell code.

ultramancool 12y ago

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single regret so far.

AceJohnny2 12y ago
> dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?
- drdaeman 12y ago
  What's wrong with old good Unix pipes?
  - audidude 12y ago
    The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out. They aren't introspect-able to see what the peer supports. They make it super easy to not maintain ABI. I could go on.
    - nisa 12y ago
      > They have an inherent vulnerability in FD passing where you can cause the peer to lock up. (It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/ http://www.ubuntu.com/usn/usn-2352-1/
    - 12y ago

mhogomchungu 12y ago

Lots of people do not seem to understand the criticism of systemd. systemd = init system + a whole lot of other things. When people complain about systemd,they usually do not complain about what it does or how it does it in the init system part.That part is pretty solid as far as functionality is concerned. When people complain about systemd,they usually complain about the "whole lot of other things" part.Lots of people have different complains and my biggest one is on udev. udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab.They could have left udev as an independent project and just create a dependency on it. The "whole lot of other things part" will,by definition,make any other project that is just an init system seem very much deficient in functionality when compared to systemd.

audidude 12y ago
> udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab. I think this is a bit of a stretch. It's not like they did a hostile take over of udev. The maintainers also thought systemd was the right place for that code to live. As for bloat, there certainly have been some new features, but so much of the systemd code (from what I can tell) was existing code that now lives in one place. That means it's free to consolidate the utility code it uses (every project has helpers for what (g)libc does not provide). In the grand scheme of things, less duplicated code is a good thing.
- nisa 12y ago
  > It's not like they did a hostile take over of udev. http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... (via http://redd.it/2a2tz5 http://redd.it/2a2tz5): > Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.

Sanddancer 12y ago

I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself would want to -- it sets the signal handlers and masks appropriately, double forks, creates a session, sets PIDs unless you tell it not to, and changes to the root directory unless you tell it not to. Glibc's misses important steps, like the signal manipulations, tries too hard to create a typical null device, and otherwise completely misses the point. The biggest problem I see with system is that the developers don't play well with others. Instead of working with various parties, like the glibc maintainers, to fix deficiencies elsewhere, they expect developers everywhere to drop what they're doing to redesign how their projects work, when they work just fine for the many, many other unix architectures out there. Too much of systemd is based on magical pixie dust, compatibility be damned, and not enough on actually making things better.

m45t3r 12y ago
Well, the problem is, you only changed the problem. Now instead of depending of a specific init system, you're depending of a specific implementation of daemon() function (which I imagine is not really standard, since if it was glibc would implement it correctly). Maybe you could create daemon_correctly() function that was guarantee to implement daemon as it should, but you would incur the risk of having the case of strlcpy() again (glibc didn't added this function since the maintainer said it was messy and bloated, so almost no software used it). And anyway, correctly daemonizing is only part of what systemd got right. I think the fact that you don't need to track services with random programs anymore (since systemd knows each and every process parent thanks to cgroups) is something much more interesting than just getting daemon() right.
cbsmith 12y ago
> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism. Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.

uselessdguy 12y ago

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager then defines a basic framework for stopping, starting, restarting and checking status for services, at a minimum. The process supervisor then applies resource limits (or even has those as separate tools, like perp does with its runtools), process monitoring (whether through ptrace(2), cgroups, PID files, jails or whatnot), autorestart, inotify(7)/kqueue handlers, system load diagnostics and so forth. The shutdown stage is another separate part, often handled either in the initd or the process manager. Often, it just hooks to the argv[0] of standard tools like halt, reboot, poweroff, shutdown to execute killall routines, detach mount points, etc. To stuff everything in the init system, I'd argue, is bad design. One must delegate, whether to auxiliary daemons, shell scripts, configuration syntax (in turn read and processed by daemons) or what have you. sysvinit is certainly inadequate. The inittab is cryptic and clunky, and runlevels are a needlessly restrictive concept to express what is essentially a named service group that can be isolated/overlayed. Of course, to start services on socket connections, you either use (x)inetd, or you reimplement a subset or (partial or otherwise) superset of it. There's no way around this, it's choosing to handle more on your own rather than delegate. In systemd's case, they do this to support socket families like AF_NETLINK. As for systemd being documented, I'd say it's quote mediocre. The manpages proved to be inconsistent and incomplete, and for anyone but an end user or a minimally invested sysadmin, of little use whatsoever. Quantity is nice, but the quality department is lacking. sysvinit's baroque and arduous shell scripts are not the fault of using shell scripts as a service medium, but have to deal with sysvinit's aforementioned cruft (inittab and runlevels) and the historical lack of any standard modules. BSD init has the latter in the form of /etc/rc.subr, which implements essential functions like rc_cmd and wait_for_pids. Exact functions vary from BSD to BSD, but more often than not, BSD init services are even shorter than systemd services: averaging 3-4 lines of code. A unified logging sink is nothing novel, it's just that systemd is the first of its kind that gained momentum, but with its own unique set of issues. syslogd and kmsg were still passable, and the former also seamlessly integrated itself with databases. Once again, changing the execution environment is a separate stage and has multiple ways of being done. Init-agnostic tools that wrap around syscalls are probably my favorite, but YMMV. As for containers, it's about time Linux caught up to Solaris and FreeBSD.

callesgg 12y ago

I think systemd actually clears up a loot of stuff. As the article describes. The main thing that scares me is the binary loging format I can think of some benefits but mostly it just seams scary. I guess I will get go se later if the benifits outweighs the rest.

tracker1 12y ago
I was actually pretty happy with the way upstart handles logging... it's about as transparent, and easier to deal with.

dschiptsov 12y ago

Out of confused mind.) There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that. Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way. btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons. There is actually nothing to talk about, except some ambitions and bad designs.

icebraining 12y ago
btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons. I'm pretty sure /sbin/init runs in userspace even on *BSDs and Solaris, and does process supervision.
- dschiptsov 12y ago
  You would be surprised how a few processes it supervises. getties (remember these?) what else? initscripts has nothing to do with /sbin/init, surprise?
_delirium 12y ago
Solaris guys certainly wouldn't tell you that, unless they haven't used Solaris in the last decade. Since Solaris 10 (2005), it has a unified process supervision and init system, with declarative config files, dependency boot, and all that other good stuff that's just now coming to Linux. It's part of the Service Management Facility (SMF), which replaced the old init-script-based system. The Illumos distributions all use SMF as well, not BSD or SysV-style init/rc scripts. A few design decisions are now seen as warts (today, XML probably wouldn't have been chosen for the config files), but I think SMF is pretty widely seen as an improvement vs. managing services with shell scripts.
- dschiptsov 12y ago
  Please tell us about these improvements over shell init scripts. Let's say a have a program to run - nginx - very popular program. Tell us, please, what improvements the good stuff gives me? BTW, in my opinion, the SMF has been written "because we can" (use XML for configs and Java for its processing) not because shell init scripts has been broken. There are many strange reasons why some programs were written or has been adopted.

contingencies 12y ago

Case in point .. today .. rebuilding an X11 desktop system on Gentoo, some weird set of dependencies around gnome beneath the window manager wants to pull in systemd. I finally work out a way around it, but it wastes half an hour of my time. My take: Containers are not well managed by general, daemon-oriented process supervisors with a localhost-oriented purview. However, those supervisors would do well to use container-related features to better secure and manage daemons as appropriate. In future, processes will be more likely managed across clusters by parallel capable supervisory systems with high availability goals and network infrastructure configuration, load and topology knowledge. Less and less people will even see the init system, except perhaps behind a logo or as it flashes past while booting their device in debug mode. (Edit: stumbled on http://www.gossamer-threads.com/lists/gentoo/user/284741 http://www.gossamer-threads.com/lists/gentoo/user/284741 which explains the scenario .. would hate to be on BSD)

stephen_g 12y ago

There's a lot of negativity going on here... As far as my experience goes, I've found it actually works really well on all the servers I've moved to CentOS 7 and on the Fedora desktop I play around with (my main dev machines are Macs) it's significantly improved boot time... I'm sure there are some valid concerns about design and such, but as far as my usage in production goes, I can't say I've had a single problem with it... It makes it a lot easier when I need to write files then the messy init scripts before also.

fsniper 12y ago

I'm new on the boat about systemd debate so I'm still reading and reviewing the situation. But the more I read the more I'm getting away from systemd. In principal everybody is on terms with the need for a new and modern init system. But yet I'm not even sold on this issue. sysvinit is still holding stance with extra tools and doing it's job cleanly. By introducing a fully reimplemented and still controversial system with many dependencies and with need for many reimplementation on our existing software we are not helping the issue but blurring the waters. And What's the fascination about boot times? Nowadays on desktops nobody boots. You just boot once and hibernate/suspend forever. And for servers, if you are rebooting you are doing something wrong. So pulling efforts from building controversial init systems to optimize hibernate/suspend in the kernel would be a better effort on this field.

johnny22 12y ago
boot times are the least important reason to use systemd.

dancecodes 12y ago

Perhaps to see topic on HN: "Why not systemd?" or something else: "Do you need systemd?"