public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Systemd migration: opinion and questions
Date: Tue, 24 Feb 2015 16:44:59 -0500	[thread overview]
Message-ID: <CAGfcS_k_Lua_eW+x2yWmh5+6A2JXQC-xwCqv0_5DU8cJrzj9Xw@mail.gmail.com> (raw)
In-Reply-To: <20150224211545.50495cc0@marcec.fritz.box>

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.

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

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

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

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

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.

-- 
Rich


  parent reply	other threads:[~2015-02-24 21:45 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 20:15 [gentoo-amd64] Systemd migration: opinion and questions Marc Joliet
2015-02-24 20:41 ` Randy Barlow
2015-02-24 23:11   ` Marc Joliet
2015-02-25 22:42     ` Marc Joliet
2015-02-27 22:29       ` Marc Joliet
2015-02-24 21:44 ` Rich Freeman [this message]
2015-02-25  7:50   ` Marc Joliet
2015-02-25 12:01     ` Rich Freeman
2015-02-25 18:25       ` Marc Joliet
2015-03-01 12:48         ` Marc Joliet
2015-03-01 13:34           ` Rich Freeman
2015-03-01 18:20             ` Marc Joliet
2015-03-01 19:13               ` Rich Freeman
2015-03-02  5:13                 ` [gentoo-amd64] " Duncan
2015-03-14 14:01                   ` Marc Joliet
2015-03-14 12:57                 ` [gentoo-amd64] " Marc Joliet
2015-03-14 13:02               ` Marc Joliet
2015-02-25 10:13   ` [gentoo-amd64] " Duncan
2015-02-25 12:13     ` Rich Freeman
2015-02-26  0:35       ` Duncan
2015-02-25 18:56     ` Marc Joliet
2015-02-26  1:55       ` Duncan
2015-02-24 21:51 ` [gentoo-amd64] " Frank Peters
2015-02-25 14:31   ` Michael Mattes
2015-02-25 20:28   ` Marc Joliet
2015-02-25 10:15 ` [gentoo-amd64] " Duncan
2015-02-25 10:33 ` Duncan
2015-02-25 19:17   ` Marc Joliet
2015-02-25 19:31     ` Rich Freeman
2015-02-25 19:54       ` Marc Joliet
2015-02-25 22:30 ` [gentoo-amd64] " Marc Joliet
2015-05-20  8:01 ` Marc Joliet
2015-05-20 10:44   ` [gentoo-amd64] " Duncan
2015-05-20 11:22     ` Rich Freeman
2015-05-21  9:36       ` Duncan
2015-05-21 11:33         ` Marc Joliet
2015-05-23  8:49         ` Marc Joliet
2015-05-23  9:32           ` Marc Joliet
2015-05-23 10:41           ` Duncan
2015-05-23 11:11             ` Marc Joliet
2015-05-23 11:37               ` Rich Freeman
2015-05-23 12:02                 ` Duncan
2015-05-23 18:07               ` Marc Joliet
2015-05-23  8:17       ` Duncan
2015-05-23 12:14         ` Duncan
2015-05-21 11:29     ` Marc Joliet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfcS_k_Lua_eW+x2yWmh5+6A2JXQC-xwCqv0_5DU8cJrzj9Xw@mail.gmail.com \
    --to=rich0@gentoo.org \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox