[gentoo-user] technical review of systemd

[gentoo-user] technical review of systemd

[thegeezer]

OK so because of how much time has been spent arguing about systemd with
little technical content, i've spent some time on the freedesktop site
reading Lennart's blog and also going through the source to find answers
to my questions about the socket activator.
i've also been going through the man pages of netctl too and am horrified
at the lack of what i would call enterprise features.

this is by no means a definitive list.
I just thought that i would share what i had found.
please correct me if i am wrong in any of these.
please add to the list for technical items only.

thanks!

pros
1.very modular, everything can be disabled though not removed
2.socket based activator allows restart of services with no service
interruption
3.if activator.c is used for this, then the code is actually pretty clean
using supplied sd-daemon.c simplifies sockets for daemons and also adds
extra watchdog features
4.can disable socket based activation according to Canek, but i can't find
how.
5.fschecking mounts and logging output (though how for corrupt / notsure) 
6.auto-gettys allows for lower numbered X windows by default for e.g.
multiseat and dynamic serial ttys
7.clever logging, including from nspawned containers' logs and distributed
for enterprise
8.nspawning using filename namespaces
9.systemctl kill <service> -- killing service and all forks and spawn
cgtop -- top with cgroups
10.much easier to define resource limitations per service

cons
1.new tools to learn, new gotchas to learn.
2.yet to go through systemd source to find out how modular or not it is.
3.not clear how the socket activator works, the code activator.c appears
to be to _test_ activation only, with activator code being elsewhere.  if
it is used then you would have one process running for each port it is
virtually listened to.
4./etc/machine-id   because hostname and node id in the <cluster of your
choice> are not enough.
5./fsck.options gives more options than "auto""force""skip" on reboot 
6.requiring logging tools in rescue cds in order to view logs
7.chroots no longer work. forcing use of nspawn to ensure environment set
up correctly.
8.strange gotchas: that because of socket/dbus etc activation you have to
disable a service first, then stop it in case it is then restarted in the
background
9.the new deal breaker for me is the networking.
for anything remotely complex (i.e. two IP addresses on an interface woo),
need to use netctl.
 a.which doesn't support vlan naming types i.e. padding zeroes
 b.doesn't appear to support gre keys
 c.doesn't appear to support multiple routing tables
 d.doesn't appear to support "ip rule"
 e.doesn't have lacp support for bonding
 f.there is the option for running a script in PRE and POST UP but...no
10.strange gotchas: /tmp being tmpfs using up to 50% ram.   unless mounted
in fstab
11.strange gotchas: logging is volatile by default _unless_
/var/log/journal exists, when it becomes persistent due to the "auto"
default.
12.transitions into systemd are non-trivial.


my own conclusions
systemd seems to be excellent for a desktop
good for _new_ instances of service VMs. I say new because of the large
job of transitioning away from openRC, but all the watchdog and better
resource management will help to pack datacentres.
It would also be good for big iron running many services because of this,
but then i thought everyone was using small fast service specific gentoo
VMs to compartmentalise anyway --- or was that just me?
Unless I have completely got netctl wrong it is terrible for a
firewall/router scenario, or being the host server for LXC containers
which is a shame because resource management built in to service control
combined with say docker.io would be a great combination; as long as you
don't use custom VLAN settings.

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.
I will however be installing a systemd desktop in a vm to play properly.
YMMV

Re: [gentoo-user] technical review of systemd

[Canek Peláez Valdés]

On Sat, Feb 22, 2014 at 6:16 PM,  <thegeezer@thegeezer.net> wrote:
> OK so because of how much time has been spent arguing about systemd with
> little technical content, i've spent some time on the freedesktop site
> reading Lennart's blog and also going through the source to find answers
> to my questions about the socket activator.
> i've also been going through the man pages of netctl too and am horrified
> at the lack of what i would call enterprise features.

networkd (netctl is just the command-line front-end) is not intended
for enterprise; it's for little servers where you only need static IPs
or simple bridges. For desktops/laptops, you are supposed to keep
using NetworkManager/connman/whatever you used before. For complex
network setups, you need *a* network manager (not necessarily
NetworkManager).

> this is by no means a definitive list.
> I just thought that i would share what i had found.
> please correct me if i am wrong in any of these.
> please add to the list for technical items only.

I find it a very impartial and objective review; thank you very much!

> thanks!
>
> pros
> 1.very modular, everything can be disabled though not removed
> 2.socket based activator allows restart of services with no service
> interruption
> 3.if activator.c is used for this, then the code is actually pretty clean
> using supplied sd-daemon.c simplifies sockets for daemons and also adds
> extra watchdog features
> 4.can disable socket based activation according to Canek, but i can't find
> how.

You use a .service unit file instead of a .socket unit file. That's it.

For OpenSSH, for example, you can enable sshd.service[1], and then the
SSH daemon works as it does in OpenRC. If you instead enable
sshd.socket[2], then the daemon will start on demand.

You don't have to *disable* anything; you choose how do you want to
use your services (if the services provide both ways, like OpenSSH
does).

> 5.fschecking mounts and logging output (though how for corrupt / notsure)

Corrupt filesystems or logs?

> 6.auto-gettys allows for lower numbered X windows by default for e.g.
> multiseat and dynamic serial ttys
> 7.clever logging, including from nspawned containers' logs and distributed
> for enterprise
> 8.nspawning using filename namespaces
> 9.systemctl kill <service> -- killing service and all forks and spawn
> cgtop -- top with cgroups
> 10.much easier to define resource limitations per service
>
> cons
> 1.new tools to learn, new gotchas to learn.
> 2.yet to go through systemd source to find out how modular or not it is.

While it tries to be modular where it can, systemd prefers simple code
and integrated solutions. Modularity is not going to be one of its
strong points.

> 3.not clear how the socket activator works, the code activator.c appears
> to be to _test_ activation only, with activator code being elsewhere.  if
> it is used then you would have one process running for each port it is
> virtually listened to.

It's been a while since I've read the source code, but it isn't in
src/activate/activate.c[3]?

> 4./etc/machine-id   because hostname and node id in the <cluster of your
> choice> are not enough.

The idea is that machine-id is as unique as reasonable to ask. I'm not
overly happy with it, too, but that's the justification.

Imagine thousands of virtual machines running services, and you want
to coalesce all their journal logs in a central server. With
machine-id, you don't need to worry even to change the default
"localhost" for your throwaway VMs, you can detect the different logs
immediately (machine-id should be generated at OS install time; for
rolling distros, I think they generate it if when installing systemd
is not available.)

> 5./fsck.options gives more options than "auto""force""skip" on reboot
> 6.requiring logging tools in rescue cds in order to view logs

Yeah, that's a drag. However, you *can* run rsyslog (or syslog-ng)
alongside the journal, and have the best of both worlds. Or you can
automatically send the journal logs to a central server designed for
that purpose only.

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

> 8.strange gotchas: that because of socket/dbus etc activation you have to
> disable a service first, then stop it in case it is then restarted in the
> background

You only need to stop the socket too. You can do it at the same time:

systemctl stop avahi-daemon.service  avahi-daemon.socket

> 9.the new deal breaker for me is the networking.
> for anything remotely complex (i.e. two IP addresses on an interface woo),
> need to use netctl.
>  a.which doesn't support vlan naming types i.e. padding zeroes
>  b.doesn't appear to support gre keys
>  c.doesn't appear to support multiple routing tables
>  d.doesn't appear to support "ip rule"
>  e.doesn't have lacp support for bonding
>  f.there is the option for running a script in PRE and POST UP but...no

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.

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

> 11.strange gotchas: logging is volatile by default _unless_
> /var/log/journal exists, when it becomes persistent due to the "auto"
> default.

It's by design; a distro can decide if it creates /var/log/journal or
nor for its users at install time. RHEL probably will; Ubuntu
(desktop) probably wont.

> 12.transitions into systemd are non-trivial.

No, they are not.

> my own conclusions
> systemd seems to be excellent for a desktop
> good for _new_ instances of service VMs. I say new because of the large
> job of transitioning away from openRC, but all the watchdog and better
> resource management will help to pack datacentres.

I agree.

> It would also be good for big iron running many services because of this,
> but then i thought everyone was using small fast service specific gentoo
> VMs to compartmentalise anyway --- or was that just me?

I think Gentoo users come in all sizes and shapes ;)

> Unless I have completely got netctl wrong it is terrible for a
> firewall/router scenario, or being the host server for LXC containers
> which is a shame because resource management built in to service control
> combined with say docker.io would be a great combination; as long as you
> don't use custom VLAN settings.

I think you got it wrong; it's just to fill the needs of simple
networks when you don't want all the bells and whistles of a big
network manager (not necessarily NetworkManager).

BTW, Kay and Lennart Ok'd the inclusion of networkd (and they had
thought it was missing from systemd), but it was written by Tom
Gundersen, primarily.

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

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.

Someone would have to do that, though; I hope to help with that in the future.

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

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

Re: [gentoo-user] technical review of systemd

[thegeezer]

> On Sat, Feb 22, 2014 at 6:16 PM,  <thegeezer@thegeezer.net> wrote:
>> OK so because of how much time has been spent arguing about systemd with
>> little technical content, i've spent some time on the freedesktop site
>> reading Lennart's blog and also going through the source to find answers
>> to my questions about the socket activator.
>> i've also been going through the man pages of netctl too and am
>> horrified
>> at the lack of what i would call enterprise features.
>
> networkd (netctl is just the command-line front-end) is not intended
> for enterprise; it's for little servers where you only need static IPs
> or simple bridges. For desktops/laptops, you are supposed to keep
> using NetworkManager/connman/whatever you used before. For complex
> network setups, you need *a* network manager (not necessarily
> NetworkManager).
>
>> this is by no means a definitive list.
>> I just thought that i would share what i had found.
>> please correct me if i am wrong in any of these.
>> please add to the list for technical items only.
>
> I find it a very impartial and objective review; thank you very much!
>
>> thanks!
>>
>> pros
>> 1.very modular, everything can be disabled though not removed
>> 2.socket based activator allows restart of services with no service
>> interruption
>> 3.if activator.c is used for this, then the code is actually pretty
>> clean
>> using supplied sd-daemon.c simplifies sockets for daemons and also adds
>> extra watchdog features
>> 4.can disable socket based activation according to Canek, but i can't
>> find
>> how.
>
> You use a .service unit file instead of a .socket unit file. That's it.
>

thanks good to know that is all you need

> For OpenSSH, for example, you can enable sshd.service[1], and then the
> SSH daemon works as it does in OpenRC. If you instead enable
> sshd.socket[2], then the daemon will start on demand.
>
> You don't have to *disable* anything; you choose how do you want to
> use your services (if the services provide both ways, like OpenSSH
> does).
>
>> 5.fschecking mounts and logging output (though how for corrupt /
>> notsure)
>
> 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

>> 6.auto-gettys allows for lower numbered X windows by default for e.g.
>> multiseat and dynamic serial ttys
>> 7.clever logging, including from nspawned containers' logs and
>> distributed
>> for enterprise
>> 8.nspawning using filename namespaces
>> 9.systemctl kill <service> -- killing service and all forks and spawn
>> cgtop -- top with cgroups
>> 10.much easier to define resource limitations per service
>>
>> cons
>> 1.new tools to learn, new gotchas to learn.
>> 2.yet to go through systemd source to find out how modular or not it is.
>
> While it tries to be modular where it can, systemd prefers simple code
> and integrated solutions. Modularity is not going to be one of its
> strong points.
>
>> 3.not clear how the socket activator works, the code activator.c appears
>> to be to _test_ activation only, with activator code being elsewhere.
>> if
>> it is used then you would have one process running for each port it is
>> virtually listened to.
>
> 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?

>> 4./etc/machine-id   because hostname and node id in the <cluster of your
>> choice> are not enough.
>
> The idea is that machine-id is as unique as reasonable to ask. I'm not
> overly happy with it, too, but that's the justification.
>
> Imagine thousands of virtual machines running services, and you want
> to coalesce all their journal logs in a central server. With
> machine-id, you don't need to worry even to change the default
> "localhost" for your throwaway VMs, you can detect the different logs
> immediately (machine-id should be generated at OS install time; for
> rolling distros, I think they generate it if when installing systemd
> is not available.)
>
>> 5./fsck.options gives more options than "auto""force""skip" on reboot
>> 6.requiring logging tools in rescue cds in order to view logs
>
> Yeah, that's a drag. However, you *can* run rsyslog (or syslog-ng)
> alongside the journal, and have the best of both worlds. Or you can
> automatically send the journal logs to a central server designed for
> that purpose only.
>
>> 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

>> 8.strange gotchas: that because of socket/dbus etc activation you have
>> to
>> disable a service first, then stop it in case it is then restarted in
>> the
>> background
>
> You only need to stop the socket too. You can do it at the same time:
>
> systemctl stop avahi-daemon.service  avahi-daemon.socket
>

good to know

>> 9.the new deal breaker for me is the networking.
>> for anything remotely complex (i.e. two IP addresses on an interface
>> woo),
>> need to use netctl.
>>  a.which doesn't support vlan naming types i.e. padding zeroes
>>  b.doesn't appear to support gre keys
>>  c.doesn't appear to support multiple routing tables
>>  d.doesn't appear to support "ip rule"
>>  e.doesn't have lacp support for bonding
>>  f.there is the option for running a script in PRE and POST UP but...no
>
> 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.

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

>> 11.strange gotchas: logging is volatile by default _unless_
>> /var/log/journal exists, when it becomes persistent due to the "auto"
>> default.
>
> It's by design; a distro can decide if it creates /var/log/journal or
> nor for its users at install time. RHEL probably will; Ubuntu
> (desktop) probably wont.
>
>> 12.transitions into systemd are non-trivial.
>
> No, they are not.

i'm not talkign about new installs.  for me the transition is not easy. 
most of my gentoo boxes are headless, and many are in far flung places.  a
migration into systemd would be a nightmare of repeatedly checking items
to ensure the reboot would succeed remotely, and have a working network
connection and working sshd.  in a previous post i mentioned that i would
need to do the following, requiring at least two reboots from gentoo wiki
[4]
.. new kernel options
.. reboot
.. new grub2 command line
.. install dbus (use=-systemd) _then_ systemd
.. create network.service as you have shown
.. add grub secondary entry with systemd init and reboot
.. would be nice to use an import for localed and hostnamed and timedated
.. importing openrc services and runlevels to targets
.. adjust syslog and systemd to work together
also there are 'workarounds' for lvm early masking -- i use LVM everywhere
and i wouldn't know which location would need this or if my boot was
broken for another reason.

a trivial migration would be
# emerge systemd (auto removes openrc)
# systemd-import-openrc (including network issues as mentioned in this post)
# reboot

>
>> my own conclusions
>> systemd seems to be excellent for a desktop
>> good for _new_ instances of service VMs. I say new because of the large
>> job of transitioning away from openRC, but all the watchdog and better
>> resource management will help to pack datacentres.
>
> I agree.
>
>> It would also be good for big iron running many services because of
>> this,
>> but then i thought everyone was using small fast service specific gentoo
>> VMs to compartmentalise anyway --- or was that just me?
>
> I think Gentoo users come in all sizes and shapes ;)
>
>> Unless I have completely got netctl wrong it is terrible for a
>> firewall/router scenario, or being the host server for LXC containers
>> which is a shame because resource management built in to service control
>> combined with say docker.io would be a great combination; as long as you
>> don't use custom VLAN settings.
>
> I think you got it wrong; it's just to fill the needs of simple
> networks when you don't want all the bells and whistles of a big
> network manager (not necessarily NetworkManager).
>
> BTW, Kay and Lennart Ok'd the inclusion of networkd (and they had
> thought it was missing from systemd), but it was written by Tom
> Gundersen, primarily.
>

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

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

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

> 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

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

[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

Re: [gentoo-user] technical review of systemd

[Canek Peláez Valdés]

On Sun, Feb 23, 2014 at 5:06 AM,  <thegeezer@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

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

Re: [gentoo-user] technical review of systemd

[Canek Peláez Valdés]

On Mon, Feb 24, 2014 at 3:09 AM, thegeezer <thegeezer@thegeezer.net> wrote:

[snip]

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

Oh, I see; I hadn't understood this.

> does systemd have configurable options for '/' so that it can run
> readonly rather than dropping to emergency in case of problems?

I believe you can run systemd out-of-the-box with / being RO. That's
why /run and /run/lock are tmpfs' and they are available basically
from the very beginning, and the reason /etc/mtab is a link to
/proc/self/mounts. You need /var and some other stuff RW, if you want
permanent logs and stuff, though.

[snip]

> can you please clarify what you mean by absorbing iproute2?

I don't use iproute2, so I don't know how big or complex it is; but if
it's small and simple, it could just be absorbed in the systemd repo,
like hwclock was [1].

*This is only speculation from my part*. I don't know how networkd
would evolve in the future; perhaps it will always remain a little
tool for trivial configurations only. And even if it evolves to cover
every possible configuration on Earth, they will go with a different
route from iproute2.

[snip]

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

OK, thanks for the clarification.

[ snip ]

> thanks for the clearing up

No prob.

Regards.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/hwclock.c
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: technical review of systemd

[Nicolas Sebrecht]

The 23/02/14, Canek Peláez Valdés wrote:

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

The way systemd services handle network whatever "network manager" you
enable is the last thing preventing me from using systemd on servers.
Seting up manual advanced setups on systemd looks crappy (if even
possible with the provided tools) compared to OpenRC.

Notice that iproute2 is the default everywhere for long time, here.

The OpenRC comprehensive configuration set for network management is
actually what I would expect in systemd.

<...>

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

Yes, it was taken from Arch in order to allow better network support for
advanced configurations whitout requiring to write yet another tool.

The thing is that I would expect systemd to handle the whole thing on
its own (with the help of iproute2) so that services have nice
grain-level dependencies.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: technical review of systemd

[Canek Peláez Valdés]

On Tue, Feb 25, 2014 at 5:38 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

[snip]

> The way systemd services handle network whatever "network manager" you
> enable is the last thing preventing me from using systemd on servers.
> Seting up manual advanced setups on systemd looks crappy (if even
> possible with the provided tools) compared to OpenRC.
>
> Notice that iproute2 is the default everywhere for long time, here.
>
> The OpenRC comprehensive configuration set for network management is
> actually what I would expect in systemd.

Perhaps they are starting small? I don't know; from what I've read,
they want something small for simple cases, and if you need more you
can use NetworkManager, connman, iproute2, or whatever.

But then you had to configure it yourself.

[snip]

>> 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.
>
> Yes, it was taken from Arch in order to allow better network support for
> advanced configurations whitout requiring to write yet another tool.

Nothing was taken from Arch, I believe. networkctl and netctl had
nothing to do with each other.

> The thing is that I would expect systemd to handle the whole thing on
> its own (with the help of iproute2) so that services have nice
> grain-level dependencies.

If someone writes support for this and convinces the systemd
maintainers that is a good idea, I think they would accept the
patches.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: technical review of systemd

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On Feb 25, 2014 10:40 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>
> On Tue, Feb 25, 2014 at 5:38 AM, Nicolas Sebrecht <nsebrecht@piing.fr>
wrote:
>
> [snip]
>
> > The way systemd services handle network whatever "network manager" you
> > enable is the last thing preventing me from using systemd on servers.
> > Seting up manual advanced setups on systemd looks crappy (if even
> > possible with the provided tools) compared to OpenRC.
> >
> > Notice that iproute2 is the default everywhere for long time, here.
> >
> > The OpenRC comprehensive configuration set for network management is
> > actually what I would expect in systemd.
>
> Perhaps they are starting small? I don't know; from what I've read,
> they want something small for simple cases, and if you need more you
> can use NetworkManager, connman, iproute2, or whatever.
>
> But then you had to configure it yourself.
>
> [snip]
>
> >> 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.
> >
> > Yes, it was taken from Arch in order to allow better network support for
> > advanced configurations whitout requiring to write yet another tool.
>
> Nothing was taken from Arch, I believe. networkctl and netctl had
> nothing to do with each other.
>
> > The thing is that I would expect systemd to handle the whole thing on
> > its own (with the help of iproute2) so that services have nice
> > grain-level dependencies.
>
> If someone writes support for this and convinces the systemd
> maintainers that is a good idea, I think they would accept the
> patches.

BTW, here is an overview of networkd by its author:

https://coreos.com/blog/intro-to-systemd-networkd/

Regards.

[-- Attachment #2: Type: text/html, Size: 2388 bytes --]

[gentoo-user] Re: technical review of systemd

[Nicolas Sebrecht]

The 25/02/14, Canek Peláez Valdés wrote:

> Perhaps they are starting small? I don't know; 

I'm pretty sure they are. BTW, things are moving fast and the state
has already changed since my last check (not so old).

>                                                from what I've read,
> they want something small for simple cases, and if you need more you
> can use NetworkManager, connman, iproute2, or whatever.
> 
> But then you had to configure it yourself.

NetworkManager and ConnMan are the big ones. Wicked (the one I use on my
laptop) looks a bit lighter. But none intend advanced, static, and easy
text configuration files for admins as usually required for servers.

Write your own tool is a bad advice for most people as I would expect
either a poor alternative or a lot of work to get a descent one.  I
think experiented developers already know they can write their own and
evaluate how hard it can be. So, they won't wait for this kind of advice
on this list to get the job done. ,-p

That beeing said, I think I understand why you write that again and
again. From what I've read recently, I guess too much people do not
clearly understand all of the refinements coming with FOSS in
corporation relationships, innovation "mentoring" or software adoption
constraints. The cabale remains tempting as it can explain everything.

Anyway, systemd-networkd (introduced in systemd-209) is written to fill
this gap. Good news.

> Nothing was taken from Arch, I believe. networkctl and netctl had
> nothing to do with each other.

I'm sorry. I think I've read that networkd did take inspiration from
netctl for the structure of configuration files at some point; not
really what I said yesterday (hugh!). Don't even know if it actually was
the case.

I have to refresh my skills on the topic with a bit more homework,
again. Didn't expect things have changed that much in a few time.  :-)

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: technical review of systemd

[Stefan G. Weichinger]

Am 25.02.2014 12:38, schrieb Nicolas Sebrecht:

> The way systemd services handle network whatever "network manager" you
> enable is the last thing preventing me from using systemd on servers.
> Seting up manual advanced setups on systemd looks crappy (if even
> possible with the provided tools) compared to OpenRC.

Yes.

My current itch to scratch: set up a bonding of 2 physical NICs with
systemd on gentoo. I didn't google for very long but didn't find much
aside from arch linux howtos using netctl etc (which I don't know and
therefore trust so much)

And the network.service-files I copied and modified back then (the
archives of this very ml show some of them) feel really somehow weak in
a way.

Aside from that I feel quite good with using systemd on all of my local
gentoo systems right now (and 2 productive servers at customers .. a 3rd
to come).

Back then I gave it a try to simply learn by doing:

... Is it complex, is it hard to learn or use, how does it work, do I
understand it, do I like the concepts ... just experience it by myself
and know my way if I have to use it somewhere. I still don't judge it as
good or bad. It's a choice right now.

Ah, yes, and suggestions welcome for that bonded interface ;-)

Stefan