[systemd-devel] mount-on-demand for backups; hooks for indicating success/failure

Jonathan Dowland jon+systemd-devel at alcopop.org
Thu Mar 9 15:53:43 UTC 2017


I have some backup services which depend on mounts. I want those
filesystems unmounted when the backup jobs are not running. This is
easily achieved with StopWhenUnneeded.

I also want to trigger the backup jobs to start when I attach my
external HDD. This is reasonably simple by adding WantedBy=<device>
to the backup service (*not* the mount unit, or it will never be

So far so good!

However, this is a headless box and I want to blink an LED when certain
jobs are running, finish or fail. So I need to execute commands in
certain situations. Job failure is easy, I can use OnFailure= and set up
a oneshot service. Job started isn't too bad, I add a ExecStart=-
to my backup service before the real one.

Signalling "device is safe to remove" I have not figured out.
Using a chain of blah.device -> blah.mount -> backup-blah.service units,
"safe to remove" LED should only happen after the mount has completed
unmounting, successfully. Is there an existing "hook" or place that I
could put that in this situation?

My temporary solution is to remove the mount unit entirely, define the
mount point in /etc/fstab and use ExecStart and ExecStop in the backup
service to mount and umount before and after the job runs:

    ExecStart=/bin/mount /media/ipod
    # vvv this is a "backup in progress" colour vvv
    ExecStart=/usr/local/bin/blinkstick --index 1 --limit 10 --set-color 33c280
    ExecStart=/usr/bin/rsync ... # the backup job
    ExecStop=/bin/umount /media/ipod
    ExecStop=/usr/local/bin/blinkstick --index 1 --limit 10 --set-color green

This works for this simple use-case, but is not very elegant, and I
don't think I can scale this up to my next task: do the same but for an
*encrypted* filesystem. So here I have to have <device> ->
systemd-crpytsetup@<blah>.service -> <blah>.mount (or not?) ->

Any advice appreciated. Thanks!

Jonathan Dowland

More information about the systemd-devel mailing list