Your message dated Wed, 12 Feb 2025 11:57:45 +0000
with message-id <[email protected]>
and subject line Re: Bug#454147: /sbin/bootlogd: bootlogd: deadlock under Xen
domU, wrong console device
has caused the Debian Bug report #454147,
regarding /sbin/bootlogd: bootlogd: deadlock under Xen domU, wrong console
device
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
454147: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454147
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sysvinit
Version: 2.86.ds1-38
Severity: normal
File: /sbin/bootlogd
Hi,
there is problem with bootlogd under Xen domU, unless right console
device is specified on kernel command line.
Valid console device is tty1 for domU me and I'm not certein, this is
constant behavior (no knowledge). If I create domain with
xm create -c etch
then logs in there and type tty, I get /dev/tty1.
When I add console=tty1 to kernel params of domain config file,
then bootlogd works as expected probably.
In the case of no console= in kernel command line bootlogd leaves in
deadlock eating up 100% VCPU and strace on it shows neverending:
open("/dev/ttyS0", O_WRONLY|O_NONBLOCK|O_NOCTTY) = 3
fcntl64(3, F_GETFL) = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(3, F_SETFL, O_WRONLY) = 0
write(3, ".\r\n", 3) = -1 EIO (Input/output error)
close(3) = 0
open("/dev/ttyS0", O_WRONLY|O_NONBLOCK|O_NOCTTY) = 3
fcntl64(3, F_GETFL) = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(3, F_SETFL, O_WRONLY) = 0
write(3, ".\r\n", 3) = -1 EIO (Input/output error)
close(3) = 0
...
There is comment in the source (before write_err() function)
/*
* We got a write error on the real console. If its an EIO,
* somebody hung up our filedescriptor, so try to re-open it.
*/
For some reason bootlogd suppose /dev/ttyS0 console device.
Regards.
--
zito
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-xen-686
Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2)
Versions of packages sysvinit depends on:
ii initscripts 2.86.ds1-38 Scripts for initializing and shutt
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii libselinux1 2.0.35-0.icz.2 SELinux shared libraries
ii libsepol1 2.0.11-0.icz.1 Security Enhanced Linux policy lib
ii sysv-rc 2.86.ds1-38 System-V-like runlevel change mech
ii sysvinit-utils 2.86.ds1-38 System-V-like utilities
sysvinit recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 3.10-1
I now notice that the bootlogd looping endlessly when failing to open the device
was fixed upstream in 3.10:
sysvinit (3.10) released; urgency=low
* Fix issue in bootlogd which could cause the service to enter an endless
loop
(and use too much CPU) when it is able to open a device for writing, but
not actually
able to write to it. This resulted in bootlogd closing and re-opening the
device over
and over. Now bootlogd should simply fail gracefully when it cannot write
to an open
file/device.
Closing.
Mark
--- End Message ---
