The officially official Devuan Forum!

You are not logged in.

#1 2025-06-22 14:23:44

User479
Member
From: Central USA
Registered: 2021-11-07
Posts: 28  

[SOLVED] OpenSMTP starting too soon

The system here is on Excalibur with SysV init.  I've run into a situation where OpenSMTP fails during system startup.  The logged messages are:

smtpd[4364]: info: OpenSMTPD 7.6.0-portable starting
smtpd[4369]: dispatcher: smtpd: bind: Cannot assign requested address
smtpd[4365]: smtpd: process dispatcher socket closed

If I start the service after booting is complete it works fine.  I think the problem must stem from the fact that opensmtp (which listens on localhost) is started before NetworkManager can initialize the loopback interface.  Ifupdown is not currently installed but had been.

The init script includes $network in the Required-Start list so this condition is apparently being satisfied even before NM has been started.  I have tried changing Required-Start to $all and that does delay the start of opensmtp until just after network-manager has started but the loopback interface has still not been initialized at that point so opensmtp still fails.

What is kinda weird is that this behavior started after I purged the ifupdown package.  The interfaces files was empty so ifupdown should not have been doing anything but it's almost like it was initializing loopback anyway.  I have syslogs from that period and they show opensmtp happily starting before network-manager with about 0.25 seconds elapsing before loopback is initialzed!

Is there a way to make the init wait until NM has completed initializing all interfaces before starting the dependent scripts?  As a temporary? workaround, I have added a "sleep 5" in the start code of opensmtp's init script.

Edit #1: I found that if I have opensmtpd listen on 127.0.0.1 instead of localhost then it will start (without Network Manager).  If I have it listen on ::1 then it still fails with the error above.  Listening on localhost caused it to try to listen on both those addresses - apparently it is ok at that point with ipv4 but not ipv6.

Edit #2: On another system I found that after purging ifupdown, dovecot won't start either (until after network manager inits the interfaces).  It can no longer bind to ::1,443 and ::1,993.  It seems like I am zeroing-in on the root cause.

Last edited by User479 (2025-06-23 19:00:59)

Offline

#2 2025-06-23 13:02:14

User479
Member
From: Central USA
Registered: 2021-11-07
Posts: 28  

Re: [SOLVED] OpenSMTP starting too soon

As a side issue I will add that when I first started researching this I had, in /etc/rc?.d/, links for S03opensmtpd & S04network-manager, which is why openstmpd was starting before network manager despite openstmpd being dependent on network manager.  I disabled and enabled network manager and then had S04network-manager & S14opensmtpd - which is the expected order.  cron & rsync also changed from S03 to S14.

I think this points to a problem somewhere with the way the init links are maintained.  Perhaps there should be a process that resets their order anytime a script is added/changed/deleted during an upgrade (while preserving the state of manually disabled services).

Offline

#3 2025-06-24 02:50:28

User479
Member
From: Central USA
Registered: 2021-11-07
Posts: 28  

Re: [SOLVED] OpenSMTP starting too soon

I have learned a bunch today!  Most important is that the ifupdown package contains some important scripts that can cause headaches if they aren't there, even if you have no use for ifupdown to manage your interfaces.  settle-dad.sh and wait-for-ll6.sh in /usr/lib/ifupdown/, for example, wait for an ipv6 interface to leave the tentative state and get a link-local address so any following processes have a usable interface.  Eureka!

Edit #1: In fact, even if ifupdown's interfaces file is empty, it will still go all the way to configuring and "ifup-ing" the loopback.  The scripts mentioned above are probably part of the ifup process.  Setting CONFIGURE_INTERFACES=no in /etc/default/networking skips this (but then you might as well purge the package).

Last edited by User479 (2025-06-24 16:26:49)

Offline

Board footer