In case it helps anyone using CentOS 7, this works for me (after a lot of
struggling):
[Unit]
Description=mount s3ql filesystem
Wants=network-online.target
After=network-online.target
Before=nfs-server.service
Conflicts=shutdown.target
ConditionPathExistsGlob=/rdisks/s3.amazonaws.com/*-s3ql-*
[Service]
Type=notify
KillSignal=SIGINT
EnvironmentFile=/etc/sysconfig/network
ExecStartPre=/usr/local/bin/fsck.s3ql --log=/data/.s3ql/fsck.log
--authfile=/root/.aws/creds.s3ql --cachedir=/data/.s3ql/cache
s3://us-east-1/XXX-s3ql-${SHOSTNAME}
ExecStart=/usr/local/bin/mount.s3ql --systemd --fg --allow-other
--log=/var/log/s3ql-mount.log --authfile=/root/.aws/creds.s3ql
--cachedir=/data/.s3ql/cache s3://us-east-1/XXX-s3ql-${SHOSTNAME} /rdisks/s3
.amazonaws.com/XXX-s3ql-${SHOSTNAME}
TimeoutStopSec=300
[Install]
WantedBy=multi-user.target
Key differences from other examples that are 'out there':
ExecStartPre - This is good for fsck.s3sql as long as you don't use --force.
KillSignal - systemd seems to insist on sending signals to its managed
processes; this *must* be set to SIGINT, which is the *only* signal mount.s3ql
responds graciously to. systemd sends SIGKILL by default.
ExecStop - I removed this, since there's not point to it, except perhaps to
do a system umount of a stale s3ql mount point. The umount.s3ql step isn't
needed, since the SIGINT sent by systemd accomplishes the same thing.
TimeoutSpec - some Ubuntu examples set this to infinity which is not
supported by the CentOS version (including revisions) of systemd.
I hope that helps at least one s3ql user on CentOS 7.
Brian
On Friday, November 18, 2016 at 2:47:19 PM UTC-5 [email protected] wrote:
> OK, we're now almost purely into the world of OS questions (I do have one
> s3ql question) but this pertains to running s3ql so I'll keep going.
>
> I've changed the TimeOutStopSec=5min setting under [Service] to 1min. This
> setting appears not to enforce any timeout, instead it's just how long the
> call to unmount will wait before marking it failed or killing it.
>
> I've added ExecStopPost=/usr/bin/sleep 60 to the [Service] in the hopes
> that it would add a 1min pause to unmounting.
>
> So my unit file /lib/systemd/system/s3ql.service now looks like:
> [Unit]
> Description=mount s3ql filesystem
> Require=NetworkManager-wait-online.service
> Before=nfs-server.service
> After=NetworkManager-wait-online.service
>
>
> [Service]
> ExecStart=/usr/bin/mount.s3ql --fg --authfile /etc/s3ql.authinfo
> --allow-other
> swift://tin.fhcrc.org/fast_dr/ /fast_dr
> ExecStop=/usr/bin/umount.s3ql /fast_dr
> ExecStopPost=/usr/bin/sleep 60
> TimeoutStopSec=1min
>
>
> [Install]
> WantedBy=multi-user.target
> RequiredBy=nfs-server.service
>
> (note that I want to serve this volume via NFS and don't want nfs-server
> running unless this volume is available)
>
> ran "systemctl daemon-reload" to load changes
>
> Still no love. If I fsck the volume, I can run "systemctl start
> s3ql.service" and the volume mounts. If I "systemctl restart," the volume
> unmounts clean, waits a minute and mounts again. "systemctl stop" also
> unmounts gracefully including a 60 second pause.
>
> But (tailing syslog shows this) if I reboot, the system is down within a
> second. What am I missing? You've mentioned systemd-notify here, I believe
> without any mention in the unit file the default for the service is
> "simple," should I be checking on the OS that something is running for that
> work?
>
> s3ql question, finally: a clean unmount shows the metadata being backed up
> and the backup rotated. Is that the complete DB? How large? Where's it
> kept? If the file system is large (say millions of inodes or more) how much
> time/space will that take?
>
> Reading up on systemd and notify....
>
>
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/ffa25aec-9a0e-4a14-9fcb-0142f1420901n%40googlegroups.com.
