65959,7> aptitude install swapspace The following NEW packages will be installed: swapspace 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 30.1 kB of archives. After unpacking 116 kB will be used. Get: 1 http://mirrordirector.raspbian.org/raspbian/ stable/main swapspace armhf 1.10-4 [30.1 kB] Fetched 30.1 kB in 2s (12.1 kB/s) Selecting previously unselected package swapspace. (Reading database ... 124324 files and directories currently installed.) Preparing to unpack .../swapspace_1.10-4_armhf.deb ... Unpacking swapspace (1.10-4) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for systemd (215-17+deb8u1) ... Failed to execute operation: Connection timed out dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: systemd [ Rootkit Hunter version 1.4.2 ] ... 65961,9> ps axuf | grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 35 0.0 0.0 0 0 ? S< Aug16 0:00 \_ [DWC Notificatio] root 1 0.0 0.8 5636 3664 ? Ds Aug16 0:20 /sbin/init ... Congratulations Poettering. Writing an init that gets stuck in the D state is a feat of magnificent incompetence. Tentacling it so badly into the rest of the system that the system can't proceed out of this state is just fantastic. -- Tim Connors
65961,9> ps axuf | grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 35 0.0 0.0 0 0 ? S< Aug16 0:00 \_ [DWC Notificatio] root 1 0.0 0.8 5636 3664 ? Ds Aug16 0:20 /sbin/init ...
Congratulations Poettering.
Writing an init that gets stuck in the D state is a feat of magnificent incompetence. Tentacling it so badly into the rest of the system that the system can't proceed out of this state is just fantastic.
Sorry... what? Unless I'm missing context somewhere, that's an awful lot of conclusions to draw from one output of ps. In most of the cases I've experienced, a process stuck in the D state is normally a result of extreme system load, a driver fault, or a hardware fault (like a failing disk). James
In Tue, 18 Aug 2015, James Harper wrote:
65961,9> ps axuf | grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 35 0.0 0.0 0 0 ? S< Aug16 0:00 \_ [DWC Notificatio] root 1 0.0 0.8 5636 3664 ? Ds Aug16 0:20 /sbin/init ...
Congratulations Poettering.
Writing an init that gets stuck in the D state is a feat of magnificent incompetence. Tentacling it so badly into the rest of the system that the system can't proceed out of this state is just fantastic.
Sorry... what?
Unless I'm missing context somewhere, that's an awful lot of conclusions to draw from one output of ps. In most of the cases I've experienced, a process stuck in the D state is normally a result of extreme system load, a driver fault, or a hardware fault (like a failing disk).
X got stuck. In a well designed system, this would result in any clients and dependencies of those clients also getting stuck. Not init. Why the fuck would init be doing anything other than wait()ing for zombie processes? -- Tim Connors
On Tue, 18 Aug 2015 09:47:48 PM Tim Connors wrote:
Why the fuck would init be doing anything other than wait()ing for zombie processes?
syslog telinit q - reread inittab open()s/unlink()s /var/log/initrunlvl open()s/lstat()s /etc/initrunlvl (reopens on SIGUSR1 for example) write to utmp/wtmp access /dev/initctl FIFO for telinit commands will access /var/run/powerstatus on SIGPWR that's all in sysvinit -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Tue, 18 Aug 2015 10:48:07 PM Chris Samuel wrote:
On Tue, 18 Aug 2015 09:47:48 PM Tim Connors wrote:
Why the fuck would init be doing anything other than wait()ing for zombie processes?
syslog *** telinit q - reread inittab *** open()s/unlink()s /var/log/initrunlvl *** open()s/lstat()s /etc/initrunlvl (reopens on SIGUSR1 for example) *** write to utmp/wtmp access /dev/initctl FIFO for telinit commands *** will access /var/run/powerstatus on SIGPWR
that's all in sysvinit
I've put asterisks next to the items that could cause init to get stuck in D state. The X server has significant access to the hardware and if something goes wrong (either with X, the kernel code it talks to, or the hardware) then there is no real limit to the scope of the damage. If something goes wrong to the stage that it hangs up the core filesystem code then everything on that filesystem can block. Now you could reasonably complain that systemd causes people to not have a separate filesystem for /usr which means that anything affecting /usr also affects the root filesystem. However in Debian there is work on addressing that issue. Also there are many other factors than systemd leading to people using the same filesystem for root and /usr (including large disks and filesystems such as BTRFS that encourage putting it all in one filesystem). Also in recent versions of Debian /var/run is a symlink to /run which is a tmpfs. Tmpfs is less likely to block than most filesystems unless you have heavy swapping load, and even then /run is unlikely to be paged out. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, 18 Aug 2015 11:20:43 PM Russell Coker wrote:
I've put asterisks next to the items that could cause init to get stuck in D state.
Yeah, that was my point, I should have mentioned that.. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 18 August 2015 at 20:59, Tim Connors <tim.w.connors@gmail.com> wrote:
65959,7> aptitude install swapspace The following NEW packages will be installed: swapspace
I don't understand how you go from installing one package and end up having installation issues with a completely different one. Care to cat the postinst script that's causing the problem? Without venom would be nice too. -- Clinton Roy Software Developer Netboxblue.com Total Internet Management Control Internet usage within and outside your organisation.
On Tue, 18 Aug 2015, Clinton Roy wrote:
On 18 August 2015 at 20:59, Tim Connors <tim.w.connors@gmail.com> wrote:
65959,7> aptitude install swapspace The following NEW packages will be installed: swapspace
I don't understand how you go from installing one package and end up having installation issues with a completely different one.
Care to cat the postinst script that's causing the problem?
At a guess it'd be this: # Automatically added by dh_installinit if [ -x "/etc/init.d/swapspace" ]; then update-rc.d swapspace defaults >/dev/null invoke-rc.d swapspace start || exit $? fi # End automatically added section in info/swapspace.postinst -- Tim Connors
On Tue, 18 Aug 2015 at 22:43 Tim Connors <tim.w.connors@gmail.com> wrote:
in info/swapspace.postinst
Note this error happened in the unpacking phase, not the configuration phase. So I think it is unlikely dpkg has even looked at swapspace' postinst at this point. Also note the previous line is "Processing triggers for systemd". I note that swapspace doesn't have a preinst script. So I would speculate the problem is in the systemd trigger. (this being complicated so far has nothing to do with systemd, but rather the design of dpkg) Looking at /var/lib/dpkg/info/systemd.postinst I would speculate the trigger being called is after /etc/init.d is updated, it calls "systemctl daemon-reload" via a wrapper that checks /run/systemd/system exists first. The only time I have seen this happen myself is when systemd was already broken, because the kernel was too old and didn't have the required features. Possibly nothing wrong with the kernel here, however I have to wonder if systemd was already broken for some reason. Maybe it failed to start up correctly because something else was broken.
On Tue, 18 Aug 2015 10:45:32 PM Brian May wrote:
Looking at /var/lib/dpkg/info/systemd.postinst I would speculate the trigger being called is after /etc/init.d is updated, it calls "systemctl daemon-reload" via a wrapper that checks /run/systemd/system exists first.
The only time I have seen this happen myself is when systemd was already broken, because the kernel was too old and didn't have the required features.
Possibly nothing wrong with the kernel here, however I have to wonder if systemd was already broken for some reason. Maybe it failed to start up correctly because something else was broken.
Or X had already hosed the system, and then when systemd was told to reread config files it got blocked on device IO. Difficult to tell without something like dmesg output to see whether things had already gone bung by this stage and an alt-sysrq-w dump to list the state of tasks that are in uninterruptible state ('D'). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, 19 Aug 2015, Chris Samuel wrote:
On Tue, 18 Aug 2015 10:45:32 PM Brian May wrote:
Looking at /var/lib/dpkg/info/systemd.postinst I would speculate the trigger being called is after /etc/init.d is updated, it calls "systemctl daemon-reload" via a wrapper that checks /run/systemd/system exists first.
The only time I have seen this happen myself is when systemd was already broken, because the kernel was too old and didn't have the required features.
Possibly nothing wrong with the kernel here, however I have to wonder if systemd was already broken for some reason. Maybe it failed to start up correctly because something else was broken.
Or X had already hosed the system, and then when systemd was told to reread config files it got blocked on device IO.
Difficult to tell without something like dmesg output to see whether things had already gone bung by this stage and an alt-sysrq-w dump to list the state of tasks that are in uninterruptible state ('D').
Filesystem (root NFS) was definitely OK. Only things stuck were systemd and virtual console stuff. systemd-getty-generator would have been stuck because console was stuck. From there, somehow init ended up waiting for a kernel lock. -- Tim Connors
On 18/08/15 20:59, Tim Connors wrote:
65959,7> aptitude install swapspace The following NEW packages will be installed: swapspace Congratulations Poettering.
Writing an init that gets stuck in the D state is a feat of magnificent incompetence. Tentacling it so badly into the rest of the system that the system can't proceed out of this state is just fantastic. hi
had a problem with swap space not being recognised on boot on a Fedora-21 and the answer was disable swap on boot, enable rc.local and start swap from there. https://bugzilla.redhat.com/show_bug.cgi?id=1227178 details the problem Steve
participants (7)
-
Brian May -
Chris Samuel -
Clinton Roy -
James Harper -
Russell Coker -
Steve Roylance -
Tim Connors