used to mount s3ql :-* *mount.s3ql --fg --systemd --authfile /root/.s3ql/authinfo2 --keep-cache --cachesize 15625000 --max-cache-entries 65536 --threads 6 --allow-other

20.04 uses systemd for startup scripts. > Normally mounting can be done via /etc/fstab or > https://www.freedesktop.org/software/systemd/man/systemd.mount.html but

> killing mount.s3ql to free up memory? Kernel log is silent. It's definitely not an OOM (an OOM would have SIGKILLed s3ql anyway). > The TERM signal does not make sense to

.name systemd[1]: Starting s3ql-mnt-b2-files.service... Aug 16 08:07:18 stratofortress.nexus.i.intelfx.name mount.s3ql[40268]: Using cached metadata. Aug 16 08:07:18

the Python systemd bindings so that the "--systemd" mount option works. Have a look at http://deb.saasweb.net/s3ql/pool/main/s/s3ql/s3ql_3.4.0-2~xenial.debian

the latest mount log crash record:* 2019-03-12 13:47:59.546 1417:Thread-12 root.excepthook: Uncaught top-level exception: Traceback (most recent call last): File "/usr

--systemd` option to simplify running mount.s3ql as a systemd unit. * Dropped the `--upstart` option - upstart seems to be unused and unmaintained. * Dropped support for legacy ("

the official systemd Python module, not the (third-party) module on PyPi. * Fixed occasional crashes with a "dugong.StateError" exception. Thanks to Roger Gammans for

a > systemd unit if it would be needed to minimize human interaction. > > Is this a simple and reliable way to test from a shell script before I > mount whether or not an fsck

Description=Mount s3ql file system Requires=nss-lookup.target network.target time-sync.target After=nss-lookup.target network.target network-online.target remote

it will mount again. > It appears the file system isn't unmounting cleanly on shutdown. > My remote filesystems take up to 10 minutes to unmount cleanly. My solution is also

python-systemd Yes. That is a terrible idea, and I would not run any software written by someone who does not recognize this. > So at this point it appears my choices are to modify your

> > > That's not good. But are you sure you pasted the complete output? It > looks as if the 'previous errors' are not actually

need to mount a cifs file system BEFOREI can mount an s3ql FS because the s3ql fs lives on the cifs fs If I run s3ql mount AFTER booting , it works but during boot it complains .. cat /var/log

upstart/systemd) and if a reboot without umount can corrupt the filesystem to the point it's unmountable, and it's unfsckable -- that's an issue. The log in the original

]# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size

code by mount.s3ql, fsck.s3ql, mkfs.s3ql, s3qladm and s3ql_verify. Both encrypted and unencrypted file systems were vulnerable. * s3ql_verify no longer crashes when checking