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

2017-04-05 Thread Jonathan Dowland
On Fri, Mar 31, 2017 at 12:01:11PM +0200, Lennart Poettering wrote:
> On recent systemd versions you can plug in a script in ExecStop= of
> your backup service, and check the $SERVICE_RESULT env var which tells
> you the success state of the service, which you can then use to set
> any LEDs you like.

This looks very useful, thanks - but the issue here is that I don't
think systemd provides a guarantee that if my backup service Requires
a mount unit, and that mount unit is marked StopWhenUnneeded=true, that
the this script will fire after the unmount has finished (and
succeeded).

I think Michal's solution of having a separate service for the LEDs
might work, perhaps with After=media-ipod.mount, but I need to
experiment some more.

-- 
Jonathan Dowland
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2017-03-09 Thread Jonathan Dowland
Hey,

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=
to the backup service (*not* the mount unit, or it will never be
auto-unmounted).

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:

[Unit]
OnFailure=blinkstick-fail.service
[Service]
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  ->
systemd-crpytsetup@.service -> .mount (or not?) ->
backup-black.service.


Any advice appreciated. Thanks!


-- 
Jonathan Dowland
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-29 Thread Jonathan Dowland
On Mon, Sep 26, 2016 at 12:31:10PM +0200, Reindl Harald wrote:
> because earlier systems (sysvinit) hat no concept like emergency mode as
> they where a lousy bunch of scripts where you ended in case of a crucial
> disk failing in a undefined state?
> 
> because earlier systems had no concept for "nofail" or "fail" at all

At least on Debian, nofail was honoured and did have an effect, prior to
adopting systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] possible bugs w/ defining .mount services

2016-01-25 Thread Jonathan Dowland
Hi,

Am I wrong to believe that with one can interchangeably refer to .mount
units via their paths?  It seems to work inconsistently. (this all with
version 215).

In a service, if I specify

BindsTo=backup.mount

Where backup.mount is a systemd unit, the service is correctly stopped
when the path is unmounted. If I use

BindsTo=/backup

It does not. (Not with 'systemctl stop /backup').

Similarly, if I use the backup.mount form for Before=, things work as
they should, but Before=/backup results in

Failed to add dependency on /backup, ignoring: Invalid argument


Many thanks,

-- 
Jonathan Dowland
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] the correct way to define crypt partitions, going forward

2016-01-22 Thread Jonathan Dowland
Hi, [please CC me on replies if possible],

I have several LUKS-encrypted volumes, upon which I have placed LVM PVs.
Prior to systemd, I would define them in /etc/crypttab. Right now, due
to systemd-cryptsetup-generator, this gets interpreted and translated
into systemd units.

I am wondering whether crypttab should be considered deprecated and
whether it would be better practice for new volumes to be defined soley
as systemd units. Is the plan for the crypttab-generator to go away
eventually?

To activate my filesystems, the steps are

1. cryptsetup luksOpen 
2. vgchange -a y 
3. mount 

I know to create a systemd-cryptsetup@XYZ.service unit and a
somepath.mount.unit to cover 1. and 3. above. But should I define a
service for 2., or handle it with ExecStartPost= in the cryptsetup
service definition?

I'm leaning towards the former, because one also needs to handle
vgchange -a n prior to luksClose, but I'd appreciate your opinions (it
might just be a matter of style).

Finally, does anyone have a good solution for multiplexing the
decrypting of dm-crypt partitions that happen to have the same
passphrases? In normal operation I have 2 such devices that I do not
want to mount at boot-time (as that is headless/unattended), but I do
want to mount (manually) in normal operation. It would be convenient to
only type my passphrase once. Is this something the passphrase-asking
logic in systemd can or could support? Should I be looking at key files
instead?

[ on the other hand, I have yet to look at a possible boot-time
decryption solution involving dropbear ssh for headless passphrase entry
at initramfs time, which might solve this nicely if it works. ]


Thanks,

-- 
Jonathan Dowland
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel