Re: [gentoo-user] technical review of systemd

[Canek Peláez Valdés]

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"?

>> 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.

>>> 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.

[ 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.

> 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
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México