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.

[protist]

I've been bitten by this a lot recently, so I've designed a workaround. This script will monitor journalctl for four consecutive errors, then restart the systemd job. It works well for me, and davmail now correctly launches on boot.

Create the script somewhere logical, e.g. ~/.local/bin/check_davmail_failing

#!/usr/bin/bash
# This script will monitor journalctl --user $service for $regex, then restart the service after $limit matches
# Related https://github.com/mguessan/davmail/issues/360
# Davmail tries to reconnect 4 times every 5 minutes, so unfortunately we are constrained to monitor the log for failure every 5 minutes.
# Alternatively we could compare the timestamps from journalctl

regex='davmail.exception.DavMailException: DavMail configuration exception'
service='davmail@<YOUR_INSTANCE>.service'
limit=4

# output singular or plural
function num_match_or_matches () {
  printf '%s %s' ${1} match
  if [ $1 -ne 1 ]; then
    printf '%s' es
  fi
}

while true; do
  printf '%s\n' "Monitoring $service"
  count=0
  journalctl --user -u "$service" -f -n 0 |
  while IFS= read -r line; do
    if [[ "$line" =~ $regex ]]; then
      ((count++)) # increment count
      printf '%s %s\n' "$(num_match_or_matches $count)" 'for expression' # log the current count
      if [ $count -ge $limit ]; then
        printf '%s\n' "Attempting to restart $service"
        systemctl --user restart "$service"
        break
      fi
    fi
  done
  printf '%s\n' 'Pausing for 30 seconds'
  sleep 30 # give davmail a bit of time before trying again
done

Create the systemd service, e.g. at ~/.config/systemd/user/check_davmail_failing.service

[Unit]
Description=Restart davmail if it fails

[Service]
Type=simple
ExecStart=/<PATH_ABOVE>/check_davmail_failing

[Install]
WantedBy=default.target

Then start and enable the service with systemctl --user enable --now check_davmail_failing.service, and it should work fine!