0

emacsclient cannot open web links using neither org-open-at-point or browse-url. It does work, however, from a standalone Emacs session. I get no relevant messages in the Messages buffer, nor from emacs --debug-init. I run the Emacs server through the default systemd service file.

I get the following error message through systemctl --user status -l emacs after trying to open a link:

Aug 28 20:48:48 asahibook systemd-coredump[4142]: [🡕] Process 4139 (qutebrowser) of user 1000 dumped core.

Module libuuid.so.1 from rpm util-linux-2.40.1-1.fc40.aarch64
Module libxcb-util.so.1 from rpm xcb-util-0.4.1-5.fc40.aarch64
Module libxkbcommon-x11.so.0 from rpm libxkbcommon-1.6.0-2.fc40.aarch64
Module libICE.so.6 from rpm libICE-1.1.1-3.fc40.aarch64
Module libSM.so.6 from rpm libSM-1.2.4-3.fc40.aarch64
Module libxcb-xkb.so.1 from rpm libxcb-1.17.0-1.fc40.aarch64
...

This message goes on to list other modules for 300 lines.

I have set the following in my init.el, to no avail:

  (setq browse-url-browser-function 'browse-url-generic
        browse-url-generic-program "qutebrowser")

Version info

Emacs: 29.4

Improve this question
7
  • 2
    Test starting Emacs server without systemd Commented Aug 28, 2024 at 20:09
  • Why did qutebrowser dump core? There should be some indication in its logs. Or you could run gdb against the core dump and try to get a backtrace. Commented Aug 28, 2024 at 21:17
  • What shynur said. I expect it's a case of starting your Emacs server too early, and/or it not having the right environment. Also test starting other processes the same way -- browse-url-generic uses call-process, so you could try (call-process "/path/to/emacs" nil nil nil "-Q") for example. Commented Aug 29, 2024 at 2:02
  • @shynur Thank you, this seems to be the cause, opening web links work if I start the server manually in my terminal. Do you have any ideas as to how I can modify the systemd service to fix this? Commented Aug 29, 2024 at 9:56
  • How about using full/absolute path of qutebrowser for browse-url-generic-program? Commented Aug 29, 2024 at 13:18

2 Answers 2

Reset to default
1

As @phils stated in his first comment, the issue was with the environment, more specifically the DISPLAY environment variable not being set for the systemd service. I added the following to my emacs.service file:

[Service]
Environment="DISPLAY=:0"
Improve this answer
2
  • I think the robust solution is to make your service wait until a display has been established before running Emacs. :0 might be correct now, but I don't think that's guaranteed to always be the case. (I've certainly used machines where my primary display was sometimes :1 (and I couldn't even tell you if or whether :0 was being used, or why). Commented Sep 6, 2024 at 12:22
  • 1
    This also sounds sane to me: "It's rather bizarre to start a GUI program from the system supervisor instance of Systemd. It wasn't designed for this. GUI programs live in an X session, started by a user. The system-wide systemd is for system processes. You should experiment with daemons instead. Or (added years later now that it's a thing) you can experiment with systemd as a user session supervisor." -- unix.stackexchange.com/a/85254/41789 Commented Sep 6, 2024 at 12:31
0

Edit your emacs.service file (mine is found at /usr/lib/systemd/user/emacs.service) and change this part:

    [Install]
    WantedBy=default.target

to be this instead:

    [Install]
    WantedBy=graphical-session.target

This will cause the daemon to wait until the graphical session is ready before starting. That way Emacs will be able to make use of the graphical web browser.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.