New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System hangs at reboot/shutdown - Arch Linux #1615

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

Comments

@prescott66
Contributor

prescott66 commented Oct 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@prescott66

prescott66 Oct 20, 2015

Contributor

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

Contributor

prescott66 commented Oct 20, 2015

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

@dvdhrm

This comment has been minimized.

Show comment
Hide comment
@dvdhrm

dvdhrm Oct 23, 2015

Member

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.

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.

@prescott66

This comment has been minimized.

Show comment
Hide comment
@prescott66
Contributor

prescott66 commented Oct 23, 2015

@elkrejzi

This comment has been minimized.

Show comment
Hide comment
@elkrejzi

elkrejzi Jan 22, 2016

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.

Contributor

elkrejzi commented Jan 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Potomac

Potomac 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

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

This comment has been minimized.

Show comment
Hide comment
@ongun-kanat

ongun-kanat Feb 26, 2016

Same as @Potomac here. Ver. 229-3

ongun-kanat commented Feb 26, 2016

Same as @Potomac here. Ver. 229-3

@diegoviola

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola Mar 1, 2016

Same problem here on systemd 229 (archlinux)

diegoviola commented Mar 1, 2016

Same problem here on systemd 229 (archlinux)

@nagyf

This comment has been minimized.

Show comment
Hide comment
@nagyf

nagyf Mar 10, 2016

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

nagyf commented Mar 10, 2016

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

@ongun-kanat

This comment has been minimized.

Show comment
Hide comment
@ongun-kanat

ongun-kanat Mar 11, 2016

@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.

ongun-kanat commented Mar 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost 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.

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

This comment has been minimized.

Show comment
Hide comment
@meradoou

meradoou Mar 12, 2016

I have same problem on Archlinux

meradoou commented Mar 12, 2016

I have same problem on Archlinux

@M-Tarasov

This comment has been minimized.

Show comment
Hide comment
@M-Tarasov

M-Tarasov Mar 12, 2016

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

M-Tarasov commented Mar 12, 2016

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

@varlesh

This comment has been minimized.

Show comment
Hide comment
@varlesh

varlesh Mar 13, 2016

Confirm this

varlesh commented Mar 13, 2016

Confirm this

@cross1983

This comment has been minimized.

Show comment
Hide comment
@cross1983

cross1983 Mar 13, 2016

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

cross1983 commented Mar 13, 2016

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

@manjarqo

This comment has been minimized.

Show comment
Hide comment
@manjarqo

manjarqo Mar 13, 2016

I confirm the issue too

manjarqo commented Mar 13, 2016

I confirm the issue too

@virpool

This comment has been minimized.

Show comment
Hide comment
@virpool

virpool Mar 13, 2016

Confirm this issue too.

virpool commented Mar 13, 2016

Confirm this issue too.

@lynxthecat

This comment has been minimized.

Show comment
Hide comment
@lynxthecat

lynxthecat Mar 16, 2016

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

lynxthecat commented Mar 16, 2016

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

@GeorgeTG

This comment has been minimized.

Show comment
Hide comment
@GeorgeTG

GeorgeTG Mar 16, 2016

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 ?

GeorgeTG commented Mar 16, 2016

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 ?

@bunkbail

This comment has been minimized.

Show comment
Hide comment
@bunkbail

bunkbail Mar 24, 2016

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.

bunkbail commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hexagonal-sun

hexagonal-sun Mar 26, 2016

+1 on Arch Linux.

hexagonal-sun commented Mar 26, 2016

+1 on Arch Linux.

@firekage

This comment has been minimized.

Show comment
Hide comment
@firekage

firekage Mar 27, 2016

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.

firekage commented Mar 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@benjarobin

benjarobin Mar 28, 2016

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

Contributor

benjarobin commented Mar 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Potomac

Potomac 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

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

This comment has been minimized.

Show comment
Hide comment
@bakteria1

bakteria1 Apr 3, 2016

Same issue here

bakteria1 commented Apr 3, 2016

Same issue here

@Potomac

This comment has been minimized.

Show comment
Hide comment
@Potomac

Potomac 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 )

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

This comment has been minimized.

Show comment
Hide comment
@varlesh

varlesh 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.

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

This comment has been minimized.

Show comment
Hide comment
@adeleglise

adeleglise Apr 9, 2016

Hi all,
I'm facing the same issue.

adeleglise commented Apr 9, 2016

Hi all,
I'm facing the same issue.

@molecularresearcher

This comment has been minimized.

Show comment
Hide comment
@molecularresearcher

molecularresearcher Apr 10, 2016

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

molecularresearcher commented Apr 10, 2016

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

@kyawthusoe45

This comment has been minimized.

Show comment
Hide comment
@kyawthusoe45

kyawthusoe45 Apr 12, 2016

Systemd 215-17, Debian Jessie: confirm this.

kyawthusoe45 commented Apr 12, 2016

Systemd 215-17, Debian Jessie: confirm this.

@layus

This comment has been minimized.

Show comment
Hide comment
@layus

layus 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.

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

This comment has been minimized.

Show comment
Hide comment
@wfhu

wfhu 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

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

This comment has been minimized.

Show comment
Hide comment
@Insomnium

Insomnium May 16, 2016

+1 on Arch

Insomnium commented May 16, 2016

+1 on Arch

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx May 16, 2016

Member

@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.
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

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola May 16, 2016

Isn't this solved already? See #2691

Or it's a different issue?

diegoviola commented May 16, 2016

Isn't this solved already? See #2691

Or it's a different issue?

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx
Member

evverx commented May 16, 2016

@diegoviola

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola May 16, 2016

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

diegoviola commented May 16, 2016

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

@layus

This comment has been minimized.

Show comment
Hide comment
@layus

layus 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.

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

This comment has been minimized.

Show comment
Hide comment
@chadmiller

chadmiller May 16, 2016

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.

chadmiller commented May 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola May 16, 2016

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

diegoviola commented May 16, 2016

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

@benjarobin

This comment has been minimized.

Show comment
Hide comment
@benjarobin

benjarobin Jun 8, 2016

Contributor

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

Contributor

benjarobin commented Jun 8, 2016

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

@diegoviola

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola Jun 12, 2016

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

diegoviola commented Jun 12, 2016

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

@berndbb

This comment has been minimized.

Show comment
Hide comment
@berndbb

berndbb 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 ...

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

This comment has been minimized.

Show comment
Hide comment
@diegoviola

diegoviola Jun 12, 2016

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.

diegoviola commented Jun 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kilbith

kilbith 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).

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).

@kyawthusoe45

This comment has been minimized.

Show comment
Hide comment
@kyawthusoe45

kyawthusoe45 Jun 19, 2016

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

kyawthusoe45 commented Jun 19, 2016

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

@charleslouis

This comment has been minimized.

Show comment
Hide comment
@charleslouis

charleslouis Jul 19, 2016

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.

charleslouis commented Jul 19, 2016

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.

@kyawthusoe45

This comment has been minimized.

Show comment
Hide comment
@kyawthusoe45

kyawthusoe45 Aug 1, 2016

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.

kyawthusoe45 commented Aug 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@smcv

smcv Aug 1, 2016

Contributor

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.

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.

@kyawthusoe45

This comment has been minimized.

Show comment
Hide comment
@kyawthusoe45

kyawthusoe45 Aug 2, 2016

@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).".

kyawthusoe45 commented Aug 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nettlebay

nettlebay Jan 21, 2017

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.

nettlebay commented Jan 21, 2017

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.

@CottonEaster

This comment has been minimized.

Show comment
Hide comment
@CottonEaster

CottonEaster May 7, 2017

I have this problem with Mint 18.1. It's driving me crazy. I've tried all sorts of workaround and none of them - at least fully - work. For I still have the problem, at least when using ethernet as against wifi. The problem means I have to hard reset my machine, which can't be good for it. This problem takes us back to the bad old days of Linux when basically nothing worked without hacks and prayer.

EDIT: It seems no-one is assigned to this bug. Why?

CottonEaster commented May 7, 2017

I have this problem with Mint 18.1. It's driving me crazy. I've tried all sorts of workaround and none of them - at least fully - work. For I still have the problem, at least when using ethernet as against wifi. The problem means I have to hard reset my machine, which can't be good for it. This problem takes us back to the bad old days of Linux when basically nothing worked without hacks and prayer.

EDIT: It seems no-one is assigned to this bug. Why?

@grossws

This comment has been minimized.

Show comment
Hide comment
@grossws

grossws May 30, 2017

I have similar issue on ArchLinux (linux 4.11.2-1-ARCH, systemd 232-8, plamsa-desktop 5.9.5-1, sddm 0.14.0-2).

It seems that either kded5 or sddm is an offending process. On shutdown sequence sddm tries to stop both X server and plasma/kde (which is run under sddm-helper) and X stops before kded5 which somehow leads to latter to ignore SIGTERM.

May 30 00:35:05 wahnsinn sddm[687]: Display server stopping...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Starting...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Authenticating...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] returning.
May 30 00:35:05 wahnsinn systemd[1]: Stopped Manage swap spaces on zram, files and partitions..
May 30 00:35:07 wahnsinn sddm[687]: Display server stopped.
May 30 00:35:07 wahnsinn sddm[687]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
May 30 00:35:07 wahnsinn sddm[687]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
May 30 00:35:07 wahnsinn systemd[1]: Stopped Simple Desktop Display Manager.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Stopping timed out. Killing.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Killing process 1373 (kded5) with signal SIGKILL.
May 30 00:36:32 wahnsinn systemd[1]: Stopped Session c2 of user gross.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Unit entered failed state.

See also FS#46585 (Arch bugtracker)

grossws commented May 30, 2017

I have similar issue on ArchLinux (linux 4.11.2-1-ARCH, systemd 232-8, plamsa-desktop 5.9.5-1, sddm 0.14.0-2).

It seems that either kded5 or sddm is an offending process. On shutdown sequence sddm tries to stop both X server and plasma/kde (which is run under sddm-helper) and X stops before kded5 which somehow leads to latter to ignore SIGTERM.

May 30 00:35:05 wahnsinn sddm[687]: Display server stopping...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Starting...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Authenticating...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] returning.
May 30 00:35:05 wahnsinn systemd[1]: Stopped Manage swap spaces on zram, files and partitions..
May 30 00:35:07 wahnsinn sddm[687]: Display server stopped.
May 30 00:35:07 wahnsinn sddm[687]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
May 30 00:35:07 wahnsinn sddm[687]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
May 30 00:35:07 wahnsinn systemd[1]: Stopped Simple Desktop Display Manager.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Stopping timed out. Killing.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Killing process 1373 (kded5) with signal SIGKILL.
May 30 00:36:32 wahnsinn systemd[1]: Stopped Session c2 of user gross.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Unit entered failed state.

See also FS#46585 (Arch bugtracker)

@osho741

This comment has been minimized.

Show comment
Hide comment
@osho741

osho741 May 30, 2017

My system with Openbox/Tint2 on kernel 4.11.2-1_ARCH just freezes when doing reboot from terminal. If I roll back to 4.10.17 it is able to reboot fine.

osho741 commented May 30, 2017

My system with Openbox/Tint2 on kernel 4.11.2-1_ARCH just freezes when doing reboot from terminal. If I roll back to 4.10.17 it is able to reboot fine.

@smcv

This comment has been minimized.

Show comment
Hide comment
@smcv

smcv May 30, 2017

Contributor

There are many reasons why a system might hang during reboot/shutdown. It is a symptom, not a cause. If you do not have evidence that the root cause of your system hang is the same as the root cause of the system hang experienced by the initial reporter of this issue, then please do not reply to this issue.

If you see the same symptom for a different reason, then nothing that has been said on this issue report is going to help you, and anything you say on this issue report is just going to make it even more confusing to a reader.

Please contact your distribution vendor (Arch Linux, Ubuntu/Canonical, Mint, etc.) for initial support. If you have evidence that your issue is caused by systemd (not to be confused with a bug merely involving systemd) then you can report that as a separate bug, with a more specific description based on that evidence.

For example, the details provided by @grossws seem to indicate a bug in either kded5, sddm, or the systemd units provided with sddm. That is probably not a bug in systemd and will probably not be fixed by changing systemd, so this is the wrong place to ask for a solution.

It seems no-one is assigned to this bug. Why?

Here are some reasons why assigning a developer to work on this issue would be counterproductive:

  1. Because the issue was closed in 2016. Closed issues are not worked on. If you have evidence of a bug in systemd, please open a new issue to represent it, with a more specific title and description than this one, and do not mix it up with everything else that has been said in this thread.

  2. Because there does not seem to be any particular evidence that any of the various problems that different people are experiencing are bugs in systemd, as opposed to bugs in particular services that they are running. Bugs in pieces of software outside systemd are not solved by changing systemd, they are solved by changing the other piece of software.

  3. Because even if some or all of the problems reported in this comment thread were caused by bugs in systemd, no single volunteer is going to want to take responsibility for fixing a series of different bugs (some of which might be bugs in systemd, some of which are almost certainly not) that are getting mixed into this issue thread. That would be an endless task - by the time one had been solved, another would likely have been reported, because the title of this issue thread is so general that it could describe all sorts of different root causes. Again, if you have evidence of a bug in systemd, please open a new issue to represent it, and do not mix it up with everything else that has been said in this thread.

Contributor

smcv commented May 30, 2017

There are many reasons why a system might hang during reboot/shutdown. It is a symptom, not a cause. If you do not have evidence that the root cause of your system hang is the same as the root cause of the system hang experienced by the initial reporter of this issue, then please do not reply to this issue.

If you see the same symptom for a different reason, then nothing that has been said on this issue report is going to help you, and anything you say on this issue report is just going to make it even more confusing to a reader.

Please contact your distribution vendor (Arch Linux, Ubuntu/Canonical, Mint, etc.) for initial support. If you have evidence that your issue is caused by systemd (not to be confused with a bug merely involving systemd) then you can report that as a separate bug, with a more specific description based on that evidence.

For example, the details provided by @grossws seem to indicate a bug in either kded5, sddm, or the systemd units provided with sddm. That is probably not a bug in systemd and will probably not be fixed by changing systemd, so this is the wrong place to ask for a solution.

It seems no-one is assigned to this bug. Why?

Here are some reasons why assigning a developer to work on this issue would be counterproductive:

  1. Because the issue was closed in 2016. Closed issues are not worked on. If you have evidence of a bug in systemd, please open a new issue to represent it, with a more specific title and description than this one, and do not mix it up with everything else that has been said in this thread.

  2. Because there does not seem to be any particular evidence that any of the various problems that different people are experiencing are bugs in systemd, as opposed to bugs in particular services that they are running. Bugs in pieces of software outside systemd are not solved by changing systemd, they are solved by changing the other piece of software.

  3. Because even if some or all of the problems reported in this comment thread were caused by bugs in systemd, no single volunteer is going to want to take responsibility for fixing a series of different bugs (some of which might be bugs in systemd, some of which are almost certainly not) that are getting mixed into this issue thread. That would be an endless task - by the time one had been solved, another would likely have been reported, because the title of this issue thread is so general that it could describe all sorts of different root causes. Again, if you have evidence of a bug in systemd, please open a new issue to represent it, and do not mix it up with everything else that has been said in this thread.

@CottonEaster

This comment has been minimized.

Show comment
Hide comment
@CottonEaster

CottonEaster May 30, 2017

Dear @smcv

  • Thank you for your explanations.

  • A combination of several bits of hackery seem to have solved the problem for me. If the problem recurrs I will open a new bug report.

  • It seems to me that (contrary to your point 2) the number of contributions of this thread is prima facie evidence of a problem - perhaps qua full-blown bug, perhaps qua something that is encouraging software writers to code their services wrongly - with systemd.

CottonEaster commented May 30, 2017

Dear @smcv

  • Thank you for your explanations.

  • A combination of several bits of hackery seem to have solved the problem for me. If the problem recurrs I will open a new bug report.

  • It seems to me that (contrary to your point 2) the number of contributions of this thread is prima facie evidence of a problem - perhaps qua full-blown bug, perhaps qua something that is encouraging software writers to code their services wrongly - with systemd.

@audiomuze

This comment has been minimized.

Show comment
Hide comment
@audiomuze

audiomuze Jul 3, 2017

got the same thing happening here, every time shut down my laptop. Running Arch 4.11.7-1-ARCH

audiomuze commented Jul 3, 2017

got the same thing happening here, every time shut down my laptop. Running Arch 4.11.7-1-ARCH

@smcv

This comment has been minimized.

Show comment
Hide comment
@smcv

smcv Jul 3, 2017

Contributor

@audiomuze Please contact your distribution vendor (in your case Arch Linux?) for initial support. If there is evidence that your issue is caused by systemd (and not a result of a bug in some other component), please open a separate bug report with full details of the symptoms and evidence, including relevant log messages and version numbers.

The title of this issue is a symptom, not a cause; there are many things that could be causing it (some of them would be systemd bugs, and some of them would not). If everyone whose system hangs during shutdown keeps adding comments to this closed issue report, then we are never going to be able to disentangle which bug reporter was suffering that symptom as a result of which root cause.

@poettering, perhaps it would be worthwhile to close the comments on this issue?

Contributor

smcv commented Jul 3, 2017

@audiomuze Please contact your distribution vendor (in your case Arch Linux?) for initial support. If there is evidence that your issue is caused by systemd (and not a result of a bug in some other component), please open a separate bug report with full details of the symptoms and evidence, including relevant log messages and version numbers.

The title of this issue is a symptom, not a cause; there are many things that could be causing it (some of them would be systemd bugs, and some of them would not). If everyone whose system hangs during shutdown keeps adding comments to this closed issue report, then we are never going to be able to disentangle which bug reporter was suffering that symptom as a result of which root cause.

@poettering, perhaps it would be worthwhile to close the comments on this issue?

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jul 3, 2017

Member

@poettering, perhaps it would be worthwhile to close the comments on this issue?

Uh, I am a bit afraid of the reddit firestorm this would likely result in...

Member

poettering commented Jul 3, 2017

@poettering, perhaps it would be worthwhile to close the comments on this issue?

Uh, I am a bit afraid of the reddit firestorm this would likely result in...

juhaerk added a commit to puavo-org/puavo-os that referenced this issue Oct 23, 2017

Revert the gdm.service timeout change, it does not solve
the problem of slow shutdowns, even though Xorg is one possible
culprit (systemd/systemd#1615).

This reverts commits b2d25eb
and a71d7cd.

juhaerk added a commit to puavo-org/puavo-os that referenced this issue Oct 23, 2017

Change DefaultTimeoutStopSec in /etc/systemd/system.conf from 90
seconds to 8 seconds.  Xorg is one of the (many?) processes
that may sometimes get confused when receiving HUP and TERM
close to each other, and does not die until KILL, slowing shut down.
See systemd/systemd#1615 for description.
Closes #264.
@ElLocoNutz

This comment has been minimized.

Show comment
Hide comment
@ElLocoNutz

ElLocoNutz Nov 6, 2017

@smcv So basically you hear hoofbeats and think zebras

ElLocoNutz commented Nov 6, 2017

@smcv So basically you hear hoofbeats and think zebras

@adrinjalali

This comment has been minimized.

Show comment
Hide comment
@adrinjalali

adrinjalali Dec 12, 2017

@smcv If several people, many of whome are tech-savy enough to have installed and working with archlinux, and wait and read the message they see on their screen, and then come back and search for the issue tying to report/fix/help in that regard, are commenting on the same issue here because of the same "symptom" they observe, maybe you should open an issue for your piece of software to give a more helpful message.

adrinjalali commented Dec 12, 2017

@smcv If several people, many of whome are tech-savy enough to have installed and working with archlinux, and wait and read the message they see on their screen, and then come back and search for the issue tying to report/fix/help in that regard, are commenting on the same issue here because of the same "symptom" they observe, maybe you should open an issue for your piece of software to give a more helpful message.

@tsdh

This comment has been minimized.

Show comment
Hide comment
@tsdh

tsdh Dec 13, 2017

Same problem on a current Arch laptop (since ages, I think), i.e., it is waiting for a stop job of User Manager for UID 1000 (which is my user). But now I had the time to debug the issue. After my user (with uid 1000) logged out, I checked systemd-cgls and there's still

│ └─user-1000.slice
│   └─user@1000.service
│     ├─init.scope
│     │ ├─2140 /usr/lib/systemd/systemd --user
│     │ └─2141 (sd-pam)
│     └─tracker-store.service
│       └─2471 /usr/lib/tracker/tracker-store

So do I see it correctly that in my case, GNOME's desktop search (Tracker) is the faulty process which doesn't properly terminate when being sent a SIGTERM followed by a SIGHUP and I should report a bug for that?

tsdh commented Dec 13, 2017

Same problem on a current Arch laptop (since ages, I think), i.e., it is waiting for a stop job of User Manager for UID 1000 (which is my user). But now I had the time to debug the issue. After my user (with uid 1000) logged out, I checked systemd-cgls and there's still

│ └─user-1000.slice
│   └─user@1000.service
│     ├─init.scope
│     │ ├─2140 /usr/lib/systemd/systemd --user
│     │ └─2141 (sd-pam)
│     └─tracker-store.service
│       └─2471 /usr/lib/tracker/tracker-store

So do I see it correctly that in my case, GNOME's desktop search (Tracker) is the faulty process which doesn't properly terminate when being sent a SIGTERM followed by a SIGHUP and I should report a bug for that?

@silliwretep

This comment has been minimized.

Show comment
Hide comment
@silliwretep

silliwretep Dec 13, 2017

This is caused by a kernel driver failing on shutdown.
The culprit can be found by methodically using modprobe -r to remove a specific driver and then shutting down.
If removing that driver before shutdown allows the system to proceed normally, that driver is likely the culprit.

If you have custom drivers on the system, the shutdown script for that driver system should contain lines to modprobe -r the drivers used prior to shutdown or reboot. This ensures the bad driver is unloaded before shutdown.

It may be good to somehow get test of what driver is currently being closed/called for debug purposes. Anyone know if that possible with kernel debugging enabled?

silliwretep commented Dec 13, 2017

This is caused by a kernel driver failing on shutdown.
The culprit can be found by methodically using modprobe -r to remove a specific driver and then shutting down.
If removing that driver before shutdown allows the system to proceed normally, that driver is likely the culprit.

If you have custom drivers on the system, the shutdown script for that driver system should contain lines to modprobe -r the drivers used prior to shutdown or reboot. This ensures the bad driver is unloaded before shutdown.

It may be good to somehow get test of what driver is currently being closed/called for debug purposes. Anyone know if that possible with kernel debugging enabled?

@kareliot

This comment has been minimized.

Show comment
Hide comment
@kareliot

kareliot Jan 17, 2018

@tsdh thanks for this. I have the exact same thing showing up when running systemd-cgls after logging out with user uid 1000.
So tracker does seem to cause the problem. Have you found out anything else?

kareliot commented Jan 17, 2018

@tsdh thanks for this. I have the exact same thing showing up when running systemd-cgls after logging out with user uid 1000.
So tracker does seem to cause the problem. Have you found out anything else?

@tsdh

This comment has been minimized.

Show comment
Hide comment
@tsdh

tsdh Jan 26, 2018

@kareliot Nope, nothing new from my side. Didn't have the time to debug any more, and since the issue is just on one machine, it hasn't bothered me enough.

tsdh commented Jan 26, 2018

@kareliot Nope, nothing new from my side. Didn't have the time to debug any more, and since the issue is just on one machine, it hasn't bothered me enough.

@ulises-jeremias

This comment has been minimized.

Show comment
Hide comment
@ulises-jeremias

ulises-jeremias Feb 8, 2018

I have same problem on Archlinux

ulises-jeremias commented Feb 8, 2018

I have same problem on Archlinux

@kareliot

This comment has been minimized.

Show comment
Hide comment
@kareliot

kareliot Feb 8, 2018

I have opened a bug report about the tracker.store.system issue in the gnome bug tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=793027#c2
Someone has already started debugging, but I have not had time to see if I can reproduce their findings.

kareliot commented Feb 8, 2018

I have opened a bug report about the tracker.store.system issue in the gnome bug tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=793027#c2
Someone has already started debugging, but I have not had time to see if I can reproduce their findings.

@CottonEaster

This comment has been minimized.

Show comment
Hide comment
@CottonEaster

CottonEaster Mar 24, 2018

I have the same problem - but on Linux Mint.

CottonEaster commented Mar 24, 2018

I have the same problem - but on Linux Mint.

@stueja

This comment has been minimized.

Show comment
Hide comment
@stueja

stueja Apr 25, 2018

For me (Arch Linux, Gnome desktop) the issue resolves whenever I deactivate Settings > Sharing > Remote Login. Hope that helps?

stueja commented Apr 25, 2018

For me (Arch Linux, Gnome desktop) the issue resolves whenever I deactivate Settings > Sharing > Remote Login. Hope that helps?

@CottonEaster

This comment has been minimized.

Show comment
Hide comment
@CottonEaster

CottonEaster Apr 25, 2018

Thanks stueja, but my own workaround is to allow my Internet connection to persist after log off.

CottonEaster commented Apr 25, 2018

Thanks stueja, but my own workaround is to allow my Internet connection to persist after log off.

@kevinxucs

This comment has been minimized.

Show comment
Hide comment
@kevinxucs

kevinxucs May 25, 2018

Still happens on Debian Testing

kevinxucs commented May 25, 2018

Still happens on Debian Testing

@FabianInostroza

This comment has been minimized.

Show comment
Hide comment
@FabianInostroza

FabianInostroza Jun 2, 2018

@kevinxucs It seems to be related to dleyna-renderer, I found the following on my shutdown log:

jun 02 04:34:29 debian systemd[1862]: dbus.service: State 'stop-final-sigterm' timed out. Killing.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14329 (dleyna-renderer) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14330 (gmain) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Failed with result 'timeout'.

Also found the following bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868951
intel/dleyna-renderer#164

You could try to uninstall dleyna-renderer and see if the problem goes away.

EDIT: at shutdown the message shown in screen is "Stopping User Manager for...", the message "Stopped User Manager..." is shown after systemd kills dleyna-renderer.

FabianInostroza commented Jun 2, 2018

@kevinxucs It seems to be related to dleyna-renderer, I found the following on my shutdown log:

jun 02 04:34:29 debian systemd[1862]: dbus.service: State 'stop-final-sigterm' timed out. Killing.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14329 (dleyna-renderer) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14330 (gmain) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Failed with result 'timeout'.

Also found the following bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868951
intel/dleyna-renderer#164

You could try to uninstall dleyna-renderer and see if the problem goes away.

EDIT: at shutdown the message shown in screen is "Stopping User Manager for...", the message "Stopped User Manager..." is shown after systemd kills dleyna-renderer.

@kevinxucs

This comment has been minimized.

Show comment
Hide comment
@kevinxucs

kevinxucs Jun 2, 2018

@FabianInostroza Thanks for pointing me the bug, but I am not sure I have dleyna-render installed.

The solution for me is to switch from gdm to lightdm, so I guess something related with gdm for my case

kevinxucs commented Jun 2, 2018

@FabianInostroza Thanks for pointing me the bug, but I am not sure I have dleyna-render installed.

The solution for me is to switch from gdm to lightdm, so I guess something related with gdm for my case

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