Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> On Sun, Feb 22, 2026 at 12:08:52PM +0100, Omar Polo wrote:
> > Hello Martijn,
> > 
> > Martijn van Duren <openbsd+tech@list.imperialat.at> wrote:
> > > [... cutting the mail because it was mangled :p ...]
> > 
> > I'm a bit on the fence on this as well.  I've been bitten by this as
> > well, and in general I think it's weird to using daemon(3) in smtpd (and
> > from the look of it radiusd as well, but i've never used it).
> > 
> > If we want to keep the "daemonization" in the program, I agree that a
> > two-step process like the one you suggest is needed, and having some
> > code to share (even just by copy-paste) between radiusd and smtpd seems
> > nice to me.
> > 
> > I still have to look at the implementation in detail, but at least as a
> > general direction, assuming again that we want to keep smtpd detaching
> > on its own, I think it's fine.
> > 
> > <madness>
> > 
> > For fairness tho, I have to say that while we were talking about this
> > I've thought multiple times "what if we just drop *gasp!* the forking in
> > the background in smtpd?" Instead of piling more code to fix the
> > problem, we could just always keep it running in the foreground, set
> > rc_bg=YES in the rc.d file, all with a net-negative diff I'd guess.
> > 
> > (it's not *that* simple, I know, but it's not terribly hard either)
> > 
> > I think that there are just two ways of running smtpd, and both will
> > continue to work just fine (except that there would no longer be a need
> > for -d)
> > 
> >  - rcctl (re)start smtpd, or
> >  - smtpd -dv for debugging
> > 
> > </madness>
> 
> In general you can adjust your daemons to call daemon(3) once it is clear
> it will have a good chance to run. This is what e.g. bgpd does. The
> initial configuration is loaded before daemon(3) calls and so the simple
> problems are quickly noticed. Sure there are cases where this does not
> work but things like config loads can be moved up with little problems. 

the config is a red-herring in this case.  that can be be fixed in
radiusd I think.  I don't use radius so -sorry yasuoka- I don't care
about that aspect.

The problem that martijn is raising here is something that cannot be
fixed by rearranging code.  smtpd (and radius, but potentially others)
need to exec some helpers which are long-lived (the smtpd filters and
tables, i think in radius these are the "modules").

at config parsing time, that's just a string.

but if execve(2) fails, smtpd dies.  this is actually a hard requirement
since filters are not allowed to fail.

The problem is that this needs to happen after daemon() from what I
understand, since daemon is going to fork, and if at that point the
filter, for e.g., does not exist, smtpd dies but you think it was
started properly.  rcctl would have printed "ok", and if you ran it
manually $? would be zero.  yet, it died immediately after daemon() and
it's not running anymore.

that's why i think there is a good rationale for martijn' daemon
changes.  by turning this into a two-step phase, we can properly tell
the user "you've mistyped the path to the filter" and fail, instead of
letting them think that we've started correctly.

note that this is a completely different issue from "what if the filter
dies at runtime": then smtpd dies but it's a runtime thing, that's why
we have monitoring, and it's a different failure mode than just a typo
in a string that can't be spotted (sanely) at config parse time.

> I seriously hate daemons that don't call daemon. Those are not daemons,
> those are sloopy programs that would like to be long running but fail to
> do it correctly.

I'm reasoning a lot about this recently, and while my thoughts might be
heretic I think that it's an interesting perspective, so I beg to
disagree.  at least in the usage of the "sloppy" adjective :P
maybe sloppy where only the daemons that you had the chance to read,
not the general idea.

In any case, I'd prefer not to steer this thread away from the topic,
the changes proposed by martiin which are going to land in radiusd as
well, and apologize for opening this parethesis.


Cheers,
Omar Polo