A stop job is running for User Manager for UID 1000 (x / 2mins) because of emacs-daemon

[c02y]

Description :octocat:

Hi, I use emacs a lot and restart it since I change my init.el from time to time, so I started to use emacs.service about one year ago using command like

systemctl --user enable emacs.service
systemctl --user start emacs.service

/usr/lib/systemd/user/emacs.service will be symbolinked as ~/.config/systemd/user/default.target.wants/emacs.service

the content of the emacs.service is:

$ cat /usr/lib/systemd/user/emacs.service
[Unit]
Description=Emacs text editor
Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/

[Service]
Type=notify
ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
# The location of the SSH auth socket varies by distribution, and some
# set it from PAM, so don't override by default.
# Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=on-failure

[Install]
WantedBy=default.target

So every time I start my computer, emacs daemon will be started in emacs.service in background, and I only need to start emacsclient to open emacs window to edit my files.

OK, this is just background, people familiar with emacs daemon know what I'm talking about.

---

But I have been suffering from a problem for a long time, and for some reasons, recently I have to reboot my computer repeatedly and this problem occurs to me many times, so this is the time I need to fix it.

When I reboot or shutdown my computer, the black screen will always display the following message:

A stop job is running for User Manager for UID 1000 (x / 2mins)

and I have to wait for 2 mins to successfully reboot or shutdown my computer, of course I can just Ctrl-Alt-Delete to force it to restart/shutdown, but this is not happening when I use Linux in VirtualBox a guest OS since Ctrl-Alt-Delete is for host OS, ANYWAY, typing Ctrl-Alt-Delete to force it to restart/shutdown it no OK for me.

I tried to disable emacs.service using systemctl --user disable emacs.service; systemctl --user stop emacs.service, and reboot, the message is gone, and my computer restarts very quickly.

And I tried to analyze the journal log using journalctl -rb -1, there are some lines like:

Oct 28 16:29:21 chz-pc kernel: audit: type=1131 audit(1572251361.509:103): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? >
Oct 28 16:29:21 chz-pc kernel: kauditd_printk_skb: 7 callbacks suppressed
Oct 28 16:29:21 chz-pc systemd[1]: Stopping User Runtime Directory /run/user/1000...
Oct 28 16:29:21 chz-pc audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Oct 28 16:29:21 chz-pc systemd[1]: Stopped User Manager for UID 1000.
Oct 28 16:29:21 chz-pc systemd[1]: [email protected]: Failed with result 'timeout'.
Oct 28 16:29:21 chz-pc systemd[1]: [email protected]: Killing process 876 (emacs) with signal SIGKILL.
Oct 28 16:29:21 chz-pc systemd[1]: [email protected]: Killing process 866 (systemd) with signal SIGKILL.
Oct 28 16:29:21 chz-pc systemd[1]: [email protected]: State 'stop-sigterm' timed out. Killing.
Oct 28 16:28:51 chz-pc emacs[876]: Buffer recentf<3> modified; kill anyway? (y or n)
Oct 28 16:28:51 chz-pc systemd[866]: emacs.service: Control process exited, code=killed, status=15/TERM
Oct 28 16:28:51 chz-pc systemd[866]: emacs.service: Stopping timed out. Terminating.
Oct 28 16:27:22 chz-pc audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=su>
Oct 28 16:27:22 chz-pc systemd[1]: Stopped Login Service.
Oct 28 16:27:22 chz-pc systemd[1]: systemd-logind.service: Succeeded.

So stopping emacs.service timed out, and it gets stuck there for over 1 minute,

Look at the line "Oct 28 16:28:51 chz-pc emacs[876]: Buffer recentf<3> modified; kill anyway? (y or n)", it is the problem of recentf, and I have problems about recentfs in spacemacs from time to time, such as https://github.com/syl20bnr/spacemacs/issues/5186, this is another one.

And I tried to edit /etc/systemd/user.conf and setting DefaultTimeoutStopSec=5s, it works, reboot after display that 2mins message only for a few seconds, but it is only workaround, this is still the problem of emacs/spacemacs.

And I tried to remove my ~/.emacs.d and use a clean emacs, the problem is gone, so I believe this is problem of my ~/.emacs.d which is provided my spacemacs.

And I tried to use ~/.emacs/core/templates/.spacemacs.templte as init.el OR use inite.el which contains many configs based on it, they have the same results.

So is there better solution that I don't have to see this message and normally reboot/shutdown as fast as possible?

And could spacemacs just save the recentf file when it gets modified or just disable recentf-mode completely?

BTW:

• OS: Manjaro+KDE, OR openSUSE Tumbleweed+KDE
• emacs version: 26.2 OR 26.3 OR 27.0
• platform: VirtualBox OR real hardware
• init.el: ~/.emacs/core/templates/.spacemacs.templte as init.el or many configs based on it

---

UPDATE:

I found a similar question and found that that situation is exactly the same with mine, but it got no replies. https://www.reddit.com/r/emacs/comments/ay1r5g/emacs_server_recentf_issue/

Reproduction guide :beetle:

• systemctl --user enable emacs.service
• systemctl --user start emacs.service
• reboot
• login
• open terminal execute reboot or click reboot icon in DE
• look at the screen
• NOTE: I didn't even open emacs or emacsclient yet, just emacs daemon during the startup, I tried this process multiple times, the 2mins problem is already there.

Observed behavior: :eyes: :broken_heart: A stop job is running for User Manager for UID 1000 (x / 2mins)

Expected behavior: :heart: :smile: restart/shuntdown immediately

System Info :computer:

• OS: gnu/linux
• Emacs: 27.0.50
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 5bcc96e)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(emacs-lisp helm multiple-cursors treemacs)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Backtrace :paw_prints:

<<BACKTRACE IF RELEVANT>>

[hg-zt]

This could be reproduced without systemd (27.0.50). Run emacs --fg-daemon in one terminal and then run emacsclient --eval "(kill-emacs)" (or save-buffers-kill-terminal) in another. The former terminal will show "Buffer recentf modified; kill anyway?" while the later hangs.

[c02y]

@hg-zt I believe this is a serious problem then, since it is OK for vanilla emacs.

[clwgg]

I fixed this behavior by including the following in my systemd unit file:

ExecStart=/usr/bin/emacs --fg-daemon=base
ExecStop=/usr/bin/emacsclient --eval "(let (kill-emacs-hook)(kill-emacs))" -s base

This will set kill-emacs-hook to nil before killing emacs when shutting down the service. Also, it gives a different, specific base-name to the emacs process managed by systemd.

I have to disclose, however, that I am unsure about how save it is to kill spacemacs with an empty kill hook. Someone more familiar with the code base would have to chip in on that.

[c02y]

@clwgg It works, I can live with this workaround, thanks.

[c02y]

I fixed this behavior by including the following in my systemd unit file:

ExecStart=/usr/bin/emacs --fg-daemon=base
ExecStop=/usr/bin/emacsclient --eval "(let (kill-emacs-hook)(kill-emacs))" -s base

This will set kill-emacs-hook to nil before killing emacs when shutting down the service. Also, it gives a different, specific base-name to the emacs process managed by systemd.

I have to disclose, however, that I am unsure about how save it is to kill spacemacs with an empty kill hook. Someone more familiar with the code base would have to chip in on that.

It works for Emacs27, but something is not right when using emacsclient for Emacs28 (I'm using emacs-git from AUR), after the service is started during systemd:

$ emm  # this is the script I use to start emacsclient, if server/service is not running, start it first.
Start emacsclient...
emacsclient: connect: Connection refused

Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
Loading /home/chz/.spacemacs.d/init.el (source)...
Loading /home/chz/.spacemacs.d/init.el (source)...done
Starting new Ispell process aspell with en_US dictionary... \
Starting new Ispell process aspell with en_US dictionary...done
Spacemacs is ready.
Emacs daemon should have started, trying to connect again
...

Normally it is only:

$ emm
Start emacsclient...

I guess this is because the server-socket-dir function in emacs source code is changed in Emacs28, and the socket file is /run/user/1000/emacs/ instead of /tmp/emacs1000/ for Emacs27.

So I have to change my emm script, change dotspacemacs-server-socket-dir and server-socket-dir variables in init.el, and I tried, but failed to make it work as expected.

So now I use:

ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --eval "(let (kill-emacs-hook)(kill-emacs))"

No need to change anything else.

And it works expected for Emacs28.

[khensunny]

This issue is start to drive me crazy because the advantage of the daemon in Spacemacs is that you no longer get irritated by it's startup time. Anyways, as I try to debug this I found that for me emacsclient -e "(kill-emacs)" works fine if there's a client around (gui/cli). So now I figure I could have a script that runs something like this:

emacsclient -c & # or emacsclient -nw /tmp/boohoo &
exec emacsclient -e "(kill-emacs)"

[khensunny]

if using systemd don't use the option in comments, it complains saying terminal type not known

[khensunny]

this is actually a bit better: emacsclient -c -e "(kill-emacs)"... thought it worked well until I tried to logout

[khensunny]

Okay, so now I started debugging. And the issue might be caused by persp-mode. Placed it in list of excluded packages then emacs systemd service started working fine

[Dietr1ch]

I faced this long ago and ended up with this workaround,

https://github.com/Dietr1ch/dotfiles/blob/master/.config/systemd/user/emacs.service

...
[Service]
...
ExecStop=/usr/bin/emacsclient --eval "(progn (recentf-save-list) (kill-emacs))"

I figured out that emacs was hanging on saving recentf's recent file list. IIRC this can be reproduced by trying to stop the user daemon (systemctl --user stop emacs) and opening a new client, which will be able to show some recentf prompts that prevent emacs from shutting down.

---

BTW, this issue has been around for a while: https://unix.stackexchange.com/questions/28485/how-can-i-get-recentf-mode-to-work-with-emacs-server-client

[LuisChDev]

The way I fixed this while keeping kill-emacs-hook was by ensuring recentf-save-list was executed at the end of the hook, right before (kill-emacs). like this:

ExecStop=/path/to/emacsclient --eval "(let ((kill-emacs-hook (append kill-emacs-hook '(recentf-save-list)))) (save-buffers-kill-emacs t))"

[eike-fokken]

The way I fixed this while keeping kill-emacs-hook was by ensuring recentf-save-list was executed at the end of the hook, right before (kill-emacs). like this:

ExecStop=/path/to/emacsclient --eval "(let ((kill-emacs-hook (append kill-emacs-hook '(recentf-save-list)))) (save-buffers-kill-emacs t))"

Thank you so much, this finally solved it for me. For future readers: Another important ingredient for the solution in my setup was to run configuration-layer/update-packages.

EDIT: Sadly I was mistaken. This only solved it for me because I forgot to change path/to/emacsclient to /usr/bin/emacsclient, which actually is a way to get rid of it but probably kills the process no matter what without saving recentf. I still have no luck, any more input is welcome!

[eike-fokken]

I now found this solution, which is probaly rather crass: ExecStop=/usr/bin/emacsclient --eval "(let (kill-emacs-query-functions confirm-kill-emacs kill-emacs-hook) (progn ((recentf-save-list) (save-buffers-kill-emacs)))))"

from emacs.stackexchange-question

to my understanding this sets the variables kill-emacs-query-functions, confirm-kill-emacs, kill-emacs-hook to nil before quitting which may be too much, but I'll run with it for now.

[rberger]

I just installed the develop spacemacs on my iMac running macOS Catalina and was having a problem where spacemacs would completely hang. Could not even sudo kill -9 or Force Quit. I was rebooting to get out of it.

Then I tried the solution by @eike-fokken suggested and that seemed to reset things.

[Bad-ptr]

This may be fixed

[thecountoftuscany]

I can confirm that I am still facing this issue. Although @eike-fokken's workaround seems to work for me.

[Bad-ptr]

May be fixed again )

[real-or-random]

May be fixed again )

I'm running the latest persp-mode and this does not fix the problem for me.

[real-or-random]

May be fixed again )

I'm running the latest persp-mode and this does not fix the problem for me.

Ok, please ignore this comment. Sorry, I was having some other problem, and I can't tell right now if upgrading persp-mode helped with this issue here.

[m4lvin]

It seems this happens even with standard emacs (not spacemacs), and that another (in my case: also needed) workaround is to give emacs more time to shutdown: https://bugs.archlinux.org/task/67505

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!