Jeremy Harris via Exim-users <[email protected]> (So 05 Apr 2020 12:33:58 CEST): > On 05/04/2020 11:13, Heiko Schlittermann via Exim-users wrote: > > > > And in forking mode? I *think*, as soon as the forking process returns, > > systemd assumes the service is available, doesn't it? Thus, the same may > > happen, if the forked process needs some time to setup its listeners and > > so on. > > That's true, though there's a slight wrinkle. Apparently systemd does > not consider a "forking" service started until the process *it* forked > exits. By that time it must of course have forked a second time to > create the daemon process. Exim will have read its config by then - > but has not yet created the listener sockets. We should consider > moving the fork that bit later; if that works ok we'd be better off > under systemd (in forking mode).
Maybe we're talking about the same, bot I didn't get your point.
That's what I think:
systemd Type=forking
t0 `------ exim -bd
fork()---- exim daemon
t1 <----------' - read configuration
- setup listener
systemd Type=simple
t0 `------ exim -bdf
t1 <-------' `- read configuration
- setup listener
In both cases systemd might consider the service running while it is
still in setup process.
More advantages of forground (Type=simple) mode:
- systemd can caputure stdout/stderr (important if Exim was
started with debug flags
- systemd can detect startup failure (if Exim dies on a
configuration file error)
systemd Type=notify
t0 `------ exim -bdf
`- read configuration
- setup listener
t1 <------------ notify systemd via sd_notify()
Seems to me as a pretty clean approach. If I'm not wrong in my
understanding of systemd.
--
Heiko
signature.asc
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
