Jeremy Harris via Exim-users <exim-users@???> (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
