Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#61602 - [systemd] Running "systemctl --user daemon-reload" will causes erratic behaviour.

Attached to Project: Arch Linux
Opened by DCyrax (DCyrax) - Friday, 01 February 2019, 19:11 GMT
Last edited by Jan de Groot (JGC) - Friday, 31 May 2019, 06:48 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



When command "systemctl --user daemon-reload" is run under Desktop Environment (in my case LXDE) at terminal console window (roxterm or lxterminal), whole desktop will shut down. After crash, running "systemctl --user daemon-reload" at login terminal will give this error message : "Failed to connect bus : connection refused".

Rerunning Desktop Environment from login virtual terminal (startx) gives (possible semi) working desktop. When running roxterm under this kind desktop, it will give error message window where error message is : "Error connection to dbus: Failed to connect socket /run/user/1000/bus: Connection refused". After confirming the dialog, roxterm starts.
Other programs seems to work fine.

Additional info:

Package versions installed on my system:
lib32-systemd 240.34-1
libsystemd 240.34-3
systemd 240.34-3
systemd-sysvcompat 240.34-3

Steps to reproduce:
0. Ensure that systemd 240.34-3 package is installed.
1. Start LXDE Desktop Environment.
2. Run LXTerminal and execute command "systemctl --user daemon-reload" in it.
This task depends upon

Closed by  Jan de Groot (JGC)
Friday, 31 May 2019, 06:48 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Configuration error.
Comment by DCyrax (DCyrax) - Friday, 01 February 2019, 22:36 GMT
Attached coredump of systemd process.
Comment by DCyrax (DCyrax) - Friday, 01 February 2019, 22:38 GMT
Running "sudo systemctl daemon-reload" inside a LXC container will crash the container.
Comment by DCyrax (DCyrax) - Friday, 01 February 2019, 22:38 GMT
PID: 1108 (systemd)
UID: 1000 (john)
GID: 1000 (john)
Signal: 11 (SEGV)
Timestamp: Sat 2019-02-02 00:31:30 +02 (8min ago)
Command Line: /usr/lib/systemd/systemd --user
Executable: /usr/lib/systemd/systemd
Control Group: /user.slice/user-1000.slice/user@1000.service/init.scope
Unit: user@1000.service
User Unit: init.scope
Slice: user-1000.slice
Owner UID: 1000 (john)
Boot ID: af56042f18544566b0fb21d3510733df
Machine ID: cb60c5e56a7b4166b6d53a26733978f8
Hostname: shodan
Storage: /var/lib/systemd/coredump/core.systemd.1000.af56042f18544566b0fb21d3510733df.1108.1549060290000000.lz4
Message: Process 1108 (systemd) of user 1000 dumped core.

Stack trace of thread 1108:
#0 0x00007ffadb75f3f5 serialize_item_format (
#1 0x0000561a31c097f1 n/a (systemd)
#2 0x0000561a31c402b6 n/a (systemd)
#3 0x0000561a31b9bc26 n/a (systemd)
#4 0x00007ffadb8e4223 __libc_start_main (
#5 0x0000561a31b9d17e n/a (systemd)

GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/systemd/systemd...(no debugging symbols found)...done.
[New LWP 1108]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/".
Core was generated by `/usr/lib/systemd/systemd --user'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ffadb75f3f5 in serialize_item_format () from /usr/lib/systemd/
(gdb) bt
#0 0x00007ffadb75f3f5 in serialize_item_format () from /usr/lib/systemd/
#1 0x0000561a31c097f1 in ?? ()
#2 0x0000561a31c402b6 in ?? ()
#3 0x0000561a31b9bc26 in ?? ()
#4 0x00007ffadb8e4223 in __libc_start_main () from /usr/lib/
#5 0x0000561a31b9d17e in ?? ()
Comment by DCyrax (DCyrax) - Friday, 01 February 2019, 22:49 GMT
Looks like that globally limiting the process stack size to 1MB will cause this bug to happen. If stack size is the default - 8MB - then this bug goes away.

Comment by DCyrax (DCyrax) - Friday, 01 February 2019, 23:01 GMT
When using DefaultLimitSTACK=2M in both files, this bug doesn't appear any more.
Comment by Jake Kreiger (Magali75) - Saturday, 02 February 2019, 10:54 GMT
Arch doesn't touch "DefaultLimitSTACK" at all. If you think there is a bug please report it upstream.