You are not logged in.
- Topics: Active | Unanswered
#26 2015-10-11 02:31:29
- nstgc
- Member
- Registered: 2014-03-17
- Posts: 393
Re: Problems with latest systemd 226-3
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.
@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
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
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
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,304
Re: Problems with latest systemd 226-3
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,304
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
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,304
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
@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,304
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 auxNothing 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: 141
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
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 0The 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
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 0The 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.serviceThen 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) continueplus 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):
KeyboardInterruptNow, 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,304
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
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.serviceLast edited by Irok (2016-04-11 09:54:32)
Offline