From: "Omar Polo" Subject: Re: split daemon(3) functionality for better debugability To: Claudio Jeker Cc: Martijn van Duren , tech@openbsd.org Date: Sun, 22 Feb 2026 18:52:30 +0100 Claudio Jeker wrote: > On Sun, Feb 22, 2026 at 12:08:52PM +0100, Omar Polo wrote: > > Hello Martijn, > > > > Martijn van Duren 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. > > > > > > > > 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 > > > > > > 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