systemd unit repeatingly restarting

[almereyda]

As found in https://github.com/AppImage/AppImageKit/issues/1120#issuecomment-910716287, the systemd user unit, which is automatically installed and activated when running go-appimage for the first time, is very aggressively restarting, which can lead to a restart every few seconds.

A unit trying to restart 2.000x times without success may deactivate itself for the better.

This fills the system log and eventually the DEs notification drawer, and could eventually be stopped after a few attempts.

The same as for the original finding, this also accounts for other Notifications:

$ journalctl --user -b 0 -u appimaged.service | grep -A 2 'Notification:' | cut -d" " -f8- | sort | uniq -c
    149 --
    150 Notification:
    150 Other AppImage integration daemon detected
    150 Please uninstall appimagelauncher first, then try again

[probonopd]

Is this a duplicate of https://github.com/probonopd/go-appimage/issues/126?

[almereyda]

I don't think so. The restarts also occur when FUSE is present in an up-to-date version, as indicated in the linked comment.

Also #126 does not address the scheduling behaviour of the systemd user unit in case of errors.

Therefore I consider this a legitimate concern, if not issue, with the way how appimaged interacts with the system:

The system and notification drawer will become very unresponsive with a lot of new Notifications arriving every few seconds, here on Ubuntu 21.04 with GNOME 3.38.

[probonopd]

The issue is

    150 Other AppImage integration daemon detected
    150 Please uninstall appimagelauncher first, then try again

You need to uninstall appimagelauncher completely before you can use appimaged from go-appimage. The two cannot be on the system at the same time.

[almereyda]

The same restart behaviour happens when fuse3 is present. https://github.com/AppImage/AppImageKit/issues/1120#issuecomment-910716287; eventually this issue needs a copy in this repository.

It is very irritating to have the systemd unit report its error messages this frequently, which also causes the system to slow down.

I feel a more graceful fallback can help here to also reduce verbosity of appimaged a little. The people reading and processing the notifications also need time to react to it, no need to remind them every 5 seconds of the same fact.

[probonopd]

Indeed. AppImages need fuse2, not fuse3. https://github.com/AppImage/AppImageKit/issues/1120

[almereyda]

Yes.

My question here is, if it would seem feasible for go-appimage/appimaged to constrain itself, after finding an error, by only reporting it once and then self deactivating the systemd user unit. It already shows sovereignty about that file when initially creating, activating and starting it.

[probonopd]

only reporting it once and then self deactivating the systemd user unit

Yes, that would be a good thing to do. Would you like to give it a go and send a pull request?

[almereyda]

Oh, that would be my first Go project. I'll put this issue into my backlog, and return asynchronously to it, in a few weeks, months.