System hangs at reboot/shutdown - Arch Linux #1615

Closed
prescott66 opened this Issue Oct 19, 2015 · 68 comments

Projects

None yet
@prescott66

Hi.
When i try to shutdown/reboot arch linux, my system hangs to cca 90 seconds and then shutdown or reboot.
I have created bug report at arch's bugzilla, but there is no one, who can find the problem.
It looks like there is problem with systemd, because after update to v227 issue is fixed for few reboots, then is back.
PLEASE take a look at my logs in bug report. Maybe you will find problem:

https://bugs.archlinux.org/task/46709

@prescott66

Now i get two jobs, that are waiting to stop at shutdown:
1.)Session c1 of user
2.)User manager for UID 1000

@dvdhrm
Member
dvdhrm commented Oct 23, 2015

If your session is not stopped at shutdown, it's very likely due to a program in your session being stuck. Please try logging out of your session and then check via a different user which programs are still running in that session. The systemd-cgls tool might come in handy.

@elkrejzi
Contributor

Apparently I'm not the only one with this issue. I ran into it too. See also

http://lists.freedesktop.org/archives/systemd-devel/2016-January/035619.html

Hope it gets resolved soon.

@Potomac
Potomac commented Feb 23, 2016

I have the same bug, a message "A stop job is running for Session c2 for user...." and a delay of 90 seconds,

I use archlinux, systemd 229-3

@ongun-kanat

Same as @Potomac here. Ver. 229-3

@diegoviola

Same problem here on systemd 229 (archlinux)

@nagyf
nagyf commented Mar 10, 2016

I have the same problem, systemd 229-3, arch linux. How can we check what program hangs?

@ongun-kanat

@nagyf I don't think it's about a program refuses to terminate but systemd guys screwed user services things so that the user daemon of systemd fails to shutdown properly.

@ghost
ghost commented Mar 11, 2016

I approve, have similar problem on Arch with systemd 229-3. It's definately not connected with desktop manager but only systemd :( I'm waiting for fix couse right now almost every shutdown seems to be the weakest part of my system.

@meradoou

I have same problem on Archlinux

@M-Tarasov

I can also confirm the issue with systemd 229-3 on Arch Linux

@varlesh
varlesh commented Mar 13, 2016

Confirm this

@cross1983

I have the same issue periodically (not each time). So i confirm this issue.

@manjarqo

I confirm the issue too

@virpool
virpool commented Mar 13, 2016

Confirm this issue too.

@lynxthecat

Confirmed Archlinux. Something about "Session c1 of user" and hangs without shutting down properly. I can still Ctrl-Alt-F but otherwise unresponsive.

@GeorgeTG

I have this issue too, but only on my desktop. Version 229-3 Arch Linux. Happens randomely at reboot/shutdown. "Session c2 of user" and i get a 90 sec timeout. Any way we can help or provide more info on this ?

@nabildanial

I'm using systemd 229-3 Arch and I can confirm this. Its already continuing hanging on shutdown for about 2 weeks now.

EDIT: A workaround here. I'm using Gnome, loging out current seesion before reboot/shutdown works for me. But it still doesn't remedy the problem.

@hexagonal-sun

+1 on Arch Linux.

@firekage

I can confirm it. In fact, i have this for a long time - Arch linux. What is strange, i don't have it on laptop machine and netbook machine. On all of them, i have nearly exacly the same programs, and apps but only on desktop i have conky.

BTW - this "bug" is not only true for 229-3. I had previous version with the same bug.

Edit: after yesterday updates, my laptop and netbook machines have the same behaviour during shutdown.

@benjarobin
Contributor

I have done an analyze here #2691 (comment) And I think I found the root cause of the problem. The solution is not that easy, I have got an idea how to solve the problem (but I don't like it), I thing @poettering will have a better idea

@Potomac
Potomac commented Mar 30, 2016

there is a workaround found by Ebiggers :

just create a file "/etc/sysctl.d/50-coredump.conf" with the following contents:

kernel.core_pattern=core

then after a reboot this bug will never occur

@bakteria1

Same issue here

@Potomac
Potomac commented Apr 4, 2016

despite the workaround found by Ebiggers I still have the bug ( "a stop job for session C2 user" )

it's a random bug, for example it can occur after 10 reboots ( that's why I thought it was solved, we need to test with a lot of reboot/shutdown, the bug will be considered as solved only when no bug occurs after at least 10~15 reboots )

@varlesh
varlesh commented Apr 4, 2016

Yes, random. Sometime reboot now, sometime reboot wait 90 sec. I kill plasmashell and other processes change DM (lightdm, sddm, slim) - this not solved problem.

@adeleglise

Hi all,
I'm facing the same issue.

@molecularresearcher

Thank you very much!
I did how Potomac described and the problem is solved.

ISamsung NC10 and Acer Aspire 7739 - and in both Arch Linux Kernel 4.4

@kyawthusoe3142

Systemd 215-17, Debian Jessie: confirm this.

@layus
layus commented Apr 13, 2016

(Modified version of an ArchLinux forum discussion)

There appears to be two distinct issues with systemd 226-3 (and some other versions).

The first one is an issue with coredumps when killing applications, and is described at #2691.

The other is a bug with applications refusing to die, and is not an issue with systemd, but with the application itself. This is the case with conky for example.

@benjarobin has done a very good job at explaining the two failures in a series of comments.
(See #2691 (comment) and following).

Both cases are linked with the application reacting badly to the SIGTERM sent to to them when the system goes down.

  • In the first case, the application crashes, but a bug with coredumps makes the system wait forever on the coredump service that can not start during shutdown. See #2993 for an attempt at fixing it.
  • In the second case, the application ignores (or misses) the SIGTERM signal and continues running, unaware of the shutdown.
    As systemd cannot tell this situation from a service requiring more time to exit cleanly, it must wait untill the hard limit of 90s before killing the process with SIGKILL. Fixing the application is the way to go. For conky I have submitted brndnmtthws/conky#233.

Of course, this does not explain why so many programs started to fail with systemd versions around 229-3. I think one explanation might be that systemd started to send SIGHUP on top of SIGTERM (as outlined in https://bbs.archlinux.org/viewtopic.php?pid=1617469#p1617469).

SIGHUP is often used to tell processes to reload their configuration. The processes failing to shutdown properly are probably not handling correctly a reload operation during their exit sequence (chromium ?).

For example, conky has a bug in its signal handling scheme since Nov 2005 (ironically, the commit is called "fix signal processing"), and possibly before, but this bug is only triggered by a SIGHUP cancelling a previous SIGTERM. As this issue arose only recently and for many programs at the same time, it is reasonable to think that the spurious SIGHUP comes from systemd.

@wfhu
wfhu commented May 16, 2016

CentOS Linux release 7.2.1511 (Core)
3.10.0-327.4.4.el7.x86_64

systemd-sysv-219-19.el7.x86_64
systemd-libs-219-19.el7.x86_64
systemd-219-19.el7.x86_64

confirmed with this issue, I have to wait 20 minutes for xxx xxx

@Insomnium

+1 on Arch

@evverx
Member
evverx commented May 16, 2016

@layus

As this issue arose only recently and for many programs at the same time, it is reasonable to think that the spurious SIGHUP comes from systemd.

I think the spurious SIGHUP comes from the kernel.

Since the process group is orphaned when the parent terminates, and the process group contains a stopped process, POSIX.1 requires that every process in the newly orphaned process group be sent the hang-up signal (SIGHUP) followed by the continue signal (SIGCONT).

Try this:

# cat orphaned.c
#include <signal.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

static void sig_hup(int signo) {
    printf("SIGHUP received, pid = %ld\n", (long)getpid());
}

static void sig_term(int signo) {
    printf("SIGTERM received, pid = %ld\n", (long)getpid());
}

int main(int argc, char *argv[]) {
    pid_t pid;

    pid = fork();
    if (pid < 0)
        return 1;

    if (pid > 0) {
        sleep(5);
        return 0;
    }

    signal(SIGHUP, sig_hup);
    signal(SIGTERM, sig_term);
    setpgid(0, 0);
    kill(getpid(), SIGSTOP);
    printf("Heya!\n");

        return 0;
}

# make orphaned

#  cat <<EOL >/etc/systemd/system/orphaned.service
[Service]
Type=oneshot
ExecStart=$(realpath orphaned)
EOL

# systemctl start orphaned.service

# journalctl -u orphaned -b
-- Logs begin at Mon 2016-05-16 10:54:57 UTC, end at Mon 2016-05-16 14:39:59 UTC. --
May 16 14:39:52 ubuntu-xenial systemd[1]: orphaned.service: Collecting.
May 16 14:39:54 ubuntu-xenial systemd[21305]: orphaned.service: Executing: /home/ubuntu/orphaned
May 16 14:39:54 ubuntu-xenial systemd[1]: Starting orphaned.service...
May 16 14:39:59 ubuntu-xenial orphaned[21305]: SIGHUP received, pid = 21306
May 16 14:39:59 ubuntu-xenial orphaned[21305]: Heya!
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: Child 21305 belongs to orphaned.service
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: Main process exited, code=exited, status=0/SUCCESS
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: Changed start -> dead
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: Job orphaned.service/start finished, result=done
May 16 14:39:59 ubuntu-xenial systemd[1]: Started orphaned.service.
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: cgroup is empty
May 16 14:39:59 ubuntu-xenial systemd[1]: orphaned.service: Collecting.
@diegoviola

Isn't this solved already? See #2691

Or it's a different issue?

@diegoviola

@evverx Got it. I stopped seeing this issue after I switched to Firefox (from Chromium).

@layus
layus commented May 16, 2016

@evverx Thanks for explaining this. It seems that you are right, SIGHUP is sent by the kernel, not systemd. This is quite a relief regarding my programming skills, because I could not find the offending line in systemd codebase :-).

Meanwhile, the issue remains. While we know that applications mishandling signals are the real offenders here, we do not know why it started breaking around v229 of systemd, nor if systemd is responsible for the change of behavior.
Of course, the bug is in the applications themselves (apparently conky and chromium) but the fact is that that bug never revealed itself before, so something must have changed in between. What could it be ?

All I can think of is a change in the order in which applications are killed. Systemd is quite aggressive when killing all the processes. It sends SIGSTOP to everyone without trusting the process hierarchy to do its job. Or maybe a change in cgroups implementation by the kernel;

The strange thing is, I do not observe the "a stop job is running for..." message anymore, but systemd still indirectly waits for my running conky when trying to unmount /home, and so for 90 seconds.

@chadmiller

If

$ echo core |sudo tee /proc/sys/kernel/core_pattern

makes it not hang, then it's something funny. SIGHUP on chromium/chrome could cause a crash of some child, which causes systemd to run something when it's trying to shut down. I expect systemd to be more resilient, but perhaps there is some new edge case.

@diegoviola

I can confirm echo core |sudo tee /proc/sys/kernel/core_pattern makes it not hang when using Chromium.

@diegoviola

After I shutdown/reboot with /proc/sys/kernel/core_pattern being set to |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e it hangs again.

@chadmiller

@diegoviola
I think you should fabricate some shell script that writes its parameters to a file. Then change the core pattern to "|/usr/local/bin/diegos-systemd-shutdown-test %P %u %g %s %t %c %e"
(You see what to name the script now, yes?)

Steps:
Capture the results of "ps axwww" in a file.
Reboot to get the crash info logged to another file.
Look in the shutdown test output file. Compare the process listing. Paste results here.

@benjarobin
Contributor

This bug is not already solved in git ? See #2691 ?

@diegoviola

@chadmiller I've used this script:

#!/bin/bash

echo $1 >> /var/tmp/systemd-core-handler
echo $2 >> /var/tmp/systemd-core-handler
echo $3 >> /var/tmp/systemd-core-handler
echo $4 >> /var/tmp/systemd-core-handler
echo $5 >> /var/tmp/systemd-core-handler
echo $6 >> /var/tmp/systemd-core-handler
echo $7 >> /var/tmp/systemd-core-handler

ps axwww >> /var/tmp/systemd-core-handler

And here is the output:

675
1000
1000
6
1463430870
18446744073709551615
D-Bus
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /sbin/init
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:00 [ksoftirqd/0]
    4 ?        S      0:00 [kworker/0:0]
    5 ?        S<     0:00 [kworker/0:0H]
    6 ?        S      0:00 [kworker/u8:0]
    7 ?        S      0:00 [rcu_preempt]
    8 ?        S      0:00 [rcu_sched]
    9 ?        S      0:00 [rcu_bh]
   10 ?        S      0:00 [migration/0]
   11 ?        S      0:00 [watchdog/0]
   12 ?        S      0:00 [watchdog/1]
   13 ?        S      0:00 [migration/1]
   14 ?        S      0:00 [ksoftirqd/1]
   15 ?        S      0:00 [kworker/1:0]
   16 ?        S<     0:00 [kworker/1:0H]
   17 ?        S      0:00 [kdevtmpfs]
   18 ?        S<     0:00 [netns]
   19 ?        S      0:00 [khungtaskd]
   20 ?        S<     0:00 [writeback]
   21 ?        SN     0:00 [ksmd]
   22 ?        SN     0:00 [khugepaged]
   23 ?        S<     0:00 [crypto]
   24 ?        S<     0:00 [kintegrityd]
   25 ?        S<     0:00 [bioset]
   26 ?        S<     0:00 [kblockd]
   27 ?        S<     0:00 [devfreq_wq]
   28 ?        S      0:00 [kworker/0:1]
   29 ?        S      0:00 [kworker/1:1]
   30 ?        S      0:00 [kswapd0]
   31 ?        S<     0:00 [vmstat]
   40 ?        S<     0:00 [kthrotld]
   44 ?        S<     0:00 [ipv6_addrconf]
   45 ?        S<     0:00 [deferwq]
   46 ?        S      0:00 [kworker/u8:1]
   83 ?        S<     0:00 [ata_sff]
   84 ?        S      0:00 [kworker/0:2]
   85 ?        S      0:00 [scsi_eh_0]
   86 ?        S<     0:00 [scsi_tmf_0]
   87 ?        S      0:00 [scsi_eh_1]
   88 ?        S<     0:00 [scsi_tmf_1]
   89 ?        S      0:00 [kworker/u8:2]
   90 ?        S      0:00 [scsi_eh_2]
   91 ?        S<     0:00 [scsi_tmf_2]
   92 ?        S      0:00 [scsi_eh_3]
   93 ?        S<     0:00 [scsi_tmf_3]
   94 ?        S      0:00 [kworker/u8:3]
   95 ?        S      0:00 [kworker/u8:4]
   96 ?        S      0:00 [kworker/u8:5]
   97 ?        S      0:00 [kworker/1:2]
   98 ?        S      0:00 [kworker/1:3]
   99 ?        S      0:00 [kworker/1:4]
  100 ?        S<     0:00 [bioset]
  101 ?        S<     0:00 [bioset]
  103 ?        S<     0:00 [kworker/1:1H]
  104 ?        S<     0:00 [kworker/0:1H]
  125 ?        S      0:00 [jbd2/sda3-8]
  126 ?        S<     0:00 [ext4-rsv-conver]
  163 ?        Ss     0:00 /usr/lib/systemd/systemd-journald
  172 ?        S      0:00 [kworker/0:3]
  201 ?        Ss     0:00 /usr/lib/systemd/systemd-udevd
  217 ?        S<     0:00 [acpi_thermal_pm]
  224 ?        S<     0:00 [kvm-irqfd-clean]
  244 ?        Ssl    0:00 /usr/lib/systemd/systemd-timesyncd
  250 ?        Ss     0:00 /usr/lib/systemd/systemd-logind
  262 ?        S<     0:00 [cfg80211]
  265 ?        Ss     0:00 login -- diego
  341 tty1     Ds     0:00 -bash
  349 tty1     S+     0:00 /bin/sh /usr/bin/startx
  371 tty1     S+     0:00 xinit /home/diego/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.GHrIq7WPyC
  372 tty1     Z      0:01 [Xorg] <defunct>
  416 tty1     Z      0:00 [i3] <defunct>
  504 ?        Ds     0:00 -bash
  511 ?        Z      0:00 [weechat] <defunct>
  522 ?        Ds     0:00 -bash
  528 ?        S      0:00 su -
  530 ?        Z      0:00 [bash] <defunct>
  675 ?        Dl     0:09 /usr/lib/chromium/chromium
 1037 ?        Ds     0:00 -bash
 1356 ?        Ss     0:00 /bin/bash /usr/bin/mkinitcpio -A sd-shutdown -k none -c /dev/null -d /run/initramfs
 1361 ?        S      0:00 [kworker/0:4]
 1369 ?        S      0:00 [kworker/0:5]
 1402 ?        D      0:00 install -Dm755 /usr/lib/systemd/systemd-shutdown /run/initramfs/shutdown
 1403 ?        S      0:00 /bin/bash /root/diego-systemd-shutdown-test.sh 675 1000 1000 6 1463430870 18446744073709551615 D-Bus thread
 1404 ?        R      0:00 ps axwww

It doesn't hang with my script, but when |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e is set to /proc/sys/kernel/core_pattern it hangs every time.

So maybe it's just the same bug from #2691?

@diegoviola

@benjarobin I'm still on 229, I haven't tested git yet.

Can someone try and confirm please?

@layus
layus commented May 16, 2016

@evverx Some aspects are still very strange to me.
i3bar has conky as a child. During the exit sequence i3bar waitpid()'s on conky. So presumably this unchecked waitpid return EINTR and does not behave as expected, right ?
Don't you also think that these poor programs receive too many signals at once ?

@evverx
Member
evverx commented May 16, 2016

@layus

Don't you also think that these poor programs receive too many signals at once ?

Well, I don't know how your service works.
But you can reproduce that "many signals at once":

-bash-4.3# systemctl cat handle-and-stop --no-pager
# /etc/systemd/system/handle-and-stop.service
[Service]
ExecStart=/bin/bash -x -c 'trap "echo CONT" CONT; trap "echo TERM" TERM; trap "echo HUP" HUP; trap "echo USR1" USR1; trap "echo USR2" USR2; while :; do kill -STOP $$$$; done'

-bash-4.3# systemctl start handle-and-stop

-bash-4.3# main_pid=$(systemctl show --property=MainPID --value handle-and-stop)

-bash-4.3# for s in TERM HUP USR1 USR2; do kill -$s $main_pid; done

-bash-4.3# grep -i sigq /proc/$main_pid/status
SigQ:   4/7959

-bash-4.3# systemctl stop handle-and-stop
...HANGS...

-bash-4.3# journalctl -u handle-and-stop -b --no-hostname
May 16 22:40:02 systemd[1]: Started handle-and-stop.service.
May 16 22:40:02 bash[104]: + trap 'echo CONT' CONT
May 16 22:40:02 bash[104]: + trap 'echo TERM' TERM
May 16 22:40:02 bash[104]: + trap 'echo HUP' HUP
May 16 22:40:02 bash[104]: + trap 'echo USR1' USR1
May 16 22:40:02 bash[104]: + trap 'echo USR2' USR2
May 16 22:40:02 bash[104]: + :
May 16 22:40:02 bash[104]: + kill -STOP 104
May 16 22:40:02 systemd[1]: handle-and-stop.service: Failed to send unit change signal for handle-and-stop.service: Connection reset by peer
May 16 22:42:28 systemd[1]: handle-and-stop.service: Trying to enqueue job handle-and-stop.service/stop/replace
May 16 22:42:28 systemd[1]: handle-and-stop.service: Installed new job handle-and-stop.service/stop as 392
May 16 22:42:28 bash[104]: ++ echo HUP
May 16 22:42:28 bash[104]: HUP
May 16 22:42:28 bash[104]: ++ echo USR1
May 16 22:42:28 bash[104]: USR1
May 16 22:42:28 bash[104]: ++ echo USR2
May 16 22:42:28 bash[104]: USR2
May 16 22:42:28 bash[104]: ++ echo TERM
May 16 22:42:28 bash[104]: TERM
May 16 22:42:28 bash[104]: ++ echo CONT
May 16 22:42:28 bash[104]: CONT
May 16 22:42:28 bash[104]: + :
May 16 22:42:28 bash[104]: + kill -STOP 104
May 16 22:42:28 systemd[1]: handle-and-stop.service: Enqueued job handle-and-stop.service/stop as 392
May 16 22:42:28 systemd[1]: handle-and-stop.service: Changed running -> stop-sigterm
May 16 22:42:28 systemd[1]: Stopping handle-and-stop.service...
May 16 22:43:58 systemd[1]: handle-and-stop.service: State 'stop-sigterm' timed out. Killing.
May 16 22:43:58 systemd[1]: handle-and-stop.service: Changed stop-sigterm -> stop-sigkill
May 16 22:43:58 systemd[1]: handle-and-stop.service: Child 104 belongs to handle-and-stop.service
May 16 22:43:58 systemd[1]: handle-and-stop.service: Main process exited, code=killed, status=9/KILL
May 16 22:43:58 systemd[1]: handle-and-stop.service: Changed stop-sigkill -> failed
May 16 22:43:58 systemd[1]: handle-and-stop.service: Job handle-and-stop.service/stop finished, result=done
May 16 22:43:58 systemd[1]: Stopped handle-and-stop.service.
May 16 22:43:58 systemd[1]: handle-and-stop.service: Unit entered failed state.
May 16 22:43:58 systemd[1]: handle-and-stop.service: Failed with result 'signal'.
May 16 22:43:58 systemd[1]: handle-and-stop.service: cgroup is empty

Anyway, try to reproduce your problem and file a new issue.
Also consider contacting the systemd mailing list: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

@diegoviola

Can someone try and confirm please?

#2691 (comment)
#3148 (comment)

@Dawnflash
Dawnflash commented May 20, 2016 edited

Confirmed on Arch Linux, kernel 4.5.4., SystemD 229 with Cinnamon and Gnome DEs.
The issue is hard to track as no journal logs are made and TTYs are killed, so system is unmanageable at that point. Moreover it only occurs sporadically, reproduction at will seems impossible.
Also, the issue appears right after DBus daemon dies (not sure if relevant though).

@maher-hanna

I hava this problem also but it apeares only in kde desktop not in gnome.
Kernel 4.5.4 , Systemd 229

@startas
startas commented May 22, 2016

Ubuntu 16.04 also has this bug.

@egriffith

This bug is the same as: #2691 , no? If so, this is thought to be fixed as of v230 and should be closed as well.

@diegoviola
diegoviola commented Jun 5, 2016 edited

I'm still having this issue on Arch Linux (systemd 230-3) but I don't know if systemd-coredump is to blame or something else.

Anyone else?

@diegoviola

I was using Firefox this time, I simply typed poweroff and got the 90s timeout.

@Potomac
Potomac commented Jun 5, 2016 edited

@diegoviola : you can try to "mask" systemd-coredump@.service with systemd

systemctl mask systemd-coredump@.service

and then just create a file "/etc/sysctl.d/50-coredump.conf" with the following contents:

kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t

tested with archlinux 64 bits with success

@diegoviola

@Potomac Thanks, but I thought the issue was already fixed in v230?

@japhir
japhir commented Jun 6, 2016 edited

I'm running 230-3 on Arch and while the above fix has some effect, the issue is not resolved for me.

It used to be a 1:30 wait for /run/user/1000 to unmount or something similar, now I get a message saying that a stop job is running for tlp, but this doesn't hang for the full 1:30 but just for ~10 seconds. This might have become a different issue though.

@poettering
Member

I'll close this bug now. The coredump issue has been fixed, and this bug was mostly about that.

of course, timeouts may be hit due to a variety of causes during shutdown. For example @japhir's issue is probably within his "tlp" service.

As it doesn't make sense to track issues with such a variety of services in a single bug I will close this now. If the issue remains with specific services, and it is clear that this is not a bug in the individual service but in systemd, then please open new, separate bugs for that.

@poettering poettering closed this Jun 7, 2016
@diegoviola

I've just started using chromium again and I got the 90s timeout again, any ideas?

@benjarobin
Contributor

@diegoviola This bug report is closed, see poettering comment... And this is highly probable that the bug is inside chromium

@diegoviola

I can confirm that after disabling "Continue running background apps when Chromium is closed" under Chromium' System makes this issue go away.

@berndbb
berndbb commented Jun 12, 2016

I have found no reason why my shutdown once hangs like described here and then with another session the PC is shut down in only a few seconds -
but since I don't use Cromium I can't consider this the (only) reason. Maybe someone somewhere else finds a clue ...

@diegoviola

I've submitted this bug to chromium, if someone is interested to follow up here:

https://bugs.chromium.org/p/chromium/issues/detail?id=619418

Thanks.

@kilbith
kilbith commented Jun 19, 2016

I didn't bother to read the whole discussion, just want to inform that I suffer from the same bug with systemd 230 on archlinux :

Started generate shutdown-ramfs
A stop job is running for User Manager for UID 1000 (1min30)

In any case, 90s is way too long. I'm forced to brutally power-off my computer when it happens (quite oftenly the case).

@kyawthusoe3142

FYI, in my case, Debian Jessie and systemd 215, installing watchdog solved the problem.

@charleslouis

On fresh install of ubuntu 16.04 :

I had either a "a stop job is running for session c2 of user XYZ" /1min30 or a total hang when pressing ESC on shutdown/reboot splash screen.
Several tests showed that deactivating Private Internet Access VPN avoided being stuck at shutdown splash screen.

@kyawthusoe3142

Debian Jessie with backported systemd 230-7~bpo8+2, this bug is found, again.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822996

"A STOP JOB IS RUNNING FOR AVAHI MDNS/DNS/SD STACK"

It eventually completed. It occurred intermittently.

@smcv
Contributor
smcv commented Aug 1, 2016

this bug is found, again

No it isn't. The (vague) title of this bug is a symptom, not a cause. If you see the same symptom for a different reason, nothing that has been said on this bug is going to help you.

In your case, the stop job that is taking a long time is Avahi, which is not the same thing as any of the other shutdown hangs discussed on this bug.

@kyawthusoe3142

@smcv It didn't not always show, "A stop job is running for Avahi mDNS/DNS-SD Stack". It sometimes showed, "A stop job is running for session c2 of user ... (1min 30s).".

@nettlebay
nettlebay commented Jan 21, 2017 edited

Me too with Ubuntu 16.04. Seems to be caused by systemd. I installed Watchdog for a couple of days but I'm not sure what it does. It's better but not perfect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment