documentation : systemd/notify should use mount.s3ql with --fg

Issue #292 on hold
Martin Hamant
created an issue

In the automount section in the documentation there is no mention that the option --fg should be used otherwise mount.s3ql would daemonize and wont notify systemd.

I'm using the following unit file (with success):

Description=S3QL mount

ExecStart=/usr/bin/mount.s3ql --debug --fg --authfile /path/to/s3ql.txt swiftks://xxx /media/container-test/
ExecStop=/usr/bin/umount.s3ql --debug /media/container-test/


Comments (11)

  1. Martin Hamant reporter

    Well, maybe it still notifies systemd when daemonized somehow but the above example doesn't work without --fg. Without --fg, the volume is mounted and immediately umounted.

  2. Martin Hamant reporter

    Of course, here it it. I just removed --fg from the unit file above. (My guess is Type=forking should be used in this case.)

    2018-03-19 08:20:57.982 901:MainThread s3ql.mount.determine_threads: Using 2 upload threads.
    2018-03-19 08:20:57.983 901:MainThread s3ql.mount.main: Autodetected 4058 file descriptors available for cache entries
    2018-03-19 08:20:59.613 901:MainThread s3ql.mount.get_metadata: Using cached metadata.
    2018-03-19 08:20:59.618 901:MainThread s3ql.mount.main: Setting cache size to 6543 MB
    2018-03-19 08:20:59.619 901:MainThread s3ql.mount.main: Mounting swiftks://xxx:yyy/ at /srv/bla...
    2018-03-19 08:20:59.636 908:MainThread s3ql.daemonize.detach_process_context: Daemonizing, new PID is 912
    2018-03-19 08:21:00.020 912:MainThread s3ql.mount.main: FUSE main loop terminated.
    2018-03-19 08:21:00.021 912:MainThread s3ql.mount.unmount: Unmounting file system...
    2018-03-19 08:21:00.364 912:MainThread s3ql.mount.main: File system unchanged, not uploading metadata.
    2018-03-19 08:21:00.469 912:MainThread s3ql.mount.main: Cleaning up local metadata...
    2018-03-19 08:21:00.472 912:MainThread s3ql.mount.main: All done.
  3. Nikolaus Rath repo owner

    No, type=notify should work just fine. Hmm. Is it possible that you don't have the systemd Python module installed? What happes if you run

    $ python3 -c "import systemd.daemon; systemd.daemon.notify('READY=1')"
  4. Michael Heyns

    hmmm, actually. That only appears to work once and stop fails. Following attempts at starting fail.

    Job for s3ql.service failed because the service did not take the steps required by its unit configuration.
    See "systemctl status s3ql.service" and "journalctl -xe" for details.
    -- Unit s3ql.service has begun starting up.
    Jul 08 04:09:53 drupple mount.s3ql[3314]: Using 4 upload threads.
    Jul 08 04:09:53 drupple mount.s3ql[3314]: Autodetected 4052 file descriptors available for cache entries
    Jul 08 04:09:53 drupple mount.s3ql[3314]: Using cached metadata.
    Jul 08 04:09:53 drupple mount.s3ql[3314]: Setting cache size to 60517 MB
    Jul 08 04:09:53 drupple mount.s3ql[3314]: Mounting s3c:// at /xxx...
    Jul 08 04:09:53 drupple systemd[1]: s3ql.service: Failed with result 'protocol'.
    Jul 08 04:09:53 drupple systemd[1]: Failed to start S3QL mount.
    -- Subject: Unit s3ql.service has failed
    [root@xxx ~]# ls /xxx/
    ls: cannot access '/xxx/': Transport endpoint is not connected
    [root@drupple ~]# umount.s3ql --debug /xxx
    2018-07-08 04:22:47.112 3759 ERROR    MainThread root.excepthook: File system appears to have crashed.

    Manually running the ExecStart and ExecStop commands work as expected (after unmounting with fusermount)

    Worked around by setting Type=simple and adding --fg

  5. Nikolaus Rath repo owner

    Could you post the logs from the failed "stop"? That'd be much more interesting. My guess is that the umount took too much time, so systemd just killed the process. There is an option to adjust that :-)

  6. Log in to comment