Gentoo Archives: gentoo-user

From: thegeezer@×××××××××.net
To: gentoo-user@l.g.o
Subject: [gentoo-user] technical review of systemd
Date: Sun, 23 Feb 2014 00:17:09
Message-Id: 07d8cf1108b4a5d52cdf81cb51db1887.squirrel@
1 OK so because of how much time has been spent arguing about systemd with
2 little technical content, i've spent some time on the freedesktop site
3 reading Lennart's blog and also going through the source to find answers
4 to my questions about the socket activator.
5 i've also been going through the man pages of netctl too and am horrified
6 at the lack of what i would call enterprise features.
8 this is by no means a definitive list.
9 I just thought that i would share what i had found.
10 please correct me if i am wrong in any of these.
11 please add to the list for technical items only.
13 thanks!
15 pros
16 1.very modular, everything can be disabled though not removed
17 2.socket based activator allows restart of services with no service
18 interruption
19 3.if activator.c is used for this, then the code is actually pretty clean
20 using supplied sd-daemon.c simplifies sockets for daemons and also adds
21 extra watchdog features
22 4.can disable socket based activation according to Canek, but i can't find
23 how.
24 5.fschecking mounts and logging output (though how for corrupt / notsure)
25 allows for lower numbered X windows by default for e.g.
26 multiseat and dynamic serial ttys
27 7.clever logging, including from nspawned containers' logs and distributed
28 for enterprise
29 8.nspawning using filename namespaces
30 9.systemctl kill <service> -- killing service and all forks and spawn
31 cgtop -- top with cgroups
32 10.much easier to define resource limitations per service
34 cons
35 tools to learn, new gotchas to learn.
36 2.yet to go through systemd source to find out how modular or not it is.
37 3.not clear how the socket activator works, the code activator.c appears
38 to be to _test_ activation only, with activator code being elsewhere. if
39 it is used then you would have one process running for each port it is
40 virtually listened to.
41 4./etc/machine-id because hostname and node id in the <cluster of your
42 choice> are not enough.
43 5./fsck.options gives more options than "auto""force""skip" on reboot
44 6.requiring logging tools in rescue cds in order to view logs
45 7.chroots no longer work. forcing use of nspawn to ensure environment set
46 up correctly.
47 8.strange gotchas: that because of socket/dbus etc activation you have to
48 disable a service first, then stop it in case it is then restarted in the
49 background
50 9.the new deal breaker for me is the networking.
51 for anything remotely complex (i.e. two IP addresses on an interface woo),
52 need to use netctl.
53 a.which doesn't support vlan naming types i.e. padding zeroes
54 b.doesn't appear to support gre keys
55 c.doesn't appear to support multiple routing tables
56 d.doesn't appear to support "ip rule"
57 e.doesn't have lacp support for bonding
58 f.there is the option for running a script in PRE and POST UP
59 10.strange gotchas: /tmp being tmpfs using up to 50% ram. unless mounted
60 in fstab
61 11.strange gotchas: logging is volatile by default _unless_
62 /var/log/journal exists, when it becomes persistent due to the "auto"
63 default.
64 12.transitions into systemd are non-trivial.
67 my own conclusions
68 systemd seems to be excellent for a desktop
69 good for _new_ instances of service VMs. I say new because of the large
70 job of transitioning away from openRC, but all the watchdog and better
71 resource management will help to pack datacentres.
72 It would also be good for big iron running many services because of this,
73 but then i thought everyone was using small fast service specific gentoo
74 VMs to compartmentalise anyway --- or was that just me?
75 Unless I have completely got netctl wrong it is terrible for a
76 firewall/router scenario, or being the host server for LXC containers
77 which is a shame because resource management built in to service control
78 combined with say would be a great combination; as long as you
79 don't use custom VLAN settings.
81 As Gentoo is a meta-distro (says Larry the Cow
82 and a rolling release distro, I'm
83 all for choice, but I would sincerely hope that unlike all of the other
84 distributions from Arch to Ubuntu systemd is not adopted by default as
85 udev and baselayout transitions were bad enough.
86 I will however be installing a systemd desktop in a vm to play properly.


Subject Author
Re: [gentoo-user] technical review of systemd "Canek Peláez Valdés" <caneko@×××××.com>