Option for DavMail to abort on failure

[protist]

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.

Jun 24 10:39:50 hostname davmail[951]: 2024-06-24 10:39:50,448 ERROR [CaldavConnection-38404] davmail  - DavMail configuration exception:
Jun 24 10:39:50 hostname davmail[951]: O365Interactive not supported in headless mode
Jun 24 10:39:50 hostname davmail[951]: davmail.exception.DavMailException: DavMail configuration exception:
Jun 24 10:39:50 hostname davmail[951]: O365Interactive not supported in headless mode
Jun 24 10:39:50 hostname davmail[951]:         at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:168)
Jun 24 10:39:50 hostname davmail[951]:         at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:93)
Jun 24 10:39:50 hostname davmail[951]:         at davmail.caldav.CaldavConnection.run(CaldavConnection.java:178)

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.

$ systemctl --user status [email protected]
● [email protected] - DavMail for foober
     Loaded: loaded (/usr/lib/systemd/user/[email protected]; enabled; preset: enabled)
     Active: active (running) since Sun 2024-06-23 21:43:39 AEST; 13h ago
 Invocation: bd5fa86d76fd4c3ebc387033185fb3d2
   Main PID: 951 (java)
      Tasks: 30 (limit: 77036)
     Memory: 131.7M (peak: 149.6M)
        CPU: 3.247s
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/app-davmail.slice/[email protected]
             └─951 java -Xmx512M -Dsun.net.inetaddr.ttl=60 -Djdk.gtk.version=2.2 -cp "/usr/share/davmail/davmail.jar:/usr/share/java/swt.jar:/usr/share/java/javafx-base.jar:/usr/share/java/javafx-controls.jar:/usr/share/java/javafx-fxml.jar:/usr/share/java/javafx-graphics.jar:/usr>

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?

[mguessan]

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:
#247

Alternative is to use autostart to have DavMail started by the desktop environment.

[protist]

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.