Some more information: Mounting the volume via mount.s3ql works with either version of mount.py (with or without the import of sd_notify from systemd.daemon).
>From a python3 session I can also run "from systemd.daemon import notify as sd_notify" and then autocompletion shows a wide list of options for calls to sd_notify. You mentioned believing I might be running some rebel version of systemd. Again, this is pretty stripped down install of CentOS_7 with: [root@fast-dr-proxy ~]# rpm -qa | grep systemd systemd-devel-219-19.el7_2.13.x86_64 systemd-sysv-219-19.el7_2.13.x86_64 systemd-python-219-19.el7_2.13.x86_64 systemd-libs-219-19.el7_2.13.x86_64 systemd-219-19.el7_2.13.x86_64 Is one of these wrong? If I change the unit file to "Type=notify" with either version of mount.py (sd_notify imported or sd_notify = None), the service no longer starts via systemctl Right now I'm back to the stock mount.py and no Type argument in the unit file (which defaults me to simple). Back to where mounts and startups work but not shutdowns. But without any sd_notify call in umount.py, I believe this means that systemd is never hearing whether the umount completes? Can it? I see a call to sd_notify that passes "STOPPING=1" but that seems to only tell systemd that the shutdown has begun? -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
