Open protist opened 2 months ago
The systemd file provided with DavMail is designed for headless mode so incompatible with O365Interactive.
In your case you want to start the application on session start, correct?
There is an open pull request related to systemd that may or may not help: https://github.com/mguessan/davmail/pull/247
Alternative is to use autostart to have DavMail started by the desktop environment.
Thanks @mguessan
In your case you want to start the application on session start, correct?
Yes, that's correct.
The systemd file provided with DavMail is designed for headless mode so incompatible with O365Interactive.
It actually works fine for me! Once I start
or restart
it manually, I get the icon in the tray, and it does the whole O365Interactive thing fine.
There is an open pull request related to systemd that may or may not help: #247
Thanks. I'm not entirely sure if it's the service
file that's the problem though? Is it more that the application itself doesn't abort on failure? I think the service
file is agnostic to the internals of the application. It's just waiting for it to abort and give it the error code.
Presumably this is by design. As above, the application is trying (but failing) to reconnect. I just think that it's being too clever, and for "proper" systemd integration it should just abort on failure instead.
Alternative is to use autostart to have DavMail started by the desktop environment.
Yes, that's possible. However, assuming the systemd job fails on ... uh... failure, the advantage is that systemd can auto-restart it. Presumably starting it once by the DE wouldn't allow for that.
I'm using the Arch Linux systemd service to launch DavMail. This generally works fine. However, DavMail often fails, usually when booting the computer. When it is failing, there is no tray icon (I have
davmail.server=false
). Presumably DavMail fails because the panel/tray/bus isn't available yet.While it's failing, I get the following loop in
journalctl
, repeated 4 times every 5 minutes.DavMail does try and reconnect, but none of these attempt work. From the message, presumably this is because it can't connect to the GUI session. The only way to get it working again is by manually restarting the systemd service.
Presumably in order to attempt reconnections, the DavMail process does not abort, and thus the systemd service itself reports as active.
There seem to be two issues here. Firstly, DavMail seems to be retrying the wrong thing. Instead of retrying to connect, it should (also) try and connect to the GUI session again. However, given that DavMail cannot reconnect by itself, is there a way to get it abort on failure immediately instead? Then systemd can restart the service. Either way, does it seem "neater" for systemd to take care of reattempts anyway?