systemd: add stop to services

[ggzengel]

'service zfs-share stop' does nothing.
Task which didn't run as daemons need an ExecStop part if you want to revert it's function.

Same with zfs-mount and zfs.import*

[ggzengel]

I tried 'ExecStop=@sbindir@/zpool export -a' with zfs-import-cache.service and it works.
But it removes /etc/zfs/zpool.cache and after service start or rebooting it will scan for pools.

1. I don't like to copy zpool.cache and bring it back after exporting because it's not a smart solution.
2. There is no ExecStopPre which could copy before exporting.

What do you think about an extra option for zpool export which doesn't touch zpool.cache?

[SpComb]

We also had to modify zfs-mount.service for clean zfs shutdown on Debian jessie with systemd.

Note that the zfs-*.service units with DefaultDependencies=no need an explicit Conflicts=shutdown.target to be stopped at shutdown.

[FransUrbo]

I don't know it if matters that this won't work if/when you boot from a ZFS filesystem. The SYSV init script checks this before it tries to export the pool, but I don't know if this is possible in systemd files..

[GregorKopka]

ExecStop seems to be able to call anything, so instead of doing @sbindir@/zpool export -a we could call a script which checks for root pool.

[FransUrbo]

You mean /etc/init.d/zfs-import?? :D

[ggzengel]

This is part of #3827:

Whether you like it or not systemd is coming more and more. I would like to see that zfs tools will read config files at there own. Even if you want to implement permissions it's better zfs will check permission and not external scripts.

I don't like to remember which script will do this or that. I like to have all tools inside one executable.

And I would like to config which mounts/unmounts will be included/excluded with -a. Export at shutdown without deleting cache file. And a lot more ...

I like this blog: http://0pointer.de/blog/projects/on-etc-sysinit.html

What's the right way to discus such thing, because this should change thing which should go back to openzfs?

[FransUrbo]

Whether you like it or not systemd is coming more and more.

Yes unfortunately :(. It will, luckily, never ever replace SYSV completely everywhere (over my dead body on my own machines!). The simple reason is that it's crap! It's poorly designed, it's poorly implemented and it's poorly maintained.

However, some people are currently stuck with it, so we need to make the best of a lousy situation and support them to.

Both import and export can take an argument on what pool(s) to import/export (without using -a).

[behlendorf]

@ggzengel I think this is a discussion we absolutely need to have. And as you say systemd is coming (if not already here) so we need to integrate with it as cleanly as possible. I think the right place to have this discussion is on the issue tracker and we should attempt to involve people who are already familiar with all things systemd. I'll admit up front I'm not very familiar with but I know @Lalufu and others are and they definitely have some opinions about this. I'd suggest open a generic systemd issue and making a proposal for we need to fix/extend our existing support.

[ggzengel]

Because of the discussion I had with @FransUrbo in #3827 I would like to have a topic about config and startup at all. My biggest problem is that my english language is not so diplomatic and exact like my german language.
On the other side @FransUrbo and others are making a good job with these scripts and I don't want to discourage them.

[Lalufu]

For most of the services having a stop function is pretty trivial, but I agree that having a general startup/shutdown discussion (what gets started when, and why, and what things get stopped, when and why) might be useful. systemd is an implementation detail.