On Mon, Sep 24, 2018, 16:29 Kamil Jońca <[email protected]> wrote: > Lennart Poettering <[email protected]> writes: > > > On Mo, 24.09.18 12:04, Mantas Mikulėnas ([email protected]) wrote: > > > >> > Uh, this looks like something you need to ask the exim community, > >> > systemd can't make exim mail queueing decisions, that's entirely > >> > internal to exim. > >> > > >> > One question though: are you sure you have started the exim service > >> > properly beforehand? I am pretty sure exim won't process the mail > >> > queue if it's not running... > >> > >> exim's a bit oldschool, and whenever you pipe a message to 'sendmail', > it > >> immediately forks a worker to deliver the message synchronously, > regardless > >> of the main daemon running. > > > > Uh, what? Are you saying exim is forking off privileged daemon code > > from unprivileged user command invocations? Christ, that's ugly. They > Yes. exim is suid root to deliver mails. > > > really really shouldn't do that. > > But they do. > > > > > > It appears to me exim should figure out some way how clients such as > > 'sendmail' invocations can trigger queue dispatching some other way, > > for example, by making exim listen on some IPC of some form, or using > > inotify or anything else. > IIRC postfix is written that way, but I want to use exim, as it is more > configurable. > KJ >
When I was writing exim systemd units for Arch a few years ago, I experimented with using queue_only=true and no permanent daemon at all, but triggering the queue runner via systemd.path units (start as soon as spool is non-empty) and timers (to replace the usual -q15m). .path units are inotify-based and can start exim as soon as /usr/bin/sendmail puts something in the queue. This didn't work well enough IIRC, but if it did, then it'd provide almost postfix-like architecture. -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
