Timeline for Prevent systemd from unmounting a partition mounted by a systemd service
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 25, 2023 at 19:00 | vote | accept | Adel M. | ||
| Sep 24, 2023 at 8:55 | comment | added | Makaveli84 | @ChrisBillington I can confirm that in a case that is tangentially similar to the OP's, KillMode=process works perfectly. Thanks for being persistent and figuring this out! | |
| S Jan 13, 2023 at 9:07 | history | bounty ended | CommunityBot | ||
| S Jan 13, 2023 at 9:07 | history | notice removed | CommunityBot | ||
| Jan 9, 2023 at 12:06 | comment | added | Chris Billington | @LL3, looks like I need to set KillMode=mixed and OP needs to set KillMode=process (or better: follow @tukan's answer). I can't test yet as I don't have access to the relevant system, but given my understanding now, I'm confident that's it. | |
| Jan 9, 2023 at 11:25 | comment | added | Chris Billington | @LL3, amazing, that makes much more sense. That should point me in the right direction. In my case I do want the disk unmounted upon SIGTERM, but not until after the script does some cleanup, so I'll look into what options I have to delay or prevent systemd killing the subprocess so I can do it explicitly after cleanup. Thanks so much for clarifying what's happening! | |
| Jan 8, 2023 at 10:42 | comment | added | LL3 | @ChrisBillington Yes, it likely does mean that. Your script runs mount, which in turn spawns a fusermount process as per FUSE normal behavior. That process lives until an explicit unmount or until it gets killed some way. By default such process belongs to the same control-group assigned to your script by systemd. You can double-check that using systemd-cgls. Default systemd behavior for stopping a simple service such as the one in OP is to kill the entire control-group, see systemd.kill(5). There are ways for you to fix your use case, depending on your overall setup. | |
| Jan 7, 2023 at 21:52 | comment | added | Chris Billington | @tukan, these are USB hard drives, if that makes a difference. Thanks for the info about timers. It makes sense, it's just a little overcomplicated compared to the script itself doing the mounting and unmounting. The partitions should be unmounted other than when the backup is running, so I don't want them to be automounted generally. | |
| Jan 7, 2023 at 21:51 | comment | added | Chris Billington | @LL3 Yes, I am mounting an NTFS filesystem. Does that mean my backup script is spawning a subprocess for the mount or something, and systemd is sending that process SIGTERM at the same time as it does the main process? I do see output from ntfs-3g in the journal for my service upon the mount and unmount commands, which confuses me unless it's a subprocess. | |
| Jan 6, 2023 at 14:19 | comment | added | LL3 | @ChrisBillington are you possibly mounting filesystem types that are implemented in userspace like FUSE does? e.g. ntfs-3g, sshfs, and many others? | |
| Jan 6, 2023 at 11:00 | comment | added | tukan | @ChrisBillington if you have such workflow then you can follow the logic I have provided in my answer nad have a .mount unit for everyday, which would point to a mount point of your choosing. Then you could use systemd timers to mount them. As for the mount, it depends what is actually done within the mount (is it a usb drive, networkdrive, etc). The systemd is wrong facility for automounting if you plugin drives that should be done via udev rules. | |
| Jan 6, 2023 at 10:23 | comment | added | Chris Billington | @tukan, my workflow is that I'm doing backups to a different disk for each weekday, and it's easier to do the logic of which disk to mount from within Python code than to try to figure out how to describe this in terms of systemd units. And it's just unexpected - if I didn't ask systemd itself to do the mounting, I didn't expect it to unmount unconditionally. I'm yet to find even a description of this as intended behaviour. | |
| Jan 5, 2023 at 10:56 | answer | added | tukan | timeline score: 1 | |
| Jan 5, 2023 at 10:00 | comment | added | tukan | @MC68020 I don't think this applies - this is an opposite situation mount via bash and it gets automatically unmounted when the script ends. In general mounting a volume via systemd & bash script is weird. I can't imagine a workflow where this is needed. | |
| Jan 5, 2023 at 9:47 | comment | added | MC68020 | @ChrisBillington : Could this answer from Poettering himself help you to understand better what happens and how to workaround this issue ? : github.com/systemd/systemd/issues/5669#issuecomment-290363903 | |
| Jan 5, 2023 at 9:31 | comment | added | tukan | What do you run in the vmount.sh? | |
| S Jan 5, 2023 at 7:49 | history | bounty started | Chris Billington | ||
| S Jan 5, 2023 at 7:49 | history | notice added | Chris Billington | Draw attention | |
| Jan 5, 2023 at 7:43 | comment | added | Chris Billington | I am seeing this problem too, with a backup script running on a systemd timer. In my case I want the disk unmounted once the script stops, but if I call systemctl stop, the disk is unmounted before my backup script can handle the SIGTERM and do its own cleanup. So that is undesirable. Very interested if you ever solved it! | |
| May 18, 2021 at 18:38 | history | asked | Adel M. | CC BY-SA 4.0 |