Hyprlock is core dumping when running as a per-user system service

[joeljosephreji]

I know of hypridle which can handle locking and suspending the computer after a timeout but I wanted to use the systemd hook to lock the computer if I were to suspend it on purpose. I followed the arch wiki for this and found this link: https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Sleep_hooks.

While trying to enable and run the service, hyprlock is core dumping:

× user-suspend@user.service - User suspend actions - Lock screen
     Loaded: loaded (/etc/systemd/system/user-suspend@.service; enabled; preset: disabled)
     Active: failed (Result: core-dump) since Tue 2024-07-02 23:14:56 AEST; 59s ago
 Invocation: a625f5aa5e994c0aa7d582e950871745
    Process: 70489 ExecStart=/usr/bin/hyprlock (code=dumped, signal=SEGV)

Jul 02 23:14:55 eos-laptop systemd[1]: Starting User suspend actions - Lock screen...
Jul 02 23:14:56 eos-laptop systemd[1]: user-suspend@user.service: Control process exited, code=dumped, status=11/SEGV
Jul 02 23:14:56 eos-laptop systemd[1]: user-suspend@user.service: Failed with result 'core-dump'.
Jul 02 23:14:56 eos-laptop systemd[1]: Failed to start User suspend actions - Lock screen.

I had receive some other errors earlier (but strangely didn't receive them this time) when I tried the same:

Jul 02 22:59:46 eos-laptop hyprlock[50039]: error: XDG_RUNTIME_DIR is invalid or not set in the environment.
Jul 02 22:59:46 eos-laptop hyprlock[50039]: [CRITICAL] Couldn't connect to a wayland compositor

I was able to run hyprlock without any issues on the as a systemd user service but it was pointless since the systemd user services can't get the sleep.target. So, the highly inexperience me is thinking that this has to do with running hyprlock as a root or something.

[PaideiaDilemma]

error: XDG_RUNTIME_DIR is invalid or not set in the environment I mean that is pretty clear I think? You can read about the environment in systemd user services in the arch wiki as well.

BUT I think XDG_RUNTIME_DIR should already be set and your problem is that you started your service with user-suspend@user.service as described in the archwiki. But your user refers to your username. So you have to start it with user-suspend@your_username.service. I think that could be your problem. But not 100% sure.

Anyways, hyprlock coredumping is not ideal. Any chance you can post a stacktrace here? coredumpctl dump <pid>

[joeljosephreji]

Yes, I had set up the service using user-suspend@myusername.service and XDG_RUNTIME_DIR had the value present as well (and I had found out that the value shouldn't have to be handled by me but by the WM/DE itself).

Sorry, I thought that I had included the coredump stacktrace. Let me replicate it again and post the coredump.

[joeljosephreji]

The output of the coredumpctl of the same core dump I initially had (please let me know if there is anything else I should do as well since I'm not really familiar with coredumpctl): PID: 70489 (hyprlock) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Tue 2024-07-02 23:14:56 AEST (9h ago) Command Line: /usr/bin/hyprlock Executable: /usr/bin/hyprlock Control Group: /system.slice/system-user\x2dsuspend.slice/user-suspend@user.service Unit: user-suspend@user.service Slice: system-user\x2dsuspend.slice Boot ID: * Machine ID: Hostname: eos-laptop Storage: /var/lib/systemd/coredump/core.hyprlock.0.****.70489.1719926096000000.zst (present) Size on Disk: 243K Message: Process 70489 (hyprlock) of user 0 dumped core.

            Stack trace of thread 70489:
            #0  0x0000717c60f7e1dd n/a (libc.so.6 + 0x16a1dd)
            #1  0x0000586c045500db n/a (hyprlock + 0x460db)
            #2  0x0000586c04520e17 n/a (hyprlock + 0x16e17)
            #3  0x0000586c0451ad7f n/a (hyprlock + 0x10d7f)
            #4  0x0000717c60e39c88 n/a (libc.so.6 + 0x25c88)
            #5  0x0000717c60e39d4c __libc_start_main (libc.so.6 + 0x25d4c)
            #6  0x0000586c0451c915 n/a (hyprlock + 0x12915)
            ELF object binary architecture: AMD x86-64

So the stack trace seemed to have a mangled output. I'm not sure how to resolve the symbols here.

Also, there was an output file I was able to generate using the --ouput flag but it seemed to be way too long.

[PaideiaDilemma]

Yeah sorry, you would need to build hyprlock with debug symbols to make the stacktrace useful.

[PaideiaDilemma]

It is probably because your HOME is not set in your environment. That seems to crash hyprlock.

[joeljosephreji]

Thanks for the fix! I will check it out and update here if I'm facing any issues! :)