How many people have actually tried systemd ?
Hi all, I'm curious after the recent storm about systemd to find out how many people have actually tried to use it? I installed a test machine with CentOS 7 (which has systemd by default) to see if it causes any issues with the Slurm HPC job queuing system we use on our supercomputers. The reason is that both want to use cgroups and (in our case) Slurm's need is greater than systemd's. To my great surprise both my cats are still alive, there have been no unexplained solar eclipses and the world has not ended. Oh, and Slurm continues to work as before. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Hi all,
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
I installed a test machine with CentOS 7 (which has systemd by default) to see if it causes any issues with the Slurm HPC job queuing system we use on our supercomputers. The reason is that both want to use cgroups and (in our case) Slurm's need is greater than systemd's.
To my great surprise both my cats are still alive, there have been no unexplained solar eclipses and the world has not ended. Oh, and Slurm continues to work as before.
Having upgraded to Jessie at home, systemd has popped up everywhere. It broke a few things, which I have posted before but will mention again: . auto startup of mythtv. I was using inittab which is horrible but worked. A quick google showed me how to do it under systemd, and it is so much better. Inittab is a pain to try and get packages to maintain. . serial console. Knowing that I was using system and that inittab wouldn't get me a serial console I figured I'd need to do some funky systemd magic to get it working. Turns out that I didn't need to do anything. Anything else that systemd has done under the covers, I haven't noticed. I think I might have been affected by some bugs where openvswitch didn't start up properly or something and I ended up putting a manual "ifup -a" in a script somewhere to fix it, but that was a bug, not a broken-by-design-ism, and it's long since been fixed. I think Linux has been missing proper service control for a long time. Different packages have thrown together half baked solutions where the init.d script starts a watcher process that starts the actual service, and restarts it if it stops for some reason (does mysql have this or am I thinking of something else?), but of course that involves a different config for every different service, and half the time doesn't work properly anyway because the developer hasn't considered various corner cases. Whether systemd is the best solution to that I don't really know, and maybe Debian has been forced to make a choice too early.... only time will tell, but the previous implementation of service management was well broken, IMHO. James
On 14/10/14 22:55, Chris Samuel wrote:
Hi all,
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
Fedora 20 users have been. I haven't had any more troubles than with the old init.d, and rc.local is still there for any legacy stuff. The management gui has a short coming regarding services that haven't been enabled - it doesn't show them. Going in with the command line tool to enable them solves it.
On 14/10/14 22:55, Chris Samuel wrote:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
Have been a user since version 44 was available in Debian for my servers, and on my desktops since I switched to Fedora 17. As a user with nowhere near as much technical expertise as others on this list, systemd has been nothing but awesome to me.
From a sysadmin perspective it makes my life easier by bringing service control up to (and beyond) the standard of Windows, which has been able to supervise processes since, gosh, I only started counting in Windows 2000.
From both a sysadmin and a user perspective, unit files are easier to write and more robust than writing init scripts. The syntax is not as friendly as upstart, but this is a minor detail.
From a user perspective, my system boots insanely quickly, no longer hangs on shutdown like upstart does (this is a known bug that is also linked to filesystem corruption -- can't be bothered finding the source for this, but is an open bug on Launchpad), and doesn't interfere with muscle memory by still being able to do "service foo restart".
From a sysadmin perspective killing off pesky child processes is SO last century. You may well argue that every instance where child processes linger when the parent dies is a bug in the application. Well, good luck fixing every one. I'll see you next millennium. In the meantime, I'm enjoying getting actual work done.
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management. If you people are going to rip out systemd and send me back to sysvinit because of technical reasons that I am not capable of arguing against, you are going to have to find a way to replicate all these useful features that I'm ACTUALLY using with an easy to learn config format (easier than configuring most things out there!) and even easier command line tools out of the box in any major distro. It's a classic case of technical purists telling the users what they should want, rather than actually giving users what they want. Before systemd came along I longed for the kind of stuff it could do! The alternatives I've seen talked about in the past week just don't cut the mustard in my book, as both a sysadmin and a user. Anything other than systemd is unacceptable in my view of the future.
Jeremy Visser <jeremy@visser.name> writes:
From a sysadmin perspective [systemd] makes my life easier by bringing service control up to (and beyond) the standard of Windows, which has been able to supervise processes since, gosh, I only started counting in Windows 2000.
So sort of like djb daemontools or (as you mentioned) upstart? It's not like systemd is the first thing to do this in Linux.
The syntax is not as friendly as upstart, but this is a minor detail. [...] and doesn't interfere with muscle memory by still being able to do "service foo restart".
upstart supports "service foo restart".
From a sysadmin perspective killing off pesky child processes is SO last century. You may well argue that every instance where child processes linger when the parent dies is a bug in the application. Well, good luck fixing every one. I'll see you next millennium. In the meantime, I'm enjoying getting actual work done.
Not sure what you mean by that.
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd :-)
On 15 October 2014 10:41, Trent W. Buck <trentbuck@gmail.com> wrote:
Not sure what you mean by that.
Sometimes a daemon will hang badly, and the init.d script won't kill it, and killing one process leaves the other processes running. So you have to go in by hand and kill -9 every process. I had this happen several weeks ago, can't remember what daemon it was now. Wish I could remember more details, but at the time was trying to debug another problem entirely. -- Brian May <brian@microcomaustralia.com.au>
On 15/10/14 10:41, Trent W. Buck wrote:
The syntax is not as friendly as upstart, but this is a minor detail. [...] and doesn't interfere with muscle memory by still being able to do "service foo restart".
upstart supports "service foo restart".
Sorry, shouldn't have put that in the same paragraph. I didn't mean that in anything relating to upstart. I'm saying switching to systemd from upstart/sysvinit doesn't affect my muscle memory. That's all.
From a sysadmin perspective killing off pesky child processes is SO last century. You may well argue that every instance where child processes linger when the parent dies is a bug in the application. Well, good luck fixing every one. I'll see you next millennium. In the meantime, I'm enjoying getting actual work done.
Not sure what you mean by that.
There are many services that I run (some free software, some proprietary — either way, out of my domain) that don't close cleanly, leaving behind helper processes. For example, ejabberd leaves behind lots of erlang processes, exim leaves behind other little exims, various Ubiquiti management tools leave java and mongod processes behind...the list is endless. Their supplied initscripts fail at cleaning all this up, and arguably it would be possible to modify every initscript or source code within the application to fix all this, but in the meantime I have work to do. OR, I could put every service in a cgroup and have systemd automagically know what belongs with what with no extra effort. *dusts hands*
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd
Sure, I have played with cgroups naked when they first came out, but is hardly what I'd call a friendly UI. systemd makes them usable for dumb folks like me. Most of the "nice" things about cgroups come with systemd for free with no explicit configuration.
Hi, It seems to me that most of the problems that are *fixed* with systemd have other fixes already. And those that don't are getting the sledge hammer to fix them belatedly. I wish the Linux desktop would become far more reliable, like Linux servers; and there *should* be no need for systemd to fix the desktop problems and servers have no need for systemd. A.
Jeremy Visser <jeremy@visser.name> writes:
For example, ejabberd leaves behind lots of erlang processes, exim leaves behind other little exims, various Ubiquiti management tools leave java and mongod processes behind...the list is endless.
Their supplied initscripts fail at cleaning all this up, and arguably it would be possible to modify every initscript or source code within the application to fix all this, but in the meantime I have work to do.
OR, I could put every service in a cgroup and have systemd automagically know what belongs with what with no extra effort. *dusts hands*
The kernel has an option to automatically put stuff into cgroups. Anybody know if that is useful in such a context? IIRC it was targeted only at separate cgroups for each GUI login.
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd
Sure, I have played with cgroups naked when they first came out, but is hardly what I'd call a friendly UI. systemd makes them usable for dumb folks like me. Most of the "nice" things about cgroups come with systemd for free with no explicit configuration.
Now I'm wondering if systemd has exceptions for example * VMs started by libvirtd * GUI logins started from nodm such that if you restart the service (because of a software upgrade), it doesn't kill off the VMs. And if it does, who made the decision about which things should be exceptions. I had a problem under Ubuntu 10.04 where libvirtd's upstart service ignored VMs, which meant you could *restart* libvirtd (as happened on security upgrades) without restarting your VMs... but it also meant that at shutdown time, the VMs weren't cleanly shutdown. And it was nontrivial to patch in the latter without also introducing the former.
trentbuck@gmail.com (Trent W. Buck) writes:
OR, I could put every service in a cgroup and have systemd automagically know what belongs with what with no extra effort. *dusts hands*
The kernel has an option to automatically put stuff into cgroups. Anybody know if that is useful in such a context? IIRC it was targeted only at separate cgroups for each GUI login.
Ah, it was what I thought it was (via Craig's link): "But you don’t have to move a finger to get this benefit, the kernel already does that if you have CONFIG_SCHED_AUTOGROUP, which you should." https://felipec.wordpress.com/tag/sysvinit/ And a quick poke like <below> shows that Debian does it by default: # for i in /proc/*/exe; do echo "$(cat "${i%exe}autogroup")" "$(readlink "$i")"; done | sort -u | column -t
On Wed, 15 Oct 2014, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Jeremy Visser <jeremy@visser.name> writes:
From a sysadmin perspective [systemd] makes my life easier by bringing service control up to (and beyond) the standard of Windows, which has been able to supervise processes since, gosh, I only started counting in Windows 2000.
So sort of like djb daemontools or (as you mentioned) upstart? It's not like systemd is the first thing to do this in Linux.
The big problem with DJB daemontools is that they are written by DJB and he doesn't like doing things in the same way as everyone else. Anyone who's going to argue against change to old interfaces and software is going to hate anything from DJB.
The syntax is not as friendly as upstart, but this is a minor detail. [...] and doesn't interfere with muscle memory by still being able to do "service foo restart".
upstart supports "service foo restart".
Upstart was the second choice of the Debian technical committee...
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd :-)
Was there any other init before systemd that used cgroups? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Wed, Oct 15, 2014 at 09:34:45PM +1100, Russell Coker wrote:
On Wed, 15 Oct 2014, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Jeremy Visser <jeremy@visser.name> writes:
From a sysadmin perspective [systemd] makes my life easier by bringing service control up to (and beyond) the standard of Windows, which has been able to supervise processes since, gosh, I only started counting in Windows 2000.
So sort of like djb daemontools or (as you mentioned) upstart? It's not like systemd is the first thing to do this in Linux.
The big problem with DJB daemontools is that they are written by DJB and he doesn't like doing things in the same way as everyone else.
that accurately describes Lennart Pottering too. i know i'm not the only person who has described LP as "like DJB but without the talent to justify the arrogance". (i can't stand djb's software but it's undeniable that - even as misguided as he usually is - he know what he's doing when it comes to writing code. it might be doing the wrong thing, but it'll be doing it nearly perfectly)
Anyone who's going to argue against change to old interfaces and software is going to hate anything from DJB.
yep. and from LP too. daemontools sucked partly because it automagically did stuff just because files had been created in certain directories - this made it impossible to control when and how stuff got started or stopped because it would just do it whenever it felt like noticing changes had been made. qmail had similar problems - djb really like his programs to automagically do stuff without any ability to manually control it. djb's software also suffered from his brain-damaged ideas about copyright and licensing.
The syntax is not as friendly as upstart, but this is a minor detail. [...] and doesn't interfere with muscle memory by still being able to do "service foo restart".
upstart supports "service foo restart".
Upstart was the second choice of the Debian technical committee...
the TC was stacked with 2 upstart supporters, 2 systemd supporters, and the chairman also supported systemd. none of the other options (openrc, sysvinit) had a chance. the result was inevitable.
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd :-)
Was there any other init before systemd that used cgroups?
according to http://qnikst.github.io/posts/2013-02-20-openrc-cgroup.html openrc had "extended cgroups support" since at least feb 2013. i don't know if/when it had basic cgroups support before that. systemd proponents often tout "but systemd does cgroups" as if that's somehow remarkable or spectacularly difficult. it's not. they make the same "it's a miracle" claim for "socket activation" too as if that isn't something that inetd has been doing for decades (wow! listen on a port and then exec a program if something connects. so difficult!) a blogger by the name of Felipe Contreras wrote a good article (with sample code) called "Demystifying the init system" about a year ago in which he shows that these allegedly super-amazing and systemd-only features aren't particularly amazing or unique or special. https://felipec.wordpress.com/tag/sysvinit/ the things that systemd does that are useful aren't special or unique, and certainly aren't worth all the extra non-init baggage that systemd brings in. as an init system, there's nothing wrong with systemd. it's all the other stuff that it tries to do that's the problem...and it's getting kind of boring to hear systemd proponents respond to that particular point with tedious claims about systemd doing cgroups or having a wonderful scripting language (because sh is so scary) or some other irrelevant missing-the-point pseudo-rebuttal. the problem is not about systemd's init capabilities. the problem is all the other shit it tries to do. craig -- craig sanders <cas@taz.net.au>
2014-10-14 13:55 GMT+02:00 Chris Samuel <chris@csamuel.org>:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
I've installed archlinux on an old laptop when it was switching from init to systemd. The latter has been installed, together with a sort of compatibility layer aimed to let user to gradually get used to it. I don't use such pc often, and I don't get the time to study how to use systemd, but that's my fault, thus currently it doesn't work (e.g. I run "sudo dhclient eth0" to configure the network, "startx" to start the graphical desktop, and so on) Maybe I choose the wrong distro... -- Mick
2014-10-15 1:44 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
Michele Bert writes:
I run "sudo dhclient eth0" to configure the network
If you only have one iface, you can omit "eth0"; dhclient will try all ifaces by default.
I'm not 100% sure, but I think I tried (it was quite a long time ago), and I found that omitting the iface makes dhclient to timeout. It just a didactic machine I (should) use to learn how a GNU/Linux is built up and works. That's why I choose Arch distro. -- Mick
On 14/10/14 22:55, Chris Samuel wrote:
Hi all,
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
All the best, Chris hi
always been running Fedora here, had some problems 1> with network-manager (ditch it and used network scripts), static addresses 2> the mdadm raid (for /home RAID5*4 disks) does not always start on boot (used scripts), 3> rc.local is not started initially, so that needed one command several versions ago. 4> Added rsyslogd to the system instead of rewriting some monitoring scripts. 5> restart ntpd is in rc.local 6> restart nfs is rc.local 7> a command some versions ago was needed to use kdm instead of gdm only needed once, rather than a config file in /etc/sysconfig 8> start smb is in rc.local a lot of rc.local was written back in Fedora-17 and is probably legacy, it works so not touching it. Steve
On Tue, Oct 14, 2014 at 10:55 PM, Chris Samuel <chris@csamuel.org> wrote:
Hi all,
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
After seeing all the hubbub on here, I thought I might give it a go on my jessie laptop. Googled how to enable it, went to follow the instructions, only to find it was already enabled and has been working for a few months now. Was quite disappointed. As with Chris, my cats are still alive. / Brett
On 15 October 2014 10:11, Brett Pemberton <brett.pemberton@gmail.com> wrote:
As with Chris, my cats are still alive.
After using systemd, I believe I can say my cat is dead. Which is good, because he died of old age many years ago, and I would be a bit alarmed if this suddenly changed after running some computer software. -- Brian May <brian@microcomaustralia.com.au>
Chris Samuel <chris@csamuel.org> writes:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
I have a stub VM and a diskless kiosk running it, both jessie. Neither exploded, but the kiosk booted slower and I saw no real benefit. journalctl works mostly like logread except for its odious affection for underscores, and this [0], though I haven't run into it myself yet. It has some wanky regexps to make "important" lines in bold or color, except they didn't work very well because I saw at least one printk that had been split in half, and half that printk was considered an "important" line by the pattern matching. [0] https://wiki.archlinux.org/index.php/Systemd#Short_lived_processes_do_not_se...
On Tue, Oct 14, 2014 at 10:55:33PM +1100, Chris Samuel wrote:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
i've got it running on a laptop. as init, it seems to do what it's supposed to do. it doesn't do anything remarkable that's worth the overly tight integration of lots of other programs. every few upgrades i have to fight it to force it to disable some new shit that it has borged that i don't want it to do. i don't want it handling ntp or logging or dhcp or anything else - all i want init to do is init. if systemd limited itself to just init then i wouldn't care much whether i was running it or sysvinit or upstart or openrc, the differences just aren't important enough to give a damn about. it's the fact that systemd tries to do so many other completely unrelated things that make it a menace. anyway, the experience has been enough to make me determined to keep systemd off my main systems for as long as possible (hopefully forever, but that's unlikely due to systemd's creeping featuritis and the growing number of direct and indirect dependencies on systemd) systemd's sudden surprise takeover of power management resulted in it shutting down the laptop during an upgrade (remote via ssh while the lid was closed). it took me ages to figure out what the culprit was and to fix it by adding "HandleLidSwitch=ignore" to /etc/systemd/logind.conf. and then it happened again during another upgrade when logind.conf was replaced and systemd reloaded. that kind of dumb shit was fixed for, e.g., upgrades of sshd way back in the mid 90s (when upgrades of sshd could result in your ssh session dying and no ssh daemon running, leaving no way to login and finish the upgrade - i used to have to keep telnetd-ssl running just to work around that)....but learning from history is beneath the systemd developers. craig -- craig sanders <cas@taz.net.au>
On 14 October 2014 22:55, Chris Samuel <chris@csamuel.org> wrote:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
I've been running it for a while - it's a major component of CoreOS, and Ubuntu 14.04 has some support for it too. I have been quite bemused by all the commotion on this mailing list, because systemd has been completely fine. I can't believe people want to stick with SysV init scripts.. they're horrible! Personally, I'd have been happier with Upstart, but anything is better than sysv. -Toby
Toby Corkindale <toby@dryft.net> writes:
On 14 October 2014 22:55, Chris Samuel <chris@csamuel.org> wrote:
I'm curious after the recent storm about systemd to find out how many people have actually tried to use it?
I've been running it for a while - it's a major component of CoreOS, and Ubuntu 14.04 has some support for it too. I have been quite bemused by all the commotion on this mailing list, because systemd has been completely fine.
I can't believe people want to stick with SysV init scripts.. they're horrible! Personally, I'd have been happier with Upstart, but anything is better than sysv.
upstart is fine when it works. When it goes wrong, it's a lot harder to debug than sysvinit -- ESPECIALLY when it goes wrong before you have writable persistent filesystem mounted, because upstart's debugging options are "everything scrolls offscreen before you can read it" and "put 'exec >/tmp/log 2>&1' at the top of your exec script". At least, that was the state as at 10.04 when booting off NFS triggered a cyclic deadlock between upstart and their "temporary workaround" mountall(8), which I notice they are STILL shipping. Which I "fixed" by replacing one of their scripts with a loop that emits an even every tenth of a second saying, basically, "mountall(8), please run mount -a". Sigh. If it was sysvinit, I could have added a "set -x" to the top of one or two scripts and found the problem a lot faster. Like that time CentOS 4 was taking FORTY MINUTES to boot, and I eventually traced it down to a /etc/sysconfig/ifcfg-eth0.~1~ being owned by an LDAP user, and since RHEL don't know how to write shell scripts, they were doing basically for i in $(ls /etc/sysconfig/) And ls of course tries to resolve the UID until libnss-ldap eventually times out. If the problem is "idiots can't write init scripts in sh", the answer is not to let the idiots write them a new XDGish notation, the answer is to pick someone from each distro and get them to go fix all the scripts.[0] Which I'd have done for Debian, except that would involve arguing with people and it's a lot easier to just selfishly fix the problem on only MY machines. [0] yes, I realize stuff like mysql and nsd3 are special and hinky. But that doesn't excuse stuff like webfs having badly-written scripts, and those can be fixed in ninety seconds. At least, as long as you don't have to worry about not bricking things in all all the different .preinst upgrade paths (which I would have to if I tried to fix them for everyone, not just me.)
participants (13)
-
Allan Duncan -
Andrew McGlashan -
Brett Pemberton -
Brian May -
Chris Samuel -
Craig Sanders -
James Harper -
Jeremy Visser -
Michele Bert -
Russell Coker -
Steve Roylance -
Toby Corkindale -
trentbuck＠gmail.com