tobias/docker-offlineimap
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ff0b84ff2b
docker-offlineimap/contrib/systemd/offlineimap.service

12 lines
191 B
SYSTEMD
Raw Normal View History

contrib: add systemd configuration files Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-22 12:58:56 +01:00
[Unit]
Description=Offlineimap Service
systemd: add documentation entry in configuration files Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2017-06-01 11:12:26 +02:00
Documentation=man:offlineimap(1)
contrib: add systemd configuration files Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-22 12:58:56 +01:00
[Service]
Use basic logger (since systemd picks up stdout) No need to overcomplicate things; systemd grabs all stdout output and logs that. Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2017-06-01 18:10:40 +02:00
ExecStart=/usr/bin/offlineimap -u basic
systemd: remove unused watchdog functionality Add restart on failure and increase timeout to kill service. Signed-off-by: benutzer193 <registerbn@gmail.com> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2017-06-01 15:29:12 +02:00
Restart=on-failure
RestartSec=60
contrib: add systemd configuration files Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-22 12:58:56 +01:00
[Install]
Use a pre-existing target for systemd services Providing mail.target is really confusing and poor UX: * When a user enables a unit, it's not truly enabled until they ALSO enable mail.target. This is very counter-intuitive. * `mail.target` provides no extra value in itself, nor is it anything "standard". * Any user wanting this specific target can still continue using it just dropping in a `mail.target` file. Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2017-06-01 18:14:10 +02:00
WantedBy=default.target
Reference in New Issue Copy Permalink