Slow shutdown/restart with sendsigs waiting 10 seconds

Bug #1212142 reported by Timo Jyrinki on 2013-08-14
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)
Medium
Unassigned
Saucy
Medium
Unassigned

Bug Description

I've the S20sendsigs waiting 10 seconds on each shutdown, making the shutdown slow.

I hacked around to debug it (probably completely wrongly), and ended up with the attached pids.txt. What is shows are the processes still after 9 seconds spent in the killall5 loop, with the pids from OMITPIDS removed from my ps ax output. It leaves only init, kernel processes, S20sendsigs itself and initctl which in my opinion should be enough not to wait for yet another second? The same output is there after two seconds already.

I've workarounded it now by changing the "for seq in 1 2 3 4 5 6 7 8 9 10; do" to "for seq in 1 ; do" which gives me a snappy shutdown back.
---
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
CheckboxSubmission: 1896b893828b4203b948b1eb6546be06
CheckboxSystem: d00f84de8a555815fa1c4660280da308
DistroRelease: Ubuntu 13.10
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-03-16 (515 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120316)
MarkForUpload: True
Package: initscripts 2.88dsf-41ubuntu3
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.11.0-2.5-generic 3.11.0-rc5
Tags: saucy
Uname: Linux 3.11.0-2-generic x86_64
UpgradeStatus: Upgraded to saucy on 2013-06-04 (70 days ago)
UserGroups: adm autopilot cdrom dip lp lpadmin motion plugdev sambashare sudo
mtime.conffile..etc.init.d.sendsigs: 2013-08-14T07:58:07.021383

Timo Jyrinki (timo-jyrinki) wrote :
tags: added: apport-collected saucy
description: updated

apport information

apport information

summary: - Slow shutdown on saucy with sendsigs waiting 10 seconds
+ Slow shutdown/restart on saucy with sendsigs waiting 10 seconds
Changed in sysvinit (Ubuntu Saucy):
importance: Undecided → Medium

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sysvinit (Ubuntu):
status: New → Confirmed
James Hunt (jamesodhunt) wrote :
b3nmore (b3nmore) wrote :

I see this in 12.04.3 as well, at least occasionally.

The attached screenshot shows a delayed shutdown/reboot. I've modified /etc/init.d/sendsigs to ps the ommited pids before killall5 -15 or killall -9 respectively. Additionally if killall5 -9 is called, all pids except the kernel threads are printed.

b3nmore (b3nmore) wrote :

Screenshot of a not delayed shutdown/reboot. In this case killall5 -9 is never called.

b3nmore (b3nmore) wrote :

Looks like some sort of race condition. If you add a sleep 2 after the sync call (near line 72) in /etc/init.d/sendsigs, terminating all processes works fine and the system shutdown/reboots without delay.

Aryeh Leib Taurog (vim-i) wrote :

I am running 14.04 and I have tried 'for seq in 1 ; do' and also adding the 'sleep 2' before sync as suggested by b3nmore, but neither seems to have any effect. It still prints '...' repeatedly for ~15 seconds before continuing shutdown

tags: added: precise

I experience the same bug on precise. Adding sleep 2 after sync (not before like @vim-i wrote above) helps.

I figured out that the problem is that when:

    killall5 -15 $OMITPIDS # SIGTERM

is called, `initctl emit plymouth-ready` process is not alive yet, so it does not receive SIGTERM. (I checked that.)

However, when

    if killall5 -18 $OMITPIDS ; then

is called, initctl process is running. As it is not in $OMITPIDS, `killall -18 reports` that not all processes has been killed and the loop does not break.

summary: - Slow shutdown/restart on saucy with sendsigs waiting 10 seconds
+ Slow shutdown/restart with sendsigs waiting 10 seconds

Screenshot of my delayed shutdown. I set number of loop iterations to 3 in order to fit whole sendsigs output on screen.

 I also attach my instrumented sendsig script file.

Rolf Leggewie (r0lf) wrote :

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in sysvinit (Ubuntu Saucy):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers