18 Aug
2015
18 Aug
'15
1:20 p.m.
On Tue, 18 Aug 2015 10:48:07 PM Chris Samuel wrote:
On Tue, 18 Aug 2015 09:47:48 PM Tim Connors wrote:
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/
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