FS#76745 - [emacs-nativecomp] 28.2-1 emacsclient doesn't start

Attached to Project: Arch Linux
Opened by Martin Brodbeck (beedaddy) - Monday, 05 December 2022, 08:48 GMT
Last edited by Toolybird (Toolybird) - Sunday, 11 December 2022, 04:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I use emacsclient and therefore have the (user-) systemd daemon emacs.service enabled. But after system startup and logging into my desktop environment (GNOME, Wayland) I can't start emacs (client):

--- snip ---
emacsclient.desktop[5312]: Waiting for Emacs...*ERROR*: Display :0 can’t be opened
systemd[1261]: app-gnome-emacsclient-5312.scope: Couldn't move process 5312 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-emacsclient-5312.scope': No such process
dleyna-renderer-service[5242]: dLeyna: Exit
systemd[1261]: app-gnome-emacsclient-5312.scope: Failed to add PIDs to scope's control group: No such process
systemd[1261]: app-gnome-emacsclient-5312.scope: Failed with result 'resources'.
systemd[1261]: Failed to start Application launched by gnome-shell.
--- snip ---

But after restarting the daemon, it works. So I guess the daemon started perhaps too early?

Additional information:
* Emacs 28.2-1
* GNOME 43

Steps to reproduce:
1. Enable the Emacs systemd daemon: `systemctl --user enable emacs.service`
2. Reboot the machine
3. Login to desktop environment (GNOME in my case)
4. Try to start "Emacs (Client)". It won't start.

Workaround:
1. Restart the daemon with `systemctl --user restart emacs.service`
2. Now, "Emacs (Client)" starts successfully
This task depends upon

Closed by  Toolybird (Toolybird)
Sunday, 11 December 2022, 04:53 GMT
Reason for closing:  Upstream
Additional comments about closing:  See comments
Comment by Toolybird (Toolybird) - Monday, 05 December 2022, 20:59 GMT
> So I guess the daemon started perhaps too early?

Yes, it appears to be the case. So how would you propose to fix it? i.e. where is the Arch packaging bug?
Comment by Martin Brodbeck (beedaddy) - Tuesday, 06 December 2022, 06:40 GMT
I don't know where the line is between arch packaging and upstream. Feel free to close it if it's not an (Arch) bug. For me, from a user perspective, it was justifiable to file a bug report because I suspected a problem in the startup process and filed that under distribution specific. Sorry if this is not the case.
Comment by Toolybird (Toolybird) - Tuesday, 06 December 2022, 07:10 GMT
Seeing as you want it to start after the desktop has loaded, why don't you just use the desktop's built-in autostart capability? It would seem to be a better fit for this use case. Searching online for similar cases, folks have tried all sorts of hacks with varying degrees of success e.g. [1][2][3][4]

[1] https://unix.stackexchange.com/questions/397853/how-to-set-a-systemd-unit-to-start-after-loading-the-desktop
[2] https://bbs.archlinux.org/viewtopic.php?id=200094
[3] https://bbs.archlinux.org/viewtopic.php?id=267914
[4] https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg
Comment by Martin Brodbeck (beedaddy) - Thursday, 08 December 2022, 07:00 GMT
Yes, this (autostart) is the workaround I came up with in the meantime. Thanks for your suggestions.
Comment by Toolybird (Toolybird) - Sunday, 11 December 2022, 04:53 GMT
For posterity [1]. If anything, this seems like a possible deficiency in the upstream provided systemd unit, in which case reporting upstream might be appropriate. Seeing as a workaround exists, closing for now.

[1] https://bbs.archlinux.org/viewtopic.php?id=281813

Loading...