You are not logged in.

#26 2015-10-11 02:31:29

nstgc
Member
Registered: 2014-03-17
Posts: 393

Re: Problems with latest systemd 226-3

WorMzy wrote:

How are you all starting your sessions? Via a login manager (which one?), or TTY?

My computer starts up in a getty, which I then log into. I start my VPN with a script, change to TTY2, log in, and startx. That's typically how it goes unless i have some sort of maintenance script to run in which case I run tmux first, then the script.

berbae wrote:

@nstgc
Your problem is definitely different, because "zombie" processes cannot be killed with the killall command.
All messages 'Failed unmounting /home' have not the same origins.

If c1 session scope closes, that's something outside the session which keeps /home busy.
Did you try 'fuser -m /home' to list what processes still use the file system?

BTW you can remove the 'shutdown' hook, because there is the default 'sd-shutdown' hook which is then automatically run.

Adding the "shutdown" hook, for the most part, fixed my problem. Previously I had

HOOKS="base udev autodetect modconf block bcache filesystems keyboard"

then

HOOKS="base udev autodetect modconf block bcache filesystems keyboard shutdown"

and now I have

HOOKS="base systemd autodetect modconf block bcache filesystems keyboard"

That third one doesn't seem to work any better than the second by the way. In anycase, c1 still fails to stop sometimes. Usually it isn't accompanied a failure to unmount.

I'll try teh bit with fuser here in a bit.

Edit: Fuser showed nothing, but the subvolume still failed to unmount. C1 seems to have stopped, but I won't know until I check the journal tomorrow after fsck'ing and scrubbing. I was watching YouTube videos in Chromium by the way.

Last edited by nstgc (2015-10-11 02:41:59)

Offline

#27 2015-10-11 07:52:58

boban_dj
Member
Registered: 2015-03-17
Posts: 150

Re: Problems with latest systemd 226-3

WorMzy wrote:

How are you all starting your sessions? Via a login manager (which one?), or TTY?

Before I started with lightdm, but when i was trying to find the reason for the delay with the session scope, uninstalled lightdm, now start from .xinit directly to a cached xfce4/i3 session.
It seems it is not happening as often without lightdm enclosing the startup session, but this i cannot confirm 100%.
Until now (from tty) when closing google-chrome with multiple tabs open, and immediate shutdown (systemctl poweroff -i) or with xfce4 panel btn shutdown, it triggers the delay 90s.
I did not catch any other program so far to trigger the shutdown delay.
It seems indeed as

berbae wrote:

The problem comes when applis, like chrome or chromium/chromium-pepper-flash and others, do not act in this way to finish running.
Will their devs be opened to changed that? I don't know.

Thanks berbae for the /etc/systemd/system.conf file tip. I didn't know this, but will use it for now.

Offline

#28 2015-10-12 13:44:48

andrekp
Member
Registered: 2012-06-07
Posts: 112

Re: Problems with latest systemd 226-3

WorMzy wrote:

How are you all starting your sessions? Via a login manager (which one?), or TTY?

In my case, I am using SLiM to start an Openbox session.

FYI, and I'm not sure there's any relation, but this weekend I discovered that I can no longer SSH into my server from this Arch install.  I can do it from other computers, and I can do it from another Linux instance (same IP address) on this computer.  THIS Arch just stopped having the ability.  I use key authentication and the problem appears to be that my key is not recognized on the server side.  The keys are in their usual places (I even tried changing them for a test).  It's more like running SSH is not picking up the key and using it.  Since I used it two days earlier with no issues, and NOTHING has been changed or updated on this box (since we've been talking about THIS THREAD'S problem), I can't help but wonder if the problem might be somehow related.  I know that seems strange, but since we don't really know what's happening here, and NOTHING on this box has been changed...?

Offline

#29 2015-10-12 13:51:14

berbae
Member
From: France
Registered: 2007-02-12
Posts: 1,302

Re: Problems with latest systemd 226-3

nstgc wrote:

In anycase, c1 still fails to stop sometimes. Usually it isn't accompanied a failure to unmount.

That shows that there is something left unclean in the session scope sometimes, but systemd still can shutdown normally after a delay.

Fuser showed nothing, but the subvolume still failed to unmount. C1 seems to have stopped ... I was watching YouTube videos in Chromium by the way.

When you run the fuser command after the failure to unmount, the delay to clean remaining things in the scope has passed and so you see nothing.
If you were viewing videos with chromium-pepper-flash, you are in the same case as in my preceding posts; the only thing to do presently is to reduce the delay in /etc/systemd/system.conf file.
But some other applis could be responsible for the shutdown problem, not only Chrome.
It would be interesting to build a list of applis not quitting cleanly.
Has someone another example of an appli responsible for an delay in the shutdown sequence?

Offline

#30 2015-10-12 14:04:47

berbae
Member
From: France
Registered: 2007-02-12
Posts: 1,302

Re: Problems with latest systemd 226-3

@andrekp
You say you changed nothing, but have you reduce the systemd timeout delay?
If yes, maybe it is too short now, because it is used elsewhere also, not only at shutdown.

But it could be another cause and an coincidence that it happens now, I don't know.
What you describe seems unrelated to the subject of this thread.

Offline

#31 2015-10-12 16:51:56

nstgc
Member
Registered: 2014-03-17
Posts: 393

Re: Problems with latest systemd 226-3

berbae wrote:

Fuser showed nothing, but the subvolume still failed to unmount. C1 seems to have stopped ... I was watching YouTube videos in Chromium by the way.

When you run the fuser command after the failure to unmount, the delay to clean remaining things in the scope has passed and so you see nothing.

No, I ran fuser before the failure, not after.

If you were viewing videos with chromium-pepper-flash, you are in the same case as in my preceding posts; the only thing to do presently is to reduce the delay in /etc/systemd/system.conf file.

The session closes almost instantly almost all the time. Changing the delay won't help. My complaint has the do with the failure to unmount.

But some other applis could be responsible for the shutdown problem, not only Chrome.
It would be interesting to build a list of applis not quitting cleanly.
Has someone another example of an appli responsible for an delay in the shutdown sequence?

Is there some other way to find out what the zombie process is? Would "ps aux |grep Z" work better? I'll try that next time, but I'm not overly eager to reproduce this particular error. I'll wait util I've done something to trigger it, and then try. I'm not one for playing Russian Roulette with my data without another reason.

Offline

#32 2015-10-12 17:07:33

Serge2702
Member
From: México City
Registered: 2014-01-14
Posts: 73

Re: Problems with latest systemd 226-3

Apparently, I have this same issue, but with a different cause. I always run conky with output to ncurses in a tab in Guake. If I don't kill conky's process I have this 90 second delay at shutdown. I got a shutdown log following these instructions http://freedesktop.org/wiki/Software/sy … eventually.

The relevant part is this:

[  211.598648] systemd[1]: session-c2.scope: Stopping timed out. Killing.
[  211.599409] systemd[1]: session-c2.scope changed stop-sigterm -> stop-sigkill
[  211.599453] systemd[1]: Received SIGCHLD from PID 1091 (conky).
[  211.599471] systemd[1]: Child 1091 (conky) died (code=killed, status=9/KILL)
[  211.599496] systemd[1]: session-c2.scope: Child 1091 belongs to session-c2.scope
[  211.599543] systemd[1]: session-c2.scope: cgroup is empty
[  211.599549] systemd[1]: session-c2.scope changed stop-sigkill -> failed
[  211.599634] systemd[1]: session-c2.scope: Job session-c2.scope/stop finished, result=done
[  211.599646] systemd[1]: Stopped Session c2 of user sergio.

EDIT: I forgot to mention that this is consistent. This only happens iff I don't kill conky. If I close guake conky continues to run in the background and this problem appears.

Last edited by Serge2702 (2015-10-12 17:11:45)

Offline

#33 2015-10-12 19:52:07

nstgc
Member
Registered: 2014-03-17
Posts: 393

Re: Problems with latest systemd 226-3

I shutdown my computer after watching a Youtube video in Chromium, but everything shutdown perfectly. I checked the journal just to be sure, but everything was fine. For me, Youtube doesn't seem to be the issue.

Offline

#34 2015-10-12 21:07:10

berbae
Member
From: France
Registered: 2007-02-12
Posts: 1,302

Re: Problems with latest systemd 226-3

Sorry but I will stop answering in this thread.
I presented what I experienced on my desktop, and what my feeling/opinion are for me about this shutdown 90s delay. That's all I can do for now.
I think things could be different for other systems and other configurations/usages, but I want to do something else now, I am tired of this issue.
Good luck to everyone.

Offline

#35 2015-10-13 13:15:55

andrekp
Member
Registered: 2012-06-07
Posts: 112

Re: Problems with latest systemd 226-3

berbae wrote:

@andrekp
You say you changed nothing, but have you reduce the systemd timeout delay?
If yes, maybe it is too short now, because it is used elsewhere also, not only at shutdown.

But it could be another cause and an coincidence that it happens now, I don't know.
What you describe seems unrelated to the subject of this thread.

No,  I changed the delay (to 15 seconds) yesterday.  SSH stopped working over the weekend.  I have changed nothing since the update that seems to be involved in causing the problem that is the subject of this thread.  Purposefully so.  SSH, during this no change period, simply stopped working.  Downgrading it did nothing.  Upgrading it again did nothing. generating the key again did nothing.  It simply stopped working.

My thinking (that it MIGHT be related to this problem) comes from the fact that there is no other reason for it to just stop on the one box that also has this problem, and that this problem might tangentially have to do with processes not being properly connected with the user.  SSH needs to be connected to a user to properly find the keys, and it appears that it can't.  Maybe it's separate, maybe it's not.

Offline

#36 2015-10-13 16:39:11

berbae
Member
From: France
Registered: 2007-02-12
Posts: 1,302

Re: Problems with latest systemd 226-3

I advice you open a new thread with 'SSH stopped working' in the subject title, for knowledgeable ssh users to see it and to be interested in helping you.
Provide also what there is in the journal or other log files about ssd; maybe you can compare the messages before and after it stopped working.
Good luck with this.

Offline

#37 2015-10-13 17:22:29

nstgc
Member
Registered: 2014-03-17
Posts: 393

Re: Problems with latest systemd 226-3

Last night I exited out of all TTY, logged in as root on TTY1, killed all processes attributed to my normal log in, synced, then ran both "fuser -m /home/nstgc" and "ps aux |grep Z" as well as "|grep z". No processes shown, so I run "systemctl poweroff" My system was powered down within 5 seconds, but it didn't unmount /home/nstgc.

Is there something else I could do to find the process preventing the unmounting?

edit: I tried unmounting manually, however I get an error saying that it's busy. Below is the output of "ps aux". fuser -m returned nothing.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0 182220  5280 ?        Ss   13:08   0:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 21
root         2  0.0  0.0      0     0 ?        S    13:08   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    13:08   0:01 [rcu_preempt]
root         8  0.0  0.0      0     0 ?        S    13:08   0:00 [rcu_sched]
root         9  0.0  0.0      0     0 ?        S    13:08   0:00 [rcu_bh]
root        10  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/0]
root        11  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/0]
root        12  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/1]
root        13  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/1]
root        14  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/1]
root        16  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/1:0H]
root        17  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/2]
root        18  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/2]
root        19  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/2]
root        21  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/2:0H]
root        22  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/3]
root        23  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/3]
root        24  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/3]
root        26  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/3:0H]
root        27  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/4]
root        28  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/4]
root        29  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/4]
root        31  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/4:0H]
root        32  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/5]
root        33  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/5]
root        34  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/5]
root        36  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/5:0H]
root        37  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/6]
root        38  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/6]
root        39  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/6]
root        40  0.0  0.0      0     0 ?        S    13:08   0:01 [kworker/6:0]
root        41  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/6:0H]
root        42  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/7]
root        43  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/7]
root        44  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/7]
root        45  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/7:0]
root        46  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/7:0H]
root        47  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/8]
root        48  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/8]
root        49  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/8]
root        51  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/8:0H]
root        52  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/9]
root        53  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/9]
root        54  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/9]
root        56  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/9:0H]
root        57  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/10]
root        58  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/10]
root        59  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/10]
root        60  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/10:0]
root        61  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/10:0H]
root        62  0.0  0.0      0     0 ?        S    13:08   0:00 [watchdog/11]
root        63  0.0  0.0      0     0 ?        S    13:08   0:00 [migration/11]
root        64  0.0  0.0      0     0 ?        S    13:08   0:00 [ksoftirqd/11]
root        66  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/11:0H]
root        67  0.0  0.0      0     0 ?        S<   13:08   0:00 [khelper]
root        68  0.0  0.0      0     0 ?        S    13:08   0:00 [kdevtmpfs]
root        69  0.0  0.0      0     0 ?        S<   13:08   0:00 [netns]
root        70  0.0  0.0      0     0 ?        S<   13:08   0:00 [perf]
root        71  0.0  0.0      0     0 ?        S    13:08   0:00 [khungtaskd]
root        72  0.0  0.0      0     0 ?        S<   13:08   0:00 [writeback]
root        73  0.0  0.0      0     0 ?        SN   13:08   0:00 [ksmd]
root        74  0.0  0.0      0     0 ?        SN   13:08   0:00 [khugepaged]
root        75  0.0  0.0      0     0 ?        S<   13:08   0:00 [crypto]
root        76  0.0  0.0      0     0 ?        S<   13:08   0:00 [kintegrityd]
root        77  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root        78  0.0  0.0      0     0 ?        S<   13:08   0:00 [kblockd]
root        79  0.0  0.0      0     0 ?        S<   13:08   0:00 [devfreq_wq]
root        81  0.0  0.0      0     0 ?        S    13:08   0:00 [kswapd0]
root        82  0.0  0.0      0     0 ?        S    13:08   0:00 [fsnotify_mark]
root        87  0.0  0.0      0     0 ?        S<   13:08   0:00 [kthrotld]
root        91  0.0  0.0      0     0 ?        S<   13:08   0:00 [ipv6_addrconf]
root        92  0.0  0.0      0     0 ?        S<   13:08   0:00 [deferwq]
root       141  0.0  0.0      0     0 ?        S<   13:08   0:00 [ata_sff]
root       146  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_0]
root       147  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_0]
root       148  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_1]
root       149  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_1]
root       150  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_2]
root       151  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_2]
root       152  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_3]
root       153  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_3]
root       154  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_4]
root       155  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_4]
root       156  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_5]
root       157  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_5]
root       164  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_6]
root       165  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_6]
root       166  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_7]
root       167  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_7]
root       168  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_8]
root       169  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_8]
root       170  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_9]
root       171  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_9]
root       172  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_10]
root       173  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_10]
root       174  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_11]
root       175  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_11]
root       176  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_12]
root       177  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_12]
root       178  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_13]
root       179  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_13]
root       186  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_14]
root       188  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_14]
root       190  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_15]
root       191  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_15]
root       194  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_16]
root       195  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_16]
root       196  0.0  0.0      0     0 ?        S    13:08   0:00 [scsi_eh_17]
root       197  0.0  0.0      0     0 ?        S<   13:08   0:00 [scsi_tmf_17]
root       222  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/0:1H]
root       230  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/9:1]
root       235  0.0  0.0      0     0 ?        S<   13:08   0:00 [bcache]
root       240  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       241  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       246  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       247  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       250  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       261  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker]
root       262  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/u25:0]
root       263  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker-hi]
root       264  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delalloc]
root       265  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-flush_del]
root       266  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-cache]
root       267  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-submit]
root       268  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-fixup]
root       269  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio]
root       270  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       271  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       272  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rai]
root       273  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rep]
root       274  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-rmw]
root       275  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-wri]
root       276  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-freespace]
root       277  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delayed-m]
root       278  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-readahead]
root       279  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-qgroup-re]
root       280  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-extent-re]
root       286  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       287  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       288  0.0  0.0      0     0 ?        S<   13:08   0:00 [bcache_gc]
root       290  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/4:2]
root       294  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-cleaner]
root       295  0.0  0.0      0     0 ?        S    13:08   0:04 [btrfs-transacti]
root       297  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/3:2]
root       303  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/2:1H]
root       313  0.0  0.0      0     0 ?        S    13:08   0:00 [bcache_allocato]
root       314  0.0  0.0      0     0 ?        S    13:08   0:00 [bcache_gc]
root       315  0.0  0.0      0     0 ?        S    13:08   0:00 [bcache_writebac]
root       316  0.0  0.0      0     0 ?        S    13:08   0:00 [bcache_writebac]
root       317  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       318  0.0  0.0      0     0 ?        S<   13:08   0:00 [bioset]
root       319  0.0  0.0      0     0 ?        S    13:08   0:00 [bcache_writebac]
root       327  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/11:2]
root       330  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/6:1H]
root       333  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/10:1H]
root       342  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/4:1H]
root       343  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/1:1H]
root       344  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/5:1H]
root       351  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/3:1H]
root       352  0.0  0.0      0     0 ?        S<   13:08   0:00 [rpciod]
root       353  0.0  0.0      0     0 ?        S<   13:08   0:00 [nfsiod]
root       355  0.0  0.3 125400 52108 ?        Ss   13:08   0:00 /usr/lib/systemd/systemd-journald
root       373  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/9:1H]
root       374  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/9:2]
root       382  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/11:1H]
root       386  0.0  0.0  36908  5240 ?        Ss   13:08   0:00 /usr/lib/systemd/systemd-udevd
root       412  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/7:1H]
root       423  0.0  0.0      0     0 ?        S<   13:08   0:00 [kworker/8:1H]
root       451  0.0  0.0      0     0 ?        S    13:08   0:00 [irq/58-mei_me]
root       455  0.0  0.0      0     0 ?        S<   13:08   0:00 [edac-poller]
root       456  0.0  0.0      0     0 ?        S<   13:08   0:00 [kpsmoused]
root       463  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker]
root       464  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker-hi]
root       465  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delalloc]
root       466  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-flush_del]
root       467  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-cache]
root       468  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-submit]
root       469  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-fixup]
root       470  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio]
root       471  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       472  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       473  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rai]
root       474  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rep]
root       475  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-rmw]
root       476  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-wri]
root       477  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-freespace]
root       478  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delayed-m]
root       479  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-readahead]
root       480  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-qgroup-re]
root       481  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-extent-re]
root       487  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker]
root       488  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker-hi]
root       489  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delalloc]
root       490  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-flush_del]
root       491  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-cache]
root       492  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-submit]
root       493  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-fixup]
root       494  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio]
root       495  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       496  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       497  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rai]
root       498  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rep]
root       499  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-rmw]
root       500  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-wri]
root       501  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-freespace]
root       502  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delayed-m]
root       503  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-readahead]
root       504  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-qgroup-re]
root       505  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-extent-re]
root       533  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-cleaner]
root       534  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-transacti]
root       537  0.0  0.0      0     0 ?        S<   13:08   0:00 [kvm-irqfd-clean]
root       538  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker]
root       539  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-worker-hi]
root       540  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delalloc]
root       541  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-flush_del]
root       542  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-cache]
root       543  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-submit]
root       544  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-fixup]
root       545  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio]
root       546  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       547  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-met]
root       548  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rai]
root       549  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-rep]
root       550  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-rmw]
root       551  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-endio-wri]
root       552  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-freespace]
root       553  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-delayed-m]
root       554  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-readahead]
root       555  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-qgroup-re]
root       556  0.0  0.0      0     0 ?        S<   13:08   0:00 [btrfs-extent-re]
root       560  0.0  0.0      0     0 ?        S<   13:08   0:00 [cfg80211]
root       566  0.0  0.0      0     0 ?        S<   13:08   0:00 [led_workqueue]
root       576  0.0  0.0      0     0 ?        S<   13:08   0:00 [hci0]
root       577  0.0  0.0      0     0 ?        S<   13:08   0:00 [hci0]
root       590  0.0  0.0      0     0 ?        S    13:08   0:00 [kworker/7:4]
root       598  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-cleaner]
root       599  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-transacti]
root       603  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-cleaner]
root       604  0.0  0.0      0     0 ?        S    13:08   0:00 [btrfs-transacti]
systemd+   652  0.0  0.0 113916  3112 ?        Ssl  13:08   0:00 /usr/lib/systemd/systemd-timesyncd
root       658  0.0  0.0  15468  2824 ?        Ss   13:08   0:00 /usr/lib/systemd/systemd-logind
root       659  0.0  0.0  12032  7356 ?        Ss   13:08   0:03 /usr/bin/haveged -F -w 1024 -v 1
root       660  0.0  0.0  88628  8720 ?        Ss   13:08   0:00 /usr/bin/cupsd -l
dbus       665  0.0  0.0  37452  4200 ?        Ss   13:08   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root       667  0.0  0.0  22496  2488 ?        Ss   13:08   0:00 /usr/bin/dhcpcd -q -b
colord     700  0.0  0.0 299944 11260 ?        Ssl  13:08   0:00 /usr/lib/colord/colord
root      2770  0.0  0.0 234012  9440 ?        Ssl  13:09   0:00 /usr/lib/upower/upowerd
rtkit     2786  0.0  0.0 181788  3196 ?        SNsl 13:09   0:00 /usr/lib/rtkit/rtkit-daemon
root      2841  0.0  0.0 449564 12464 ?        Ssl  13:09   0:05 /usr/lib/udisks2/udisksd --no-debug
root      2887  0.0  0.0 275660  6900 ?        Ssl  13:09   0:00 /usr/lib/accountsservice/accounts-daemon
root      2897  0.0  0.0  47228  3464 ?        Ss   13:09   0:00 /usr/bin/wpa_supplicant -u
avahi     2909  0.0  0.0  43176  3712 ?        Ss   13:09   0:00 avahi-daemon: running [Host.local]
avahi     2913  0.0  0.0  43048   324 ?        S    13:09   0:00 avahi-daemon: chroot helper
root      3119  0.0  0.0      0     0 ?        S    13:14   0:00 [kworker/2:0]
root      3698  0.0  0.0      0     0 ?        S    13:23   0:00 [kworker/5:0]
root      3704  0.0  0.0      0     0 ?        S    13:23   0:00 [kworker/8:0]
root      6440  0.0  0.0      0     0 ?        S    14:58   0:00 [kworker/u24:15]
root      6456  0.0  0.0      0     0 ?        S<   14:59   0:00 [kworker/u25:3]
root      6472  0.0  0.0      0     0 ?        S    15:00   0:00 [kworker/1:1]
root      6609  0.0  0.0      0     0 ?        S    15:03   0:00 [kworker/0:2]
root      6691  0.0  0.0      0     0 ?        S    15:04   0:00 [kworker/10:1]
root      6693  0.0  0.0      0     0 ?        S    15:04   0:00 [kworker/11:1]
root      6695  0.0  0.0      0     0 ?        S    15:04   0:00 [kworker/3:0]
root      6698  0.0  0.0      0     0 ?        S    15:04   0:00 [kworker/4:1]
root      6700  0.0  0.0   7940  1772 tty2     Ss+  15:04   0:00 /sbin/agetty --noclear tty2 linux
root      6751  0.0  0.0      0     0 ?        S    15:04   0:00 [kworker/6:1]
root      6752  0.0  0.0  89864  4332 ?        Ss   15:04   0:00 login -- root
root      6754  0.0  0.0  34044  4488 ?        Ss   15:04   0:00 /usr/lib/systemd/systemd --user
root      6756  0.0  0.0 244564  1896 ?        S    15:04   0:00 (sd-pam)
root      6759  0.0  0.0  17800  5704 tty1     Ss   15:04   0:00 -bash
root      6798  0.0  0.0  19556  3032 tty1     S+   15:08   0:00 tmux
root      6800  5.2  0.0  22680  4096 ?        Rs   15:08   0:24 tmux
root      6801  0.1  0.0  17904  6120 pts/0    Ss   15:08   0:00 -bash
root      6808  0.0  0.0      0     0 ?        S    15:08   0:00 [kworker/0:1]
root      6809  0.0  0.0      0     0 ?        S    15:08   0:00 [kworker/8:2]
root      6813  0.0  0.0      0     0 ?        S    15:09   0:00 [kworker/5:2]
root      6814  0.0  0.0      0     0 ?        S    15:09   0:00 [kworker/1:0]
root      6815  0.0  0.0      0     0 ?        S    15:09   0:00 [kworker/2:1]
root      6823  0.0  0.0      0     0 ?        S    15:10   0:00 [kworker/u24:2]
root      6824  0.0  0.0      0     0 ?        S    15:10   0:00 [kworker/u24:3]
root      7782  0.0  0.0      0     0 ?        S    15:13   0:00 [kworker/0:0]
root      7783  0.0  0.0      0     0 ?        S    15:14   0:00 [kworker/8:1]
root      7915  0.0  0.0      0     0 ?        S    15:15   0:00 [kworker/3:1]
root      7918  0.0  0.0      0     0 ?        S    15:15   0:00 [kworker/1:2]
root      7921  0.0  0.0  36448  3440 pts/0    R+   15:15   0:00 ps aux

Nothing there is using my home directory.

lsof also shows nothing. So there are no processes using /home/nstgc, and no open files from there either.

edit2: I unmounted everything mounted under my home directory, then unmounted my home directory. That worked. Why is this nessisary? I don't know, but it takes a whole lot less time to do this than it does to check and scrub the whole volume because a single subvolume won't unmount.

Last edited by nstgc (2015-10-13 22:37:11)

Offline

#38 2015-10-31 17:14:09

NeoZelux
Member
Registered: 2012-10-28
Posts: 45

Re: Problems with latest systemd 226-3

for me, killing dhcpcd and wpa_supplicant consistently circumvent the problem (no "runing stop job").
Booting my laptop then immediately shutting down (without launching dhcpcd) avoids the shutdown issue as well.

Offline

#39 2015-11-07 23:46:27

orlfman
Member
Registered: 2007-11-20
Posts: 138

Re: Problems with latest systemd 226-3

i just got this issue today as well. 4 of them

a start job is running for:
store sound card state
restore sound card state
store sound card state
and user manager for uid 1000

followed by unable to unmount /home

took a little over 10 minutes to shutdown

Offline

#40 2015-11-11 13:52:14

nstgc
Member
Registered: 2014-03-17
Posts: 393

Re: Problems with latest systemd 226-3

I'm not longer sure that the c scope issue and the failure to unmount are related, but rather both are separate bugs in systemd. I have solved the issue with scope, but the only way to ensure that my home directory unmounts is to log in as root and recursively unmount it before shutting down.

Offline

#41 2015-11-15 18:33:17

Ledti
Member
Registered: 2010-07-31
Posts: 122
Website

Re: Problems with latest systemd 226-3

Serge2702 wrote:

Apparently, I have this same issue, but with a different cause. I always run conky with output to ncurses in a tab in Guake. If I don't kill conky's process I have this 90 second delay at shutdown. I got a shutdown log following these instructions http://freedesktop.org/wiki/Software/sy … eventually.

The relevant part is this:

[  211.598648] systemd[1]: session-c2.scope: Stopping timed out. Killing.
[  211.599409] systemd[1]: session-c2.scope changed stop-sigterm -> stop-sigkill
[  211.599453] systemd[1]: Received SIGCHLD from PID 1091 (conky).
[  211.599471] systemd[1]: Child 1091 (conky) died (code=killed, status=9/KILL)
[  211.599496] systemd[1]: session-c2.scope: Child 1091 belongs to session-c2.scope
[  211.599543] systemd[1]: session-c2.scope: cgroup is empty
[  211.599549] systemd[1]: session-c2.scope changed stop-sigkill -> failed
[  211.599634] systemd[1]: session-c2.scope: Job session-c2.scope/stop finished, result=done
[  211.599646] systemd[1]: Stopped Session c2 of user sergio.

EDIT: I forgot to mention that this is consistent. This only happens iff I don't kill conky. If I close guake conky continues to run in the background and this problem appears.

I only started getting this issue when I switched from i3status to conky w/ i3bar, so I can confirm that conky can trigger whatever the problem is.

Offline

#42 2015-12-10 23:04:56

Ledti
Member
Registered: 2010-07-31
Posts: 122
Website

Re: Problems with latest systemd 226-3

I've figured out what the problem was in my case.

My i3 configuration sets the display mode of i3bar to hide by default.

According to the user's guide for i3:

The hide mode maximizes screen space that can be used for actual windows. Also, i3bar sends the SIGSTOP and SIGCONT signals to the statusline process to save battery power.

For some reason, the 'killall -s TERM' command fails to kill the statusline process (conky in my case) in this scenario unless i3bar is visible. In other words, it fails to kill a process running under the SIGSTOP signal. I imagine something similar is happening to systemd during reboot/poweroff. This sounds like a bug but I'm not entirely sure myself, as it never happened to me before when using i3status.

My work-around is to instead call a script that sends a kill -9 signal to conky before reboot/poweroff, forcibly ending the statusline process.

#!/bin/bash

killall -q -w -s TERM audacious
killall -q -w -s TERM chromium
killall -q -w -s KILL conky

if [[ $1 == "-r" ]]; then
    systemctl reboot
else
    systemctl poweroff
fi

exit 0

The side benefit of this script is that it safely closes a few other applications for me, so I no longer have to do it manually.

Edit: Actually, it seems the 'killall -s TERM' & SIGSTOP problem is unrelated as the issue persists even if i3bar is in dock mode. Killing conky before reboot/poweroff still resolves the issue, but it's curious why systemd fails to do this itself.

Last edited by Ledti (2015-12-10 23:33:17)

Offline

#43 2016-01-03 00:18:38

bakteria
Member
Registered: 2015-12-15
Posts: 35

Re: Problems with latest systemd 226-3

Ledti wrote:

I've figured out what the problem was in my case.

My i3 configuration sets the display mode of i3bar to hide by default.

According to the user's guide for i3:

The hide mode maximizes screen space that can be used for actual windows. Also, i3bar sends the SIGSTOP and SIGCONT signals to the statusline process to save battery power.

For some reason, the 'killall -s TERM' command fails to kill the statusline process (conky in my case) in this scenario unless i3bar is visible. In other words, it fails to kill a process running under the SIGSTOP signal. I imagine something similar is happening to systemd during reboot/poweroff. This sounds like a bug but I'm not entirely sure myself, as it never happened to me before when using i3status.

My work-around is to instead call a script that sends a kill -9 signal to conky before reboot/poweroff, forcibly ending the statusline process.

#!/bin/bash

killall -q -w -s TERM audacious
killall -q -w -s TERM chromium
killall -q -w -s KILL conky

if [[ $1 == "-r" ]]; then
    systemctl reboot
else
    systemctl poweroff
fi

exit 0

The side benefit of this script is that it safely closes a few other applications for me, so I no longer have to do it manually.

Edit: Actually, it seems the 'killall -s TERM' & SIGSTOP problem is unrelated as the issue persists even if i3bar is in dock mode. Killing conky before reboot/poweroff still resolves the issue, but it's curious why systemd fails to do this itself.

I also have this problem. And I also have i3 with conky.

Offline

#44 2016-04-04 14:23:07

Layus
Member
Registered: 2012-04-30
Posts: 12

Re: Problems with latest systemd 226-3

I found more info for my case (conky hangs).

Running a debug-shell before powering off:

sudo systemctl start debug-shell.service

Then attaching gdb to a conky currently stopped by i3bar (the one with T, not S in ps output)

$ ps axu | grep conky
layus  1406  0.0  0.0 392188 12188 ?        Tl   14:51   0:00 conky
layus  1409  0.1  0.0 392188 10124 ?        Sl   14:51   0:08 conky
$ gdb conky 1406
(gdb) handle all nostop pass print
(gdb) continue

plus gdb logging, this gives

...
[show i3 bar]
Thread 1 "conky" received signal SIGCONT, Continued.
[hide i3 bar]
Thread 1 "conky" received signal SIGSTOP, Stopped (signal).
Thread 5 "conky" received signal SIGSTOP, Stopped (signal).
Thread 3 "conky" received signal SIGSTOP, Stopped (signal).
Thread 2 "conky" received signal SIGSTOP, Stopped (signal).
Thread 1 "conky" received signal SIGSTOP, Stopped (signal).
Thread 4 "conky" received signal SIGSTOP, Stopped (signal).
[show i3 bar]
Thread 1 "conky" received signal SIGCONT, Continued.
[hide i3 bar]
Thread 1 "conky" received signal SIGSTOP, Stopped (signal).
Thread 5 "conky" received signal SIGSTOP, Stopped (signal).
Thread 2 "conky" received signal SIGSTOP, Stopped (signal).
Thread 1 "conky" received signal SIGSTOP, Stopped (signal).
Thread 4 "conky" received signal SIGSTOP, Stopped (signal).
Thread 3 "conky" received signal SIGSTOP, Stopped (signal).
Thread 1 "conky" received signal SIGCONT, Continued.
Thread 1 "conky" received signal SIGSTOP, Stopped (signal).
Thread 2 "conky" received signal SIGTERM, Terminated.
Thread 4 "conky" received signal SIGTERM, Terminated.
Thread 1 "conky" received signal SIGCONT, Continued.
Thread 5 "conky" received signal SIGHUP, Hangup.
Thread 3 "conky" received signal SIGCONT, Continued.
Thread 1 "conky" received signal SIGPIPE, Broken pipe.
[Thread 0x7fdcdf83e700 (LWP 1399) exited]
[Thread 0x7fdcd783e700 (LWP 1398) exited]
[Thread 0x7fdce003f700 (LWP 1397) exited]
[Thread 0x7fdce0840700 (LWP 1396) exited]

Program terminated with signal SIGPIPE, Broken pipe.
The program no longer exists.
Error detected on fd 0
error detected on stdin
Exception ignored in: <gdb.GdbOutputFile object at 0x7f21761fbba8>
Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 43, in flush
    def flush(self):
KeyboardInterrupt

Now, the code of conky is such that a SIGHUP event can erase a SIGTERM event (see https://github.com/brndnmtthws/conky/bl … y.cc#L3175 and around https://github.com/brndnmtthws/conky/bl … .cc#L3035).

So, first conky does not handle signals correctly, but apparently systemd changed something because conky now receives a SIGHUP, which it did not receive before.

In this setup, conky ignores the SIGTERM and stays around, preventing proper shutdown.

Offline

#45 2016-04-04 14:48:43

berbae
Member
From: France
Registered: 2007-02-12
Posts: 1,302

Re: Problems with latest systemd 226-3

I use conky here and I do not have hangs like you get with it, when shutting down.

But I don't remember what system configuration you use and what could be special with your installation, to compare with mine...

Offline

#46 2016-04-05 19:41:05

Irok
Member
Registered: 2015-10-10
Posts: 56

Re: Problems with latest systemd 226-3

Hi, solution working for me :

Install watchdog  enable the service with systemctl and start it, use sync. reload daemons.

in /etc/systemd/system.conf file reduce the time to ten secons as berbae said

Do not mess with the hooks can cause that swap fails at boot

I am using conky and chromium in plasma destopk and the combination of this two solutions solved the problem for me ( no message  stop job is running for session C1 )

Last edited by Irok (2016-04-17 16:35:18)

Offline

#47 2016-04-09 19:50:57

ggoranov
Member
Registered: 2016-04-09
Posts: 13

Re: Problems with latest systemd 226-3

Irok wrote:

Hi, solution working for me :

Install watchdog  enable the service with systemctl and start it, reload daemons.

in /etc/systemd/system.conf file reduce the time to ten secons as berbae said

Do not mess with the hooks can cause that swap fails at boot

I am using conky and chromium in plasma destopk and the combination of this two solutions solved the problem for me ( no message  stop job is running for session C1 )


That fixed the problem for me as well

Offline

#48 2016-04-10 17:49:24

Irok
Member
Registered: 2015-10-10
Posts: 56

Re: Problems with latest systemd 226-3

Sorry for post the solution that late, I was using cinnamon and this problem was not present, whem I moved to plasma again it started. I figure out the solution the day after install plasma. Is still a little buggy but is usable now.

Offline

#49 2016-04-11 05:33:45

ggoranov
Member
Registered: 2016-04-09
Posts: 13

Re: Problems with latest systemd 226-3

After a bit more testing turns out that in my case in order the solution with the watchdog to work I have to reload daemons (systemctl daemon-reload) every time the pc boots. I must assume I am doing something wrong.

Offline

#50 2016-04-11 09:47:09

Irok
Member
Registered: 2015-10-10
Posts: 56

Re: Problems with latest systemd 226-3

ggoranov did you enable the service?

sudo systemctl enable watchdog.service

Last edited by Irok (2016-04-11 09:54:32)

Offline

Board footer

Powered by FluxBB