Re: [gentoo-amd64] Systemd migration: opinion and questions

[Marc Joliet <marcec@gmx.de>]

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

Am Tue, 24 Feb 2015 16:44:59 -0500
schrieb Rich Freeman <rich0@gentoo.org>:

> Lots of stuff here.  I'm only replying where I think I can add value.
> 
> On Tue, Feb 24, 2015 at 3:15 PM, Marc Joliet <marcec@gmx.de> wrote:
> >
> > == Things I have *not* gotten rid of (yet) ==
> >
> > Fcron is still around, mainly because packages might rely on it being there
> > (e.g., man-db and mlocate install files there), but also because I haven't
> > researched systemd timers yet.
> 
> My fault.  :)  I have sys-process/systemd-cron in my rich0 overlay but
> I've been too lazy to get it into the main tree (I need to check to
> see what units if any I had to tweak from what gets installed and
> merge those back into the package).  This is a set of timer/service
> units that will run all the /etc/cron.*/ jobs.  They'll run in series
> and not in parallel as they would if you turned them into individual
> timer scripts, but it is a great way to just integrate the scripts
> packages already are providing.  It also has a crontab generator, but
> I don't think it works with fcrontab so I have not tested this.
> Generators are just one of those little things I love about systemd.

That sounds great!  I'll be looking forward to this :) .

(Although, sadly, it does appear as if ebuilds getting stuck in overlays happens
much too often these days.)

> >
> > I plan on uninstalling syslog-ng, but haven't done so yet.  I simply feel
> > better waiting a bit, even though I don't run it anymore.  Man, I feel silly
> > after typing that...
> 
> Yeah, took me a while to uninstall it, but I don't find much value in
> running both.

Precisely.  It's more a "but what if...!" kind of worry.

> >
> > == Network migration on my desktop ==
> >
> > My desktop has a somewhat more complicated network setup than the laptop (which
> > uses NetworkManager).  The wan0 network device is no problem, but I also have a
> > bridge with one physical device connected to it, and one dummy device.  ...
> > I originally ignored systemd-networkd because I keep
> > hearing that it's only for simple networks, but after looking at the man page
> > it appears that it can do (almost) everything that I needed it to, although I'm
> > not sure about dummy device support.
> 
> Here is what I'm doing for a bridge - I can't vouch for dummy devices
> but I wouldn't be surprised if it works (remember, these are the guys
> doing udev too):
> cd /etc/systemd/network/
> 
> cat brkvm.netdev
> [NetDev]
> Name=brkvm
> Kind=bridge
> 
> 
> cat brkvm.network
> [Match]
> Name=brkvm
> 
> [Network]
> DNS=192.168.0.5
> Address=192.168.0.5/24
> Gateway=192.168.0.21
> 
> 
> cat eth-bridge.network
> [Match]
> Name=e*
> 
> [Network]
> Bridge=brkvm
> 
> 
> If you're using persistent names you might need to tweak the Name in
> the last one slightly so that it matches whatever you're using.

That looks nice, I like that the bridge device is distinct from the bridge
network, is distinct from other devices attached to it.  This might help in
getting unit dependencies right. I'll try it out this weekend.

My primary concern with networkd would be that it is very new, and thus not as
well tested as other solutions.  While netctl is also fairly new, and
I'm using that with no problems, it uses well-known DHCP clients, while it
appears that networkd implements its own.

But I'll give it a whirl anyway ;) .

> > === Timers ===
> >
> > Can a systemd timer depend on a mount point such that it waits until the mount
> > point exists before running?  Or will it fail after a timeout?  I want to
> > research this myself, but haven't gotten around to it yet.
> 
> So, timer units are units, and units can have dependencies, and mounts
> can be dependencies since mounts are units.  However, if you set the
> dependency on the timer itself, then the timer won't start running
> until the mount exists.  You probably want the depencency to be on the
> service started by the timer (so the timer is watching the clock, but
> the service won't start without the mount).

Wait, so the timer won't start watching the clock until its dependencies are
met (i.e, the mount point appears)?  Is that what you mean?  Because that might
be more in line with what I want (though I'm not sure yet).

> If you set a
> Requires=foo.mount and After=foo.mount, then the service shouldn't run
> unless foo.mount is available.  I suspect systemd will attempt to
> mount the filesystem when it runs the service, and you'll get units in
> the failed state if that doesn't work.
>
> However, I haven't tested any of this.  I suspect it wouldn't take
> much to work this out.  I have a mount dependency in one of my
> services.  Just look at the mount units in /run/systemd/generator for
> the name of the mount unit systemd is creating from fstab.

Right, so IIUC, I would have a oneshot service that does the backup, and the timer
runs that, and of course the timer can depend on the mount point.  And if the
mount point doesn't exist, then the service started by the timer will fail.

What I would prefer to have is a timer that only runs if *both* the time *and*
mount conditions are met.  Skimming the man page, this does not seem possible.
I suppose it would be nice if timers learned "conditions" on which they should
wait in addition to the time condition, but maybe that's outside the scope of
systemd?

But my confidence that at the very least something better than what I have now
will be possible, I'll just have to take the time and read the man pages
properly.

> > === Depending on a specific network interface ===
> >
> > Some socket units failed to start at first, due to "resource" errors.  So I
> > made them depend on netctl@bridge via *.d/requires.conf files like so:
> >
> >     [Unit]
> >     Requires=netctl@bridge.service
> >     After=netctl@bridge.service
> >
> > That fixed the errors, but is it the correct way to depend on that interface
> > (ignoring the fact that I could have put symlinks at the right place instead)?
> 
> Following my networkd scripts above, I suspect that something like
> this /might/ work but I haven't tested it:
> Requires=sys-subsystem-net-devices-brkvm.device
> After=sys-subsystem-net-devices-brkvm.device
> 
> Again, another example of the udev integration - you get device units
> for devices.  That also lets you do things like start a service when a
> device is activated, have dependencies, etc.  You should look at the
> list of units sometime - you can also do things like run a service
> when a file is modified (no need to have a helper program watching it
> with fnotify, etc).

Right, I really do like that about systemd, too.  It's much more thorough than
other systems (in several ways).  The mount point units generated from fstab
are one example, but I also noticed that each script in /etc/local.d/ gets the
same treatment and is exposed as its own unit.

The more I use systemd, the more I realise why it made sense to merge the udev
project into systemd: they both play off each others capabilities quite
nicely (udev giving systemd extra information and events to act upon, and
systemd reacting to udev's events and doing the appropriate thing).

Diving into systemd on a whim really was the best way to see what all the fuss
was about, and so far it was worth it.

> Also, I think Requires basically implies Wants as well, so if that
> network device doesn't exist and the service tries to start, systemd
> might try to create that device, if possible.
> 
> Now, the device existing does not necessarily mean that it has an IP,
> working DNS, etc.  I don't know if there is any way to have a
> dependency on a specific configured network.  That might be a great
> question to ask the systemd devs.

Sure, if nobody here gives an authoritative answer, I'll ask there.  People:
you have until the weekend ;) .

Thanks to everyone for the responses so far!
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]