On Mo, 24.09.18 12:04, Mantas Mikulėnas (grawity@xxxxxxxxx) 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 really really shouldn't do that. > (I think this behavior is slightly ugly. It can be disabled by setting > 'queue_only=yes', but... it's probably necessary because the main daemon > only processes its queue every x minutes and won't notice queued messages > for a while.) If I got the above right then this isn't just "slightly" ugly, it's really awful. Daemon code should not be run from unprivileged user contexts, not in today's world. 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. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel