Not shutting down on SIGTERM #164

wesx · 2017-05-28T08:11:46Z

I recently experienced huge delays when shutting down. This comes from systemd sending an SIGTERM to the process dleyna-renderer-service and waiting for the service to actually stop.
Because of the service not shutting down systemd waits a 1min and 58secs before killing the service.
The only package that uses dleyna-renderer on my system was gnome-photos. Cause i never uses this i decided to temporarily uninstall gnome-photos and dleyna-renderer to reduce my shutdown time.

With the service still running i tried to send SIGTERM to it, but nothing happens, so it seems to be an problem with the service. If you give me the location of the logfiles i can paste them here.

My version of dleyna-renderer was 0.5.0-1 and im using Arch Linux.

I hope you can fix this, else it would be very annoying to use on systemd managed systems.

szelek · 2018-03-14T01:03:19Z

The problem still exists in version 0.6.0, also on Arch Linux.
I don't know if it's dleyna-renderer or Arch's package issue.

Below shutdown logs:
systemd[11373]: dbus.service: Killing process 12436 (dleyna-renderer) with signal SIGKILL. systemd[11373]: dbus.service: Failed with result 'timeout'.

robhancock · 2018-04-17T04:51:07Z

I have been seeing the same issue. Doing a pstack on the process shows a thread that seems to be stuck in this stack trace:

#0  0x00007f5bc55b4b99 in syscall () at /lib64/libc.so.6
#1  0x00007f5bc5e7450f in g_cond_wait () at /lib64/libglib-2.0.so.0
#2  0x00007f5bc6766a8f in soup_session_process_queue_item () at /lib64/libsoup-2.4.so.1
#3  0x00007f5bc676744e in soup_session_real_send_message () at /lib64/libsoup-2.4.so.1
#4  0x00007f5bc6e45d6e in gupnp_service_info_get_introspection () at /lib64/libgupnp-1.0.so.4
#5  0x00007f5bc768b761 in prv_props_update.isra () at /usr/lib64/dleyna-renderer/libdleyna-renderer-1.0.so.1
#6  0x00007f5bc768d01d in dlr_device_get_all_props () at /usr/lib64/dleyna-renderer/libdleyna-renderer-1.0.so.1
#7  0x00007f5bc747da8f in prv_process_task () at /lib64/libdleyna-core-1.0.so.4
#8  0x00007f5bc5e2b577 in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#9  0x00007f5bc5e2eb77 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#10 0x00007f5bc5e2ef20 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#11 0x00007f5bc5e2f232 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#12 0x00007f5bc747cbdc in dleyna_main_loop_start () at /lib64/libdleyna-core-1.0.so.4
#13 0x00007f5bc54e5f2a in __libc_start_main () at /lib64/libc.so.6
#14 0x000055ef9e8b39ba in _start ()

phako · 2018-11-05T16:06:22Z

That's supposed to be fixed by fixing #104

fedelibre · 2019-01-16T06:37:25Z

I confirm the problem on Fedora (here's the bug report).

Madko · 2019-04-10T18:26:13Z

Still there on Fedora 30 Beta

rsbells · 2019-04-10T21:30:18Z

If you are able to reproduce it. Can you try to resolve it and provide a patch?

hifigraz · 2019-04-28T08:44:36Z

Problem still exists V0.6.0

hifigraz · 2019-05-07T13:40:49Z

I'get a lot of core dumps. here is a backtrace:
[robert@Titan ~] $ gdb --core=core.27555 /usr/lib/dleyna-renderer-service
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
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:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/dleyna-renderer-service...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 27555]
[New LWP 27558]
[New LWP 27557]
[New LWP 27560]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/dleyna-renderer-service'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f61f97ced70 in dlr_upnp_lost_client () from /usr/lib/dleyna-renderer/libdleyna-renderer-1.0.so.1
[Current thread is 1 (Thread 0x7f61f5c857c0 (LWP 27555))]
(gdb) bt
#0 0x00007f61f97ced70 in dlr_upnp_lost_client () at /usr/lib/dleyna-renderer/libdleyna-renderer-1.0.so.1
#1 0x00007f61f97cc4c4 in () at /usr/lib/dleyna-renderer/libdleyna-renderer-1.0.so.1
#2 0x00007f61f978a57d in () at /usr/lib/dleyna-1.0/connectors/libdleyna-connector-dbus.so
#3 0x00007f61f91d1a12 in () at /usr/lib/libgio-2.0.so.0
#4 0x00007f61f91d71b2 in () at /usr/lib/libgio-2.0.so.0
#5 0x00007f61f91de659 in () at /usr/lib/libgio-2.0.so.0
#6 0x00007f61f96a5661 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#7 0x00007f61f96a7739 in () at /usr/lib/libglib-2.0.so.0
#8 0x00007f61f96a86d2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#9 0x00007f61f9763ab6 in dleyna_main_loop_start () at /usr/lib/libdleyna-core-1.0.so.5
#10 0x00007f61f9477ce3 in __libc_start_main () at /usr/lib/libc.so.6
#11 0x0000556ad96e209e in _start ()
(gdb)

phako · 2019-05-07T14:07:41Z

That's something completely different

paulie4 · 2019-05-11T12:41:15Z

@rsbells, it happens at every shutdown, so yes, it's easily reproducible, but I'm not sure how to debug it. I edited my ~/.config/dleyna-renderer-service.conf to increase the log level and was going to restart the service, but even though I see the process running and started by systemd, I don't know how to control it with systemctl:

$ ps -O ppid -C dleyna-renderer
  PID  PPID S TTY          TIME COMMAND
 1553   878 S ?        00:00:00 /usr/lib/dleyna-renderer-service

$ ps -O ppid 878
  PID  PPID S TTY          TIME COMMAND
  878     1 S ?        00:00:00 /usr/lib/systemd/systemd --user

$ systemctl --user status dleyna-renderer-service
Unit dleyna-renderer-service.service could not be found.

$ systemctl --user status dleyna-renderer
Unit dleyna-renderer.service could not be found.

davidstrauss · 2019-05-11T19:41:33Z

@paulie4 At least on Fedora, it does not appear to run as a systemd service (either at the system level or, where you're looking with --user, the user session level). Fedora's packaging of dleyna-renderer ships the service configuration via /usr/share/dbus-1/services/com.intel.dleyna-renderer.service, which leverages the D-Bus Specification for services.

paulie4 · 2019-05-12T20:45:29Z

@davidstrauss, I'm using Arch Linux. I do see that I have a /usr/share/dbus-1/services/com.intel.dleyna-renderer.service file, but as you can see from my ps output in my previous comment, the parent process of the /usr/lib/dleyna-renderer-service process is /usr/lib/systemd/systemd --user. I couldn't see an easy way to stop/start a service in the D-Bus spec you pointed to, so I just restarted my comp instead. How would you stop/start the service?

It doesn't seem like the log-level=8 change I made to dleyna-renderer-service.conf made a difference. This is what I see in my systemd journal (the only thing that changed between machine reboots was the log level from 0x13 to 0x3F):

...
May 12 16:12:17 scruffy dbus-daemon[884]: [session uid=1000 pid=884] Activating service name='com.intel.dleyna-renderer' requested by ':1.64' (uid=1000 pid=1423 comm="/usr/bin/gnome-photos --gapplication-service ")
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: dLeyna core version 0.6.0
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: dleyna-renderer-service version 0.6.0
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Type[0] Level[0x3F] Mask[0x4C] Flags[0x4F]
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Load file [/home/paulie/.config/dleyna-renderer-service.conf]
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: [General settings]
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Never Quit: F
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Connector Name: dbus
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Port: 0
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Push host port: 0
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: [Logging settings]
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Log Type : 0
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Log Level: 0x3F
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: [Network filtering settings]
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Enabled : F
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Entries: (null)
May 12 16:12:17 scruffy dbus-daemon[884]: [session uid=1000 pid=884] Successfully activated service 'com.intel.dleyna-renderer'
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: Calling GetRenderers method
May 12 16:12:17 scruffy dleyna-renderer-service[1520]: New media server /com/intel/dLeynaRenderer/server/uuid_3aRINCON_5CAAFD296F0001400_MR
...
May 12 16:19:03 scruffy systemd[860]: dbus.service: State 'stop-final-sigterm' timed out. Killing.
May 12 16:19:03 scruffy systemd[860]: dbus.service: Killing process 1520 (dleyna-renderer) with signal SIGKILL.
May 12 16:19:03 scruffy systemd[860]: dbus.service: Failed with result 'timeout'.
...

Should there have been a log message if/when the service got a message to shutdown, which would mean that it did not get a shutdown message?

davidstrauss · 2019-05-13T01:53:16Z

@paulie4 systemd is parent to a lot of things as a user session manager, but it doesn't necessarily mean that it manages the lifecycle of something directly. Based on your logs, it looks like that the only service systemd is aware of there is dbus.service, which I suspect is your entire user session D-Bus daemon (rather than host-level) as well as anything that D-Bus daemon is launching. In this case, your user D-Bus daemon appears to launch the dleyna-renderer-service as a D-Bus (but not directly systemd) service. If the dleyna-renderer-service is double forking, it may be intentionally detaching from the D-Bus parent PID and getting re-parented to systemd. However, since systemd uses cgroups to track PID-to-service affiliations (not parent PIDs), systemd still considers the dleyna-renderer-service PID part of dbus.service and expects it to exit when dbus.service shuts down.

At least one of the following should be happening to prevent this:

dbus.service can be (and currently is) configured to have all contained PIDs sent a shutdown signal. In this model, services like dleyna-renderer-service should respond to the signal by exiting gracefully.
Alternatively, dbus.service could be configured to only have the main D-Bus PID sent the shutdown signal by systemd. However, D-Bus would then be responsible for cleaning up any other PIDs it launched.
Finally, dleyna-renderer-service could be configured to run as its own systemd service, not just launched within dbus.service. There would still need to be a way for dleyna-renderer-service to cleanly shut down, but it would isolate the problem from everything else in D-Bus.

How would you stop/start the service?

D-Bus seems to start it based on bus activity. I'm not a D-Bus expert, though. I'm just trying to explain why the service doesn't seem to appear directly in systemd's interfaces even though systemd has the parent PID. I do not know how to instruct a D-Bus-style service to shut down or even if there's a single convention for doing so.

Should there have been a log message if/when the service got a message to shutdown, which would mean that it did not get a shutdown message?

There would be logging of a similar sort if dleyna-renderer-service were directly a systemd service, but it is not. I'm unsure what to expect for a D-Bus service.

paulie4 · 2019-05-13T14:11:55Z

Do you have any suggested next steps on what to do to debug what the problem could be? Thanks!

phako · 2019-05-13T14:29:05Z

Get a stack trace from the stuck process. I assume it looks like the one in #164 (comment)

paulie4 · 2019-05-30T13:09:43Z

It was quite hard to get this thing to build, since it requires a very old version of gupnp (see Issue #166). I then ran make install, and after a restart, journalctl shows that dleyna-renderer crashed on startup:

May 30 09:03:31 scruffy dbus-daemon[912]: [session uid=1000 pid=912] Activating service name='com.intel.dleyna-renderer' requested by ':1.64' (uid=1000 pid=1451 comm="/usr/bin/gnome-photos --gapplication-service ")
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: dLeyna core version 0.6.0
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: dleyna-renderer-service version 0.6.0
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Type[0] Level[0x3F] Mask[0x4C] Flags[0x4F]
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Load file [/home/paulie/.config/dleyna-renderer-service.conf]
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: [General settings]
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Never Quit: F
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Connector Name: dbus
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Port: 0
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Push host port: 0
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: [Logging settings]
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Log Type : 0
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Log Level: 0x3F
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: [Network filtering settings]
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Enabled : F
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: Entries: (null)
May 30 09:03:31 scruffy dbus-daemon[912]: [session uid=1000 pid=912] Successfully activated service 'com.intel.dleyna-renderer'
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: server.c : prv_manager_root_method_call() --- Calling GetRenderers method
May 30 09:03:31 scruffy bijiben-shell-s[1446]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 30 09:03:31 scruffy dleyna-renderer-service[1586]: server.c : prv_found_media_server() --- New media server /com/intel/dLeynaRenderer/server/uuid_3aRINCON_5CAAFD18723401400_MR
May 30 09:03:31 scruffy audit[1586]: ANOM_ABEND auid=1000 uid=1000 gid=100 ses=3 pid=1586 comm="dleyna-renderer" exe="/usr/local/libexec/dleyna-renderer-service" sig=11 res=1
May 30 09:03:31 scruffy kernel: dleyna-renderer[1586]: segfault at 0 ip 00007fa8c9e77ed7 sp 00007ffd3891a710 error 4 in libgupnp-1.0.so.0.0.0[7fa8c9e64000+21000]
May 30 09:03:31 scruffy kernel: Code: 8d 0d 12 00 01 00 ba 04 00 00 00 48 89 c7 b8 00 00 00 00 e8 2b cf fe ff b8 00 00 00 00 e9 ed 00 00 00 48 8b 45 a8 48 8b 40 18 <48> 8b 00 48 89 c7 e8 2e d7 fe ff 48 89 45 f0 48 8b 55 c8 48 8b 45
May 30 09:03:31 scruffy kernel: audit: type=1701 audit(1559221411.832:54): auid=1000 uid=1000 gid=100 ses=3 pid=1586 comm="dleyna-renderer" exe="/usr/local/libexec/dleyna-renderer-service" sig=11 res=1
May 30 09:03:31 scruffy kernel: audit: type=1130 audit(1559221411.845:55): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1603-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 30 09:03:31 scruffy audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1603-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 30 09:03:31 scruffy systemd[1]: Created slice system-systemd\x2dcoredump.slice.
May 30 09:03:31 scruffy systemd[1]: Started Process Core Dump (PID 1603/UID 0).
May 30 09:03:31 scruffy bijiben-shell-s[1446]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 30 09:03:31 scruffy bijiben-shell-s[1446]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 30 09:03:32 scruffy systemd-coredump[1604]: Process 1586 (dleyna-renderer) of user 1000 dumped core.
                                                
                                                Stack trace of thread 1586:
                                                #0  0x00007fa8c9e77ed7 gupnp_service_info_get_introspection (libgupnp-1.0.so.0)
                                                #1  0x00007fa8ca0af3e7 prv_get_av_service_states_values (libdleyna-renderer-1.0.so.1)
                                                #2  0x00007fa8ca0afcd4 prv_props_update (libdleyna-renderer-1.0.so.1)
                                                #3  0x00007fa8ca0b0a00 dlr_device_get_all_props (libdleyna-renderer-1.0.so.1)
                                                #4  0x00007fa8ca0b80b6 dlr_upnp_get_all_props (libdleyna-renderer-1.0.so.1)
                                                #5  0x00007fa8ca0b4862 prv_process_async_task (libdleyna-renderer-1.0.so.1)
                                                #6  0x00007fa8ca0b4b19 prv_process_task (libdleyna-renderer-1.0.so.1)
                                                #7  0x00007fa8ca0649e1 n/a (libdleyna-core-1.0.so.5)
                                                #8  0x00007fa8c9aa47b1 g_main_context_dispatch (libglib-2.0.so.0)
                                                #9  0x00007fa8c9aa6869 n/a (libglib-2.0.so.0)
                                                #10 0x00007fa8c9aa77f2 g_main_loop_run (libglib-2.0.so.0)
                                                #11 0x00007fa8ca063ab6 dleyna_main_loop_start (libdleyna-core-1.0.so.5)
                                                #12 0x000055e8b22bb1d5 main (dleyna-renderer-service)
                                                #13 0x00007fa8c9730ce3 __libc_start_main (libc.so.6)
                                                #14 0x000055e8b22bb09e _start (dleyna-renderer-service)
                                                
                                                Stack trace of thread 1588:
                                                #0  0x00007fa8c97fd0d1 __poll (libc.so.6)
                                                #1  0x00007fa8c9aa67c0 n/a (libglib-2.0.so.0)
                                                #2  0x00007fa8c9aa68ae g_main_context_iteration (libglib-2.0.so.0)
                                                #3  0x00007fa8c9aa6902 n/a (libglib-2.0.so.0)
                                                #4  0x00007fa8c9a81f21 n/a (libglib-2.0.so.0)
                                                #5  0x00007fa8c98d9a92 start_thread (libpthread.so.0)
                                                #6  0x00007fa8c9807cd3 __clone (libc.so.6)
                                                
                                                Stack trace of thread 1593:
                                                #0  0x00007fa8c980297d syscall (libc.so.6)
                                                #1  0x00007fa8c9a55141 g_cond_wait_until (libglib-2.0.so.0)
                                                #2  0x00007fa8c9ad6343 n/a (libglib-2.0.so.0)
                                                #3  0x00007fa8c9ad6543 g_async_queue_timeout_pop (libglib-2.0.so.0)
                                                #4  0x00007fa8c9a7ae9a n/a (libglib-2.0.so.0)
                                                #5  0x00007fa8c9a81f21 n/a (libglib-2.0.so.0)
                                                #6  0x00007fa8c98d9a92 start_thread (libpthread.so.0)
                                                #7  0x00007fa8c9807cd3 __clone (libc.so.6)
                                                
                                                Stack trace of thread 1601:
                                                #0  0x00007fa8c97fd0d1 __poll (libc.so.6)
                                                #1  0x00007fa8c9aa67c0 n/a (libglib-2.0.so.0)
                                                #2  0x00007fa8c9aa68ae g_main_context_iteration (libglib-2.0.so.0)
                                                #3  0x00007fa8c54a8bde n/a (libdconfsettings.so)
                                                #4  0x00007fa8c9a81f21 n/a (libglib-2.0.so.0)
                                                #5  0x00007fa8c98d9a92 start_thread (libpthread.so.0)
                                                #6  0x00007fa8c9807cd3 __clone (libc.so.6)
                                                
                                                Stack trace of thread 1589:
                                                #0  0x00007fa8c97fd0d1 __poll (libc.so.6)
                                                #1  0x00007fa8c9aa67c0 n/a (libglib-2.0.so.0)
                                                #2  0x00007fa8c9aa77f2 g_main_loop_run (libglib-2.0.so.0)
                                                #3  0x00007fa8c9c1a648 n/a (libgio-2.0.so.0)
                                                #4  0x00007fa8c9a81f21 n/a (libglib-2.0.so.0)
                                                #5  0x00007fa8c98d9a92 start_thread (libpthread.so.0)
                                                #6  0x00007fa8c9807cd3 __clone (libc.so.6)
May 30 09:03:32 scruffy systemd[1]: [email protected]: Succeeded.
May 30 09:03:32 scruffy kernel: audit: type=1131 audit(1559221412.198:56): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1603-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 30 09:03:32 scruffy audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-1603-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

hifigraz · 2019-07-06T21:37:02Z

This problem still exists even two years later, this is a little bit discouraging.

hifigraz · 2019-08-31T19:36:24Z

and it still exists

phako · 2019-09-01T11:49:03Z

@hifigraz Not really helpful.

hifigraz · 2019-09-01T11:56:04Z

Hi @phako
I managed to remove gnome-photos and dleyna-renderer now the system works as expected.

Fixes intel#104 Fixes intel#164

erus · 2020-01-18T19:08:43Z

I am currently running the branch from @phako with the fix for this bug, have not seen any shutdown issues since.
Thanks !

maggu2810 · 2020-04-18T07:21:05Z

I am running Fedora 32 and realized that on shutdown I need to wait > 90 seconds (the time systemd decides to not wait anymore but kill a service).

It seems to be caused by dleyna-renderer not shutting down on sigterm.
See:

Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Child 12165 belongs to gnome-session-restart-dbus.service.
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Main process exited, code=exited, status=0/SUCCESS
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Succeeded.
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Service will not restart (restart setting)
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Changed running -> dead
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Consumed 5ms CPU time.
Apr 18 00:35:35 m3800.localdomain systemd[1705]: gnome-session-restart-dbus.service: Collecting.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: State 'stop-sigterm' timed out. Killing.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Killing process 6503 (dleyna-renderer) with signal SIGKILL.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Changed stop-sigterm -> stop-sigkill
Apr 18 00:37:05 m3800.localdomain systemd[1705]: Received SIGCHLD.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: Child 6503 (dleyna-renderer) died (code=killed, status=9/KILL)
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Child 6503 belongs to dbus-:[email protected].
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Main process exited, code=killed, status=9/KILL
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Failed with result 'timeout'.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Service restart not allowed.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Changed stop-sigkill -> failed
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Job 2084 dbus-:[email protected]/stop finished, result=done
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Unit entered failed state.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Consumed 554ms CPU time.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus-:[email protected]: Control group is empty.
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus\x2d:1.2\x2dcom.intel.dleyna\x2drenderer.slice changed active -> dead
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus\x2d:1.2\x2dcom.intel.dleyna\x2drenderer.slice: Job 2083 dbus\x2d:1.2\x2dcom.intel.dleyna\x2drenderer.slice/stop finished, result=done
Apr 18 00:37:05 m3800.localdomain systemd[1705]: dbus\x2d:1.2\x2dcom.intel.dleyna\x2drenderer.slice: Consumed 1.142s CPU time.

hifigraz · 2020-04-18T08:22:36Z

I am running Fedora 32 and realized that on shutdown I need to wait > 90 seconds (the time systemd decides to not wait anymore but kill a service).

Don‘t expect this to be fixed. It’s known and open for years now.

erus · 2020-04-18T09:59:43Z

I am running Fedora 32 and realized that on shutdown I need to wait > 90 seconds (the time systemd decides to not wait anymore but kill a service).

Don‘t expect this to be fixed. It’s known and open for years now.

The branch from @phako fixes the issue for me : depending on your distribution, they may be willing to use his patchset for their package.

maggu2810 · 2020-04-18T10:47:19Z

depending on your distribution, they may be willing to use his patchset for their package

It seems to be reported to the distribution over two years ago: https://bugzilla.redhat.com/show_bug.cgi?id=1520740

So, it seems there is no change to get it solved. Wired.

maggu2810 · 2020-04-19T07:04:15Z

I worked around it another way, so I do not need to wait for a fixed dleyna-renderer or some distribution action (who knows if it happen).

Fedora (and perhaps the other distros, too) starts the dleyna-renderer-service as a user service.
So, we just need to ensure that systemd kills it (with sigkill) if the user session stops.

as user:

mkdir -p $HOME/.config/systemd/user

cat <<EOF > $HOME/.config/systemd/user/dleyna-renderer-service-kill.service
[Unit]
Description=Kills the dleyna-rednerer-service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=/usr/bin/killall -9 dleyna-renderer-service

[Install]
WantedBy=multi-user.target
EOF

systemctl --user daemon-reload

systemctl --user enable --now dleyna-renderer-service-kill.service

That's it.

hifigraz · 2020-04-30T19:01:08Z

That's it.

That works, but that's not it.
Thank you for this idea and quick hack.

But it is really sad, that the patch by @phako is completely ignored by the original author? The software provider seems to be completely unreliable.

Best Robert

Fixes intel#104 Fixes intel#164

prevents 2min hang if dleyna service is stale. intel/dleyna-renderer#164 (comment)

FabianInostroza mentioned this issue Jun 2, 2018

System hangs at reboot/shutdown - Arch Linux systemd/systemd#1615

Closed

phako added a commit to phako/dleyna-renderer that referenced this issue Sep 21, 2019

Do service introspection on device creation

0dcfb58

Fixes intel#104 Fixes intel#164

phako added a commit to phako/dleyna-renderer that referenced this issue Sep 21, 2019

Do service introspection on device creation

1ce12ff

Fixes intel#104 Fixes intel#164

phako added a commit to phako/dleyna-renderer that referenced this issue Oct 30, 2019

Do service introspection on device creation

a588dd1

Fixes intel#104 Fixes intel#164

phako added a commit to phako/dleyna-renderer that referenced this issue Dec 1, 2020

Do service introspection on device creation

e6804fb

Fixes intel#104 Fixes intel#164

lalmeras added a commit to powo-roles/powo.misc that referenced this issue Feb 27, 2021

kill dleyna service at shutdown

6901739

prevents 2min hang if dleyna service is stale. intel/dleyna-renderer#164 (comment)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Not shutting down on SIGTERM #164

Not shutting down on SIGTERM #164

wesx commented May 28, 2017

szelek commented Mar 14, 2018

robhancock commented Apr 17, 2018 •

edited

Loading

phako commented Nov 5, 2018 •

edited

Loading

fedelibre commented Jan 16, 2019

Madko commented Apr 10, 2019

rsbells commented Apr 10, 2019

hifigraz commented Apr 28, 2019

hifigraz commented May 7, 2019

phako commented May 7, 2019

paulie4 commented May 11, 2019

davidstrauss commented May 11, 2019 •

edited

Loading

paulie4 commented May 12, 2019

davidstrauss commented May 13, 2019 •

edited

Loading

paulie4 commented May 13, 2019

phako commented May 13, 2019

paulie4 commented May 30, 2019

hifigraz commented Jul 6, 2019

hifigraz commented Aug 31, 2019

phako commented Sep 1, 2019

hifigraz commented Sep 1, 2019

erus commented Jan 18, 2020

maggu2810 commented Apr 18, 2020 •

edited

Loading

hifigraz commented Apr 18, 2020

erus commented Apr 18, 2020

maggu2810 commented Apr 18, 2020

maggu2810 commented Apr 19, 2020 •

edited

Loading

hifigraz commented Apr 30, 2020

Not shutting down on SIGTERM #164

Not shutting down on SIGTERM #164

Comments

wesx commented May 28, 2017

szelek commented Mar 14, 2018

robhancock commented Apr 17, 2018 • edited Loading

phako commented Nov 5, 2018 • edited Loading

fedelibre commented Jan 16, 2019

Madko commented Apr 10, 2019

rsbells commented Apr 10, 2019

hifigraz commented Apr 28, 2019

hifigraz commented May 7, 2019

phako commented May 7, 2019

paulie4 commented May 11, 2019

davidstrauss commented May 11, 2019 • edited Loading

paulie4 commented May 12, 2019

davidstrauss commented May 13, 2019 • edited Loading

paulie4 commented May 13, 2019

phako commented May 13, 2019

paulie4 commented May 30, 2019

hifigraz commented Jul 6, 2019

hifigraz commented Aug 31, 2019

phako commented Sep 1, 2019

hifigraz commented Sep 1, 2019

erus commented Jan 18, 2020

maggu2810 commented Apr 18, 2020 • edited Loading

hifigraz commented Apr 18, 2020

erus commented Apr 18, 2020

maggu2810 commented Apr 18, 2020

maggu2810 commented Apr 19, 2020 • edited Loading

hifigraz commented Apr 30, 2020

robhancock commented Apr 17, 2018 •

edited

Loading

phako commented Nov 5, 2018 •

edited

Loading

davidstrauss commented May 11, 2019 •

edited

Loading

davidstrauss commented May 13, 2019 •

edited

Loading

maggu2810 commented Apr 18, 2020 •

edited

Loading

maggu2810 commented Apr 19, 2020 •

edited

Loading