Oct  7 07:45:56 post cyrus/lmtpunix[307]: DBERROR db4: Logging region out of memory; you may need to increase its size
Oct  7 07:45:56 post cyrus/lmtpunix[307]: DBERROR: opening /var/lib/cyrus/deliver.db: Cannot allocate memory
Oct  7 07:45:56 post cyrus/lmtpunix[307]: DBERROR: opening /var/lib/cyrus/deliver.db: cyrusdb error
Oct  7 07:45:56 post cyrus/lmtpunix[307]: FATAL: lmtpd: unable to init duplicate delivery database
Oct  7 07:45:56 post cyrus/master[754]: service lmtpunix pid 307 in READY state: terminated abnormally

Seems like this can be fixed with:

/etc/init.d/cyrus2.2 stop
cat< /var/lib/cyrus/db/DB_CONFIG
set_cachesize 0 2097152 1
set_lg_regionmax 1048576
EOM
/etc/init.d/cyrus2.2 start

Looking more closer into the logs, it turned out that this trouble started last night when I connected with a client running the soon to be released Ubuntu Oneiric Ocelot using the new kmail2.

So it looks like the KDE/Ubuntu folks broke again kmail (or any KDE subsystem), as it also has troubles when migrating over from kmail(1) and it looks like it’s not able to access most of the imap subfolders. Well done!

Some more about packaging nagios and icinga related packages can be found at our team site.

# dpkg -l | grep xen | grep bpo
ii libxenstore3.0 4.0.1-1~bpo50+1 Xenstore communications library for Xen
ii linux-image-2.6.32-bpo.5-xen-686 2.6.32-26~bpo50+1 Linux 2.6.32 for modern PCs, Xen dom0 suppor
ii xen-hypervisor-4.0-i386 4.0.1-1~bpo50+1 The Xen Hypervisor on i386
ii xen-linux-system-2.6.32-bpo.5-xen-686 2.6.32-26~bpo50+1 Xen system with Linux 2.6.32 on modern PCs (
ii xen-tools 4.1-1~bpo50+1 Tools to manage Debian XEN virtual servers
ii xen-utils-4.0 4.0.1-1~bpo50+1 XEN administrative tools
ii xen-utils-common 4.0.0-1~bpo50+1 XEN administrative tools – common files
ii xenstore-utils 4.0.1-1~bpo50+1 Xenstore utilities for Xen

This fixed the problem of spontaneous reboots for all of the systems I have migrated …. until now! Last week I tried this solution on my private system and it failed in some way.

A full dump of the syslog is also available. It looks like /etc/rcS.d/S03udev is hanging in some way .. the syslog for this looks like:

Oct 29 20:51:07 mordor kernel: [ 17.728120] Code: 04 00 00 00 00 83 3c 24 10 74 32 77 0c 83 3c 24 08 0f 85 9f 00 00 00 eb 12 83 3c 24 20 74 30 83 3c 24 40 0f 85 8d 00 00 00 eb 35 <0f> b6 01 8b 54 24 20 89 02 c7 42 04 00 00 00 00 eb 79 0f b7 01
Oct 29 20:51:07 mordor kernel: [ 17.731554] EIP: [] acpi_ex_system_memory_space_handler+0×189/0×221 SS:ESP 0069:ec135d74
Oct 29 20:51:07 mordor kernel: [ 17.731791] CR2: 00000000eda86000
Oct 29 20:51:07 mordor kernel: [ 17.731881] —[ end trace 7b8af581772a1c55 ]—
Oct 29 20:51:07 mordor kernel: [ 18.116622] input: PC Speaker as /devices/platform/pcspkr/input/input6
Oct 29 20:51:07 mordor kernel: [ 18.427607] Error: Driver ‘pcspkr’ is already registered, aborting…
Oct 29 20:51:07 mordor kernel: [ 232.381814] Adding 10000452k swap on /dev/sda2. Priority:-1 extents:1 across:10000452k

The dom0 is there hanging in some way … I don’t have an exact way to get the system proceed from there … usually I need to wait some seconds and pressing ^C after a while will get the box up.
Anyways … I remember there are some problems with udev >= 150 and older kernels, which is also documented in the squeeze release notes. Maybe there is also a problem with older udev and newer kernels? But why is this combination working on other systems? Booting linux-image-2.6.32-bpo.5-686 works without any issue anyways, so it seems xen related. Any idea is appreciated!
UPDATE: I’ve also reported this via #602109.

P.S. If you like nagios and/or icinga related software, there is a Nagios Maintainers Group and we would like to invite you, if you want to improve or extend the nagios/icinga ecosystem in Debian.

• mailscanner 4.79.11-2~bpo50+1
• icinga 1.0.1-3~bpo50+1 (NEW queue)
• nagios3 3.2.0-5~bpo50+1
• php-suhosin 0.9.31-1~bpo50+1 (NEW queue)

A new haproxy 1.4.4-1~bpo50+1 package is in preparation and needs testing before uploading. You can find the package here.

You can discover your DUN channel something like:

# hcitool scan
Scanning …
3C:F7:2A:1A:4D:2A Cycophone
# sdptool browse 3C:F7:2A:1A:4D:2A | \
grep -9 “Service Name: Dial-Up Networking” | \
tail -10 | grep Channel
Channel: 22

So your /etc/bluetooth/rfcomm.conf should now look like:

…
rfcomm0 {
bind yes;
device 3C:F7:2A:1A:4D:2A;
channel 22;
comment “Cycophone”;
}
…