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/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
