Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.511 SMTPd fails to start with chroot Bus error

Greetings, all...

I was getting inundated from my demo v7 box with "configuration daemon not running...restarted" messages, so I bumped from 7.509 to 7.511. Now, I can't get SMTP to start:


[FONT=monospace]2011:10:02-13:00:20 secmgr-va selfmonng[3227]: W NOTIFYEVENT Name=smtp_running Level=INFO Id=125 suppressed [/FONT]
[FONT=monospace]2011:10:02-13:00:20 secmgr-va selfmonng[3227]: W triggerAction: 'cmd' [/FONT]
[FONT=monospace]2011:10:02-13:00:20 secmgr-va selfmonng[3227]: W actionCmd(+):  '/var/mdw/scripts/smtp restart' [/FONT]
[FONT=monospace]2011:10:02-13:00:22 secmgr-va selfmonng[3227]: W child returned status: exit='0' signal='0' [/FONT]
[FONT=monospace]2011:10:02-13:00:42 secmgr-va selfmonng[3227]: I check Failed increment smtp_running counter 1 - 15 [/FONT]
[...]
[FONT=monospace]2011:10:02-13:05:22 secmgr-va selfmonng[3227]: W check Failed increment smtp_running counter 15 - 15 [/FONT]
I get no logs whatsoever (no debug), as the daemon doesn't even get that far. /var/mdw/scripts/smtp start yields:
/var/mdw/scripts/smtp: line 23: 23075 Bus error               chroot $CHROOT /bin/smtpd.bin $WORKER
[ ok ]
None of the other postgres-dependent functions seem to be affected, however, I reinitialized the databases, anyway, just for good measure. I'm really hoping I don't need to re-install the server (again). I was hoping to get my demo up to v8, so I'd have something new to show a client this week...

Any thoughts?

TIA


This thread was automatically locked due to age.
Parents
  • Problem somewhat resolved:

    (With many thanks to Timothy in Astaro US Support.)

    "Bus error" is coming back from the smtp daemon itself (the fact that it is chrooted is of no consequence). Somehow, during the update from 7.509 to 7.510 and/or 7.511, the /var/chroot-smtp/tmp/ram/pid directory vanished, and the startup script apparently does not automatically recreate it (I thought that it did). So, as there was no directory for the daemon to write the pid file, it looks like it just fell over (I didn't expect this, as I knew the ram directory needed to be there - I thought it wrote the pid there and not under that level, as it's chrooted, and nothing else would be writing a pid there - I wouldn't think).

    Instead of investigating further, I opted to make a backup of the config, install v8.2 from CD, and restore from the stick during the first boot. This was the absolute fastest, neatest Astaro upgrade I've ever done. Everything came up perfectly.

    So, the lesson to be learned is: A bus error indicates an inability to write something which is necessary. This can be caused by running out of disk space, a failure of the disk controller or channel, or the physical disk hardware, as well as  - such as in this case - a missing directory location. I would have thought it always referred to a hardware bus error.
Reply
  • Problem somewhat resolved:

    (With many thanks to Timothy in Astaro US Support.)

    "Bus error" is coming back from the smtp daemon itself (the fact that it is chrooted is of no consequence). Somehow, during the update from 7.509 to 7.510 and/or 7.511, the /var/chroot-smtp/tmp/ram/pid directory vanished, and the startup script apparently does not automatically recreate it (I thought that it did). So, as there was no directory for the daemon to write the pid file, it looks like it just fell over (I didn't expect this, as I knew the ram directory needed to be there - I thought it wrote the pid there and not under that level, as it's chrooted, and nothing else would be writing a pid there - I wouldn't think).

    Instead of investigating further, I opted to make a backup of the config, install v8.2 from CD, and restore from the stick during the first boot. This was the absolute fastest, neatest Astaro upgrade I've ever done. Everything came up perfectly.

    So, the lesson to be learned is: A bus error indicates an inability to write something which is necessary. This can be caused by running out of disk space, a failure of the disk controller or channel, or the physical disk hardware, as well as  - such as in this case - a missing directory location. I would have thought it always referred to a hardware bus error.
Children
No Data