Re: [gentoo-user] technical review of systemd

[thegeezer]

On 02/23/2014 06:01 PM, Canek Peláez Valdés wrote:
> On Sun, Feb 23, 2014 at 5:06 AM,  <thegeezer@×××××××××.net> wrote:
> [ snip ]
>>> Corrupt filesystems or logs?
>> logs.  currently if fsck runs anywhere on boot i get zero log about what
>> was done, so i prefer to do this on a running system.  / is obviously
>> special, so this is a pro that fsck is logged, but of course if / has
>> issue i'm not sure what systemd would do other than drop you to emergency
> Mmmmh;
>
> centurion ~ # journalctl /usr/lib/systemd/systemd-fsck -b
> -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Sun 2014-02-23
> 11:37:30 CST. --
> Feb 18 23:49:16 centurion systemd-fsck[1047]: Centurion: clean,
> 1054301/3389904 files, 10171017/13533184 blocks
> Feb 18 23:49:17 centurion systemd-fsck[1531]: Data: clean,
> 308819/30531584 files, 105744823/122096390 blocks
> Feb 18 23:49:17 centurion systemd-fsck[1568]: Files: clean,
> 509045/9773056 files, 20704341/39072470 blocks
>
> I mean; my file systems were clean, but if some output was generated,
> it would be there.
>
> I don't think I understand what do you mean by "zero log"?

using openrc if i reboot a system that requires fsck on /mnt/data it
will do an fsck. but not log anything anywhere about the result, which
is why i put this as a pro.
does systemd have configurable options for '/' so that it can run
readonly rather than dropping to emergency in case of problems?

>>> It's been a while since I've read the source code, but it isn't in
>>> src/activate/activate.c[3]?
>> ok so it does look like it would have a systemd-activate process for each
>> socket being activated on behalf of a service. that makes me feel better
>> than one process doing all of them. perhaps someone using service
>> activation can do a 'ps aux' to confirm?
> It is one instance of systemd-activate for each socket; I don't have
> any  socket activated service waiting for the first connection at this
> moment, but it's obvious from the source code, I believe. It waits in
> a loop for a connection, if specified it accepts it, and then launches
> the service.
>
> [ snip ]
>
>>>> 7.chroots no longer work. forcing use of nspawn to ensure environment
>>>> set
>>>> up correctly.
>>> I'm sorry, chroot doesn't work? First time I heard about it. While
>>> systemd-nspawn is a gazillion times better than a simple chroot, you
>>> *can* still use a chroot if you so desire. Where did you found that
>>> chroot doesn't works?
>> agreed nspawn is better due to the filesystem namespaces.  chroot itself
>> works, but the environment doesn't so it is effectively broken.  full
>> explaination from lennart's blog [5]  This is quite old so i don't know if
>> this has been fixed, seems unlikely based on what he described
> Oh, I see. Yeah; you cannot longer start a service inside a chroot;
> but in the blog post you cited [5], there is a recipe to launch a
> chroot inside a unit file, working around this limitation. And, if you
> are running systemd and want jailed services, systemd-nspawn works so
> much better.
>
> For non service-start-up-and-management stuff (for example, boot from
> a non-systemd LiveCD and emerge something you forgot that you need),
> chroot still works.
>
> So, there is a workaround if you want to keep using chroot for jailed
> services, and there's a better alternative.
>
> [ snip ]
>
>>> networkd (again, netctl is the command-line front-end) is not for
>>> enterprise networks; on the contrary, is for the trivial cases. For
>>> example, in a little web server I administer I have:
>>>
>>> $ cat /etc/systemd/system/network.service
>>> [Unit]
>>> Description=Static network service
>>> After=local-fs.target
>>> Before=network.target
>>> Documentation=man:ifconfig(8)
>>> Documentation=man:route(8)
>>>
>>> [Service]
>>> Type=oneshot
>>> RemainAfterExit=yes
>>> ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255
>>> netmask 255.255.255.0 up
>>> ExecStart=/bin/route add default gw 192.168.1.1 enp2s12
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>> (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time
>>> yet).
>>>
>>> I'm going to get rid of this trivial network.service unit file when
>>> 209 (or better 210) hits Gentoo. Cases like this are the use-cases for
>>> networkd.
>> what i don't understand is if you look at how openRC does it, it only
>> really cares about up/down events and the /etc/conf.d/net is very
>> comprehensive, in part because it passes everything to iproute2 to handle,
>> the only thing i can't do without an additional shell script is tc qdiscs.
>> i don't need or want a network manager, just need something that applies
>> confs on startup / stop of interfaces.  I'm a little surprised that there
>> isn't an iproute2 .service file
>>
>> reading through your example, in fact this is preferrable to me than using
>> a network manager but using iproute2.  I would rather you keep this
>> example in, and have this shown on the wiki or somewhere as this neatly
>> resolves my network concern.
> Mmmh. Maybe I wasn't clear; in your case, it seems that
> iproute2+OpenRC *is* your network manager.
>
> Perhaps at some point networkd will gain the ability to use iproute2
> (or even absorb it), but right now is only for tiny little setups.

can you please clarify what you mean by absorbing iproute2?

>>>> 10.strange gotchas: /tmp being tmpfs using up to 50% ram.   unless
>>>> mounted
>>>> in fstab
>>> That doesn't have nothing to do with systemd: from man:mount(8):
>>>
>>> """
>>> Mount options for tmpfs
>>>        size=nbytes
>>>               Override  default  maximum  size  of  the  filesystem.
>>> The size is given in bytes, and rounded up to entire pages.  The
>>> default is half of the memory. The size parameter also
>>>               accepts a suffix % to limit this tmpfs instance to that
>>> percentage of your physical RAM: the default, when neither size nor
>>> nr_blocks is specified, is size=50%
>>> """
>>>
>>> systemd just mounts the tmpfs; the default *is* 50%.
>>>
>> I was just highlighting because someone could be putting systemd on
>> embedded and wondering why memory usage increased over time. no issue if
>> you have 8GB+, but if you have 256MB is an issue, and if you have less you
>> are counting every byte.
> Yeah, but again, it has nothing to do with systemd: the default *is*
> 50% for tmpfs'. Embedded guys need to know this independently of if
> they use systemd or not.
the only reason that i bring this up is because if you _don't_ use
systemd then /tmp is a folder hanging off /
if you _do_ use systemd it will try to mount it tmpfs
not everyone will realise this which is why i listed it as a 'gotcha' --
a nuance in working with it but not a major issue.
> [ snip ]
>
>>>> 12.transitions into systemd are non-trivial.
>>> No, they are not.
>> i'm not talkign about new installs.
> [ sniped rest with which I concur ]
>
> I'm sorry, I think I expressed myself incorrectly. When you said
> "transitions into systemd are non-trivial", I answered "No, they are
> not", meaning "No, they are not trivial". In other words, I agree with
> you.
>
> Sorry for the confusion.

thanks for the clearing up

>> I think actually that i would just create an iproute2 service file for
>> each device.  so have no network manager at all and have the service file
>> start after the interface.   iproute2.enp2s0.service etc
>> in there i would have "exec=/sbin/ip rule add" etc
>> i'd also have "exec=/sbin/ip addr add" etc
> Having a "network manager" doesn't necessarily means having a big
> monolithic thing that sets up your network. If you use some
> scripts+conf with iproute2 to set up your network, then *that's* your
> network manager.
>
> The point of networkd (if I understand correctly), is that if you
> *need* iproute2 (I don't have it installed in any of my machines), or
> highly dynamic non-trivial network configurations, then networkd will
> not be enough.
>
> And, by the way, someone make me notice that netctl is an Arch'ism,
> and that the command-line front-end for networkd is actually
> networkctl.
>
>>>> As Gentoo is a meta-distro (says Larry the Cow
>>>> http://www.gentoo.org/main/en/about.xml) and a rolling release distro,
>>>> I'm
>>>> all for choice, but I would sincerely hope that unlike all of the other
>>>> distributions from Arch to Ubuntu systemd is not adopted by default as
>>>> udev and baselayout transitions were bad enough.
>>> As a systemd supporter, at some point in the long, long future, I
>>> would be more than happy if systemd was added to the handbook as
>>> "secondary supported init system" in its own section. I'm completely
>>> fine with OpenRC as the default.
>> that would be the ideal way forwards
> Glad to see you don't disapprove.
>
>>> Also (and I plan to work on this in the future), I would like to have
>>> LiveCDs and stages with systemd installed (not necessarily hosted in
>>> the Gentoo infrastructure), because is works really nicely install
>>> Gentoo from systemd-nspawn instead of a chroot.
>> actually I agree - even if it is only to get journactl on a bootable cd!
> :D
>
>>> Someone would have to do that, though; I hope to help with that in the
>>> future.
>> to end on a merry note [6] and kind of why i wrote this
> Thanks for sharing.
>
> Regards.
>
>>>> I will however be installing a systemd desktop in a vm to play properly.
>>>> YMMV
>>> Thanks again for a succinct, impartial and objective analysis of systemd.
>> very welcome, hope this helps others
>>
>>> Regards.
>>>
>>> [1]
>>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/sshd.service?view=markup
>>> [2]
>>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/sshd.socket?view=markup
>>> [3] http://cgit.freedesktop.org/systemd/systemd/tree/src/activate
> [ snip sig ]
>> [4] http://wiki.gentoo.org/wiki/Systemd
>> [5] http://0pointer.de/blog/projects/changing-roots.html
>> [6]
>> http://allpoetry.com/poem/9326367-Everybody--Anybody--Somebody--Nobody-and-Someone-Else-by-YoungDumbCrazy