Ctrl-C does not cleanly unmount

[Salokyn]

Version: 2.32 (built from sources in a docker container)

FROM python:3-slim
RUN apt-get update -qq && apt-get install -y curl gnupg2 jq bzip2 build-essential pkg-config libfuse-dev libsqlite3-dev libfuse2 psmisc procps
RUN pip install --upgrade --no-cache-dir setuptools pycrypto defusedxml requests apsw llfuse dugong
RUN TAG=$(curl -s "https://api.github.com/repos/s3ql/s3ql/releases/latest"|jq -r .tag_name -) \
 && FILE=$(echo "$TAG"|sed s/release/s3ql/) \
 && curl -L "https://github.com/s3ql/s3ql/releases/download/$TAG/$FILE.tar.bz2" | tar -xj \
 && cd $FILE \
 && python3 setup.py build_ext --inplace \
 && python3 setup.py install

I mount a S3QL FS (I created an authfile2 file meanwhile)

mount.s3ql --fg swiftks://auth.cloud.ovh.net/GRA1:test-s3ql /s3ql
Using 2 upload threads.
Autodetected 1048538 file descriptors available for cache entries
Detected Swift features for storage.gra1.cloud.ovh.net:443: copy via COPY, Bulk delete 1000 keys at a time, maximum meta value length is 255 bytes
Using cached metadata.
Setting cache size to 7150 MB
Mounting swiftks://auth.cloud.ovh.net/GRA1:test-s3ql/ at /s3ql...

Then CTRL+C and...

Unmounting file system...
ERROR: Uncaught top-level exception:
Traceback (most recent call last):
  File "/usr/local/bin/mount.s3ql", line 11, in <module>
    load_entry_point('s3ql==2.32', 'console_scripts', 'mount.s3ql')()
  File "/usr/local/lib/python3.7/site-packages/s3ql-2.32-py3.7-linux-x86_64.egg/s3ql/mount.py", line 221, in main
    raise RuntimeError('Received signal %d, terminating' % (ret,))
RuntimeError: Received signal 2, terminating

It is OK to umount cleanly after mounting without --fg:

mount.s3ql swiftks://auth.cloud.ovh.net/GRA1:test-s3ql /s3ql
Using 2 upload threads.
Autodetected 1048538 file descriptors available for cache entries
Detected Swift features for storage.gra1.cloud.ovh.net:443: copy via COPY, Bulk delete 1000 keys at a time, maximum meta value length is 255 bytes
Using cached metadata.
Setting cache size to 7149 MB
Mounting swiftks://auth.cloud.ovh.net/GRA1:test-s3ql/ at /s3ql...

umount.s3ql /s3ql

It works with version 2.21 (debian stretch package)

mount.s3ql --fg swiftks://auth.cloud.ovh.net/GRA1:test-s3ql /s3ql
Using 2 upload threads.
Autodetected 1048538 file descriptors available for cache entries
Downloading and decompressing metadata...
Reading metadata...
..objects..
..blocks..
..inodes..
..inode_blocks..
..symlink_targets..
..names..
..contents..
..ext_attributes..
Setting cache size to 7340 MB
Mounting swiftks://auth.cloud.ovh.net/GRA1:test-s3ql/ at /s3ql...

CTRL+C

FUSE main loop terminated.
Unmounting file system...
Dumping metadata...
..objects..
..blocks..
..inodes..
..inode_blocks..
..symlink_targets..
..names..
..contents..
..ext_attributes..
Compressing and uploading metadata...
Wrote 262 bytes of compressed metadata.
Cycling metadata backups...
Backing up old metadata...
Cleaning up local metadata...
All done.

[Nikratio]

Thanks for the report! It is not clear to me that this is a bug rather than intended behavior. If Ctrl-C is indistinguishable from unmounting the file system (as it was in 2.31 and earlier), you could always just unmount the filesystem rather than pressing Ctrl-C. In 2.32 and newer, Ctrl-C results in the filesystem terminating as quickly as possible without data-loss (assuming that the local cache is kept).

Do you have a use case where you depend on Ctrl-C having the same semantics as unmounting?

[Salokyn]

Hi,
This is because I try to run s3ql in a docker container. So it must run in forground and must be unmounted cleanly when the container is stopped (when it is stopped, docker send a SIGTERM signal to the process running in the container).
When mount.s3ql --fg receives a SIGTERM or SIGHUP, it should cleanly unmount (whatever the time needed) and exit. This works fine in version 2.21 but crashes with v2.32.
Here is my project : https://gitlab.com/Salokyn/docker-s3ql

[Nikratio]

Thanks for the additional details! However, it is still not clear to me why you can't trigger a regular unmount before stopping the container, or as part of the container stopping procedure. Having a way to shutdown S3QL as quickly as possible without loosing data is a valuable feature, so I'm really not found of the idea of dropping this in favor of making SIGTERM/SIGHUP an alias for unmount.

[Nikratio]

I'm closing this bug report for now. Please feel free to re-open this if you can provide the requested information!