FS#67505 - [emacs] default systemd user service kills server improperly, likely due to race condition

Attached to Project: Arch Linux
Opened by Hoot (drountian) - Thursday, 06 August 2020, 00:02 GMT
Last edited by Jürgen Hötzel (juergen) - Monday, 12 September 2022, 13:17 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jürgen Hötzel (juergen)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
At least on my system, when the default emacs user service is enabled, and the computer is shutdown, or the service is manually stopped, the server exits with a non 0 exit code. In my case using the default "ExecStop=emacsclient --eval "(kill-emacs)" the exit code is 15. I have worked around the issue by adding "ExecStop=sleep 1" to the [Service] section of a systemd user override (systemd --user edit emacs.service), so now ExecStop calls "emacsclient --eval "(kill-emacs)" and then calls "sleep 1" which makes it wait long enough for the server to exit.

Thanks a lot to "Colin Guthrie" who's assistance of another helped me work around this issue, see "https://lists.freedesktop.org/archives/systemd-devel/2015-August/033872.html".

I am certain that I am doing this rather clumsily, but I'm not sure if there's a better way, perhaps running the server as a forked "--bg-daemon" process instead of the simple "--fg-daemon"? Not sure this is ideal.

I am a bit of a newbie when it comes to systemd and much of the Linux ecosystem, so if there's anything I've missed that would help, let me know.

Additional info:
* package version(s)
emacs 26.3-2
systemd 245.7-1

* config and/or log files etc.
With the default unit file on exit the journal shows:
"emacs.service: Main process exited, code=exited, status=15/n/a"
"emacs.service: Failed with result 'exit-code'."
With the workaround applied these errors do not appear.

* link to upstream bug report, if any
None yet as I'm not certain this occurs on all systems, or if other packages have different systemd units included, if it's confirmed on other systems I might be able to report upstream.

Steps to reproduce:
1. Make sure your system is managed by systemd.
2. Install emacs (pacman -Syu emacs)
3. Run "systemctl --user start emacs.service" to start the default emacs user service
4. Verify the server is working (perhaps with "emacsclient -c", closing it when done).
5. Run "systemctl --user stop emacs.service"
6. Use "journalctl --user-unit=emacs.service" and observe the error.
This task depends upon

Closed by  Jürgen Hötzel (juergen)
Monday, 12 September 2022, 13:17 GMT
Reason for closing:  Fixed
Comment by Jürgen Hötzel (juergen) - Tuesday, 11 August 2020, 19:56 GMT
Thanks for your detailed bug report!

I can confirm this is still an issue in emacs-27.1
Comment by Noel Maersk (veox) - Tuesday, 15 September 2020, 19:46 GMT
<edited> - wrong bug, sorry.
Comment by mephinet (mephinet) - Wednesday, 11 November 2020, 09:32 GMT
I can confirm the issue, and that the sleep-1 work-around works fine for me.
Comment by Jan Felix Langenbach (Janfel) - Wednesday, 24 March 2021, 20:46 GMT
I want to add, that using `tail --pid=${MAINPID} --follow /dev/null` is a more robust workaround than using `sleep 1`.
Comment by Tim Ruffing (realorrandom) - Sunday, 11 September 2022, 09:50 GMT
This has been solved upstream in emacs 28.1, see commit https://github.com/emacs-mirror/emacs/commit/e5348f125ff03ac70713e5b227f9e51f759a587b .

Loading...