Re: [systemd-devel] exim4 only queues mails sent by systemd service
Am 24.09.18 um 22:07 schrieb Dan Nicholson: > This is exactly what exim does when run via sendmail (which mail and > mutt likely use behind the scenes). I had a very similar setup to the > OP using exim on one of our servers and was perplexed why the queue > wasn't being flushed immediately. Here's what I wrote our git history: > > I had naively thought that sendmail used SMTP to send a mail to the > local MTA. That's actually not the case for either exim or postfix, > which use internal procedures to queue and send the mail. Normally > that's not a problem except when sendmail is run by a systemd service. > Then the way that processes are spawned to queue and send the mail have > to match the service type. In the case of exim, the sending process > actually forks from sendmail, which systemd kills before it can run if > the service type is set to oneshot. and be happy about it! other than with the dumb native "sendmail" you don't lose mails just because the service won't start for whatever reason see what happens otherwise https://www.reddit.com/r/vmware/comments/7mmh3o/vcenter_server_appliance_65_update_1cd_email/ you lose alert mails just because that idiotic configuration was wrong, with postfix after you got it starting again you get all your system-mails in the meantime submitted with the "sendmail-interface" aka maildrop ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mon, Sep 24, 2018 at 1:38 PM Lennart Poettering wrote: > > On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: > > > This didn't work well enough IIRC, but if it did, then it'd provide > > > almost postfix-like architecture. > > > > > > Or just making 'sendmail' send a SIGALRM to the main daemon would do the > > > job perfectly well, I suspect... > > > > But I still does not know, where is the problem, why exim doest not play > > well with systemd ... > > Here's an educated guess: your script terminates, so that that systemd > decides your service has ended. In such a case it kills any left-over > processes of the service, and this will include the exim process > forked off into the bg, because it is attributed to your script's > context. > > Thus the exim queue runner might be forked off, but it wil be > immediately terminated by systemd again... This is exactly what exim does when run via sendmail (which mail and mutt likely use behind the scenes). I had a very similar setup to the OP using exim on one of our servers and was perplexed why the queue wasn't being flushed immediately. Here's what I wrote our git history: I had naively thought that sendmail used SMTP to send a mail to the local MTA. That's actually not the case for either exim or postfix, which use internal procedures to queue and send the mail. Normally that's not a problem except when sendmail is run by a systemd service. Then the way that processes are spawned to queue and send the mail have to match the service type. In the case of exim, the sending process actually forks from sendmail, which systemd kills before it can run if the service type is set to oneshot. I ended up just writing python script to send the mail via SMTP to the localhost. -- Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
kjo...@o2.pl (Kamil Jońca) writes: [...] > And another question: is it a way to make systemd not to kill background > processes? Sorry for premature question. I just read about KillMode setting. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ "Maybe we can get together and show off to each other sometimes." ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
kjo...@o2.pl (Kamil Jońca) writes: > Lennart Poettering writes: > >> On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: >>> > This didn't work well enough IIRC, but if it did, then it'd provide >>> > almost postfix-like architecture. >>> > >>> > Or just making 'sendmail' send a SIGALRM to the main daemon would do the >>> > job perfectly well, I suspect... >>> >>> But I still does not know, where is the problem, why exim doest not play >>> well with systemd ... >> >> Here's an educated guess: your script terminates, so that that systemd >> decides your service has ended. In such a case it kills any left-over >> processes of the service, and this will include the exim process >> forked off into the bg, because it is attributed to your script's >> context. > I made some tests (ie.add sleep at end of exec line), > and this confirms your explanation. > But ... why this is working as --user service? pure luck? > > KJ And another question: is it a way to make systemd not to kill background processes? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Let us never negotiate out of fear, but let us never fear to negotiate. -- John F. Kennedy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mo, 24.09.18 22:14, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Mon, Sep 24, 2018, 22:13 Kamil Jońca wrote: > > > Lennart Poettering writes: > > > > > On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: > > >> > This didn't work well enough IIRC, but if it did, then it'd > > provide almost postfix-like architecture. > > >> > > > >> > Or just making 'sendmail' send a SIGALRM to the main daemon would do > > the job perfectly well, I suspect... > > >> > > >> But I still does not know, where is the problem, why exim doest not play > > >> well with systemd ... > > > > > > Here's an educated guess: your script terminates, so that that systemd > > > decides your service has ended. In such a case it kills any left-over > > > processes of the service, and this will include the exim process > > > forked off into the bg, because it is attributed to your script's > > > context. > > I made some tests (ie.add sleep at end of exec line), > > and this confirms your explanation. > > But ... why this is working as --user service? pure luck? > > > > Maybe the --user manager doesn't have privileges to kill a setuid-root > process. Precisely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mon, Sep 24, 2018, 22:13 Kamil Jońca wrote: > Lennart Poettering writes: > > > On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: > >> > This didn't work well enough IIRC, but if it did, then it'd > provide almost postfix-like architecture. > >> > > >> > Or just making 'sendmail' send a SIGALRM to the main daemon would do > the job perfectly well, I suspect... > >> > >> But I still does not know, where is the problem, why exim doest not play > >> well with systemd ... > > > > Here's an educated guess: your script terminates, so that that systemd > > decides your service has ended. In such a case it kills any left-over > > processes of the service, and this will include the exim process > > forked off into the bg, because it is attributed to your script's > > context. > I made some tests (ie.add sleep at end of exec line), > and this confirms your explanation. > But ... why this is working as --user service? pure luck? > Maybe the --user manager doesn't have privileges to kill a setuid-root process. > -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Lennart Poettering writes: > On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: >> > This didn't work well enough IIRC, but if it did, then it'd provide >> > almost postfix-like architecture. >> > >> > Or just making 'sendmail' send a SIGALRM to the main daemon would do the >> > job perfectly well, I suspect... >> >> But I still does not know, where is the problem, why exim doest not play >> well with systemd ... > > Here's an educated guess: your script terminates, so that that systemd > decides your service has ended. In such a case it kills any left-over > processes of the service, and this will include the exim process > forked off into the bg, because it is attributed to your script's > context. I made some tests (ie.add sleep at end of exec line), and this confirms your explanation. But ... why this is working as --user service? pure luck? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Beware the new TTY code! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote: > > This didn't work well enough IIRC, but if it did, then it'd provide > > almost postfix-like architecture. > > > > Or just making 'sendmail' send a SIGALRM to the main daemon would do the > > job perfectly well, I suspect... > > But I still does not know, where is the problem, why exim doest not play > well with systemd ... Here's an educated guess: your script terminates, so that that systemd decides your service has ended. In such a case it kills any left-over processes of the service, and this will include the exim process forked off into the bg, because it is attributed to your script's context. Thus the exim queue runner might be forked off, but it wil be immediately terminated by systemd again... It's one of the reasons why exim shouldn't do what it is doing there. Running priv daemon code as forked bg children from differently privileged user code is just a massively bad idea. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Mantas Mikulėnas writes: [...] > > This didn't work well enough IIRC, but if it did, then it'd provide > almost postfix-like architecture. > > Or just making 'sendmail' send a SIGALRM to the main daemon would do the job > perfectly well, I suspect... > > -- > Mantas Mikulėnas But I still does not know, where is the problem, why exim doest not play well with systemd ... KJ -- http://wolnelektury.pl/wesprzyj/teraz/ If you love someone, set them free. If they don't come back, then call them up when you're drunk. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
On Mo, 24.09.18 20:17, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > I am sorry, what? Are you saying there's now a third kind of task? > > real kernel threads, real userspace processes, and weird shit running > > kernel code that in turn runs userspace supplied programs, and all > > that under user control? > > > > No, it is not exactly "user control". It runs executable embedded into > kernel module. So it is not arbitrary code. In this particular case at > least. By "user control" I meant that they are kill()-able by users (kernel threads generally are not). > > Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they > > pass the recently reworked is_kernel_thread() tests? > > No. The flags are 4194560 == 0x400100 == PF_RANDOMIZE|PF_SUPERPRIV. > > And sorry, I cannot comment on "these processes"; I have seen only one > concrete example. I have no idea how widespread use of this facility is. > > > We might want to update killall.c then so that it does not make > > assumptions on /proc/$PID/cmdline validity anymore, but strictly uses > > is_kernel_thread(). That should fix things properly for you, no? That > > way dracut won't even see these new kind processes at all... > > Well, I suppose there could be corner cases when executable and > libraries are from different filesystems, but this better waits for real > life example then. I prepped this PR: https://github.com/systemd/systemd/pull/10159 I think this should fix your issue, could you test? (using PF_KTHREAD checking is more correct anyway, hence regardless this should really be the right way and be merged) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
24.09.2018 19:52, Lennart Poettering пишет: > On Mo, 24.09.18 19:30, Andrei Borzenkov (arvidj...@gmail.com) wrote: > >> 24.09.2018 16:20, Lennart Poettering пишет: >>> On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: >>> Dracut /shutdown script first tries to kill all processes still running off old root. Unfortunately this fails for special user process that runs bpfilter because it does not include reference to /oldroot in places where dracut looks for in kilall_proc_mountpoint() >>> >>> Hmm, when we invoke the /shutdown executable we already executed our >>> process killing spree as part of systemd-shutdown. How come your >>> processes even survive that long? >> >> >> p = procfs_file_alloca(pid, "cmdline"); >> f = fopen(p, "re"); >> if (!f) >> return true; /* not really, but has the desired effect */ >> >> count = fread(, 1, 1, f); >> >> /* Kernel threads have an empty cmdline */ >> if (count <= 0) >> return true; >> >> >> This process is spawned as special kernel thread, even though it is >> otherwise normal user process. > > I am sorry, what? Are you saying there's now a third kind of task? > real kernel threads, real userspace processes, and weird shit running > kernel code that in turn runs userspace supplied programs, and all > that under user control? > No, it is not exactly "user control". It runs executable embedded into kernel module. So it is not arbitrary code. In this particular case at least. > If so, yuck... > > Under which parent PID do they show up? kthreadd or somewhere further > down? > I showed it in original post. 10:~ # ps -ef | fgrep '[none]' root 984 2 0 09:46 ?00:00:00 [none] Yes, this is kthreadd. > Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they > pass the recently reworked is_kernel_thread() tests? > No. The flags are 4194560 == 0x400100 == PF_RANDOMIZE|PF_SUPERPRIV. And sorry, I cannot comment on "these processes"; I have seen only one concrete example. I have no idea how widespread use of this facility is. > We might want to update killall.c then so that it does not make > assumptions on /proc/$PID/cmdline validity anymore, but strictly uses > is_kernel_thread(). That should fix things properly for you, no? That > way dracut won't even see these new kind processes at all... > Well, I suppose there could be corner cases when executable and libraries are from different filesystems, but this better waits for real life example then. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mon, Sep 24, 2018 at 7:51 PM Mantas Mikulėnas wrote: > > > On Mon, Sep 24, 2018, 16:29 Kamil Jońca wrote: > >> Lennart Poettering writes: >> >> > On Mo, 24.09.18 12:04, Mantas Mikulėnas (graw...@gmail.com) 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. > Or just making 'sendmail' send a SIGALRM to the main daemon would do the job perfectly well, I suspect... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
On Mo, 24.09.18 19:30, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 24.09.2018 16:20, Lennart Poettering пишет: > > On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > >> Dracut /shutdown script first tries to kill all processes still running > >> off old root. Unfortunately this fails for special user process that > >> runs bpfilter because it does not include reference to /oldroot in > >> places where dracut looks for in kilall_proc_mountpoint() > > > > Hmm, when we invoke the /shutdown executable we already executed our > > process killing spree as part of systemd-shutdown. How come your > > processes even survive that long? > > > p = procfs_file_alloca(pid, "cmdline"); > f = fopen(p, "re"); > if (!f) > return true; /* not really, but has the desired effect */ > > count = fread(, 1, 1, f); > > /* Kernel threads have an empty cmdline */ > if (count <= 0) > return true; > > > This process is spawned as special kernel thread, even though it is > otherwise normal user process. I am sorry, what? Are you saying there's now a third kind of task? real kernel threads, real userspace processes, and weird shit running kernel code that in turn runs userspace supplied programs, and all that under user control? If so, yuck... Under which parent PID do they show up? kthreadd or somewhere further down? Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they pass the recently reworked is_kernel_thread() tests? We might want to update killall.c then so that it does not make assumptions on /proc/$PID/cmdline validity anymore, but strictly uses is_kernel_thread(). That should fix things properly for you, no? That way dracut won't even see these new kind processes at all... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mon, Sep 24, 2018, 16:29 Kamil Jońca wrote: > Lennart Poettering writes: > > > On Mo, 24.09.18 12:04, Mantas Mikulėnas (graw...@gmail.com) 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
On Mon, 24 Sep 2018 15:20:47 +0200 Lennart Poettering wrote: > On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > Dracut /shutdown script first tries to kill all processes still > > running off old root. Unfortunately this fails for special user > > process that runs bpfilter because it does not include reference > > to /oldroot in places where dracut looks for in > > kilall_proc_mountpoint() > > Hmm, when we invoke the /shutdown executable we already executed our > process killing spree as part of systemd-shutdown. How come your > processes even survive that long? What am I missing? I believe it's because the bpfilter helper process is identified as a kernel thread - since it has an empty command line - and therefore not killed. I personally feel this is a bug (in the kernel), but apparently this whole bpfilter thing isn't quite ready yet and shouldn't be used for the moment -- so hopefully it'll improve/be fixed in the mean time. You can see this thread[1] about the issue. Cheers, [1] https://www.spinics.net/lists/netdev/msg520030.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
24.09.2018 16:20, Lennart Poettering пишет:
> On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
>> Dracut /shutdown script first tries to kill all processes still running
>> off old root. Unfortunately this fails for special user process that
>> runs bpfilter because it does not include reference to /oldroot in
>> places where dracut looks for in kilall_proc_mountpoint()
>
> Hmm, when we invoke the /shutdown executable we already executed our
> process killing spree as part of systemd-shutdown. How come your
> processes even survive that long?
p = procfs_file_alloca(pid, "cmdline");
f = fopen(p, "re");
if (!f)
return true; /* not really, but has the desired effect */
count = fread(, 1, 1, f);
/* Kernel threads have an empty cmdline */
if (count <= 0)
return true;
This process is spawned as special kernel thread, even though it is
otherwise normal user process.
net/bpfilter/bpfilter_kern.c:load_umh():
/* fork usermode process */
err = fork_usermode_blob(_umh_start,
_umh_end - _umh_start,
);
if (err)
return err;
pr_info("Loaded bpfilter_umh pid %d\n", info.pid);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timeout Waiting for Device
On Mo, 24.09.18 10:02, gw1500 (i_was_yah0...@yahoo.com) wrote: > Thanks for the reply. I only have one swap space and obviously I need > it. So the question is, what do I do to fix it. I did not generate those > entries (except the last). They were generated by Anaconda during the > install so I'm afraid to change them. Here is my /etc/fstab: > UUID=11d33833-3e21-4654-8c0f-ab76a73f7de2 swap > swap defaults 0 0 Figure out the right UUID for your swap and correct it in this line. 11d33833-3e21-4654-8c0f-ab76a73f7de2 doesnt appear to be correct as a swap partition with that UUID never appears to show up. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timeout Waiting for Device
On 9/24/2018 9:30 AM, Lennart Poettering wrote: > On Mo, 17.09.18 11:29, gw1500 (i_was_yah0...@yahoo.com) wrote: > >> I don't know the significance of this error when I start my network >> (CentOS 7) but it does not seem to effect anything I've noticed. Can >> someone tell me what this means, what it might effect and how to fix it? >> TIA. >> >> Sep 16 09:34:38 dap002 systemd[1]: Job >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device/start >> timed out. >> Sep 16 09:34:38 dap002 systemd[1]: Timed out waiting for device >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device. >> -- Subject: Unit >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device >> has failed >> -- Defined-By: systemd >> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> -- -- Unit >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device >> has failed. >> -- -- The result is timeout. Sep 16 09:34:38 dap002 systemd[1]: >> Dependency failed for >> /dev/disk/by-uuid/11d33833-3e21-4654-8c0f-ab76a73f7de2. -- Subject: Unit >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap >> has failed -- Defined-By: systemd -- Support: >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> -- -- Unit >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap >> has failed. >> -- -- The result is dependency. Sep 16 09:34:38 dap002 systemd[1]: Job >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap/start >> failed with result 'dependency'. Sep 16 09:34:38 dap002 systemd[1]: Job >> dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device/start >> failed with result 'timeout'. Sep 16 09:34:56 dap002 sudo[32540]: dap : >> TTY=pts/0 ; PWD=/home/dap/Downloads ; USER=root ; COMMAND=/sbin/service >> network status Sep 16 09:35:48 dap002 sudo[306]: dap : TTY=pts/0 ; >> PWD=/home/dap/Downloads ; USER=root ; COMMAND=/bin/bash Sep 16 09:35:48 >> dap002 dbus[704]: [system] Activating service >> name='org.freedesktop.problems' (using servicehelper) Sep 16 09:35:48 >> dap002 dbus[704]: [system] Successfully activated service >> 'org.freedesktop.problems' > It appears you have a swap device configured (most likely in > /etc/fstab) that never shows up. Consider removing it from the > configuration or fixing it. > > Lennart > Thanks for the reply. I only have one swap space and obviously I need it. So the question is, what do I do to fix it. I did not generate those entries (except the last). They were generated by Anaconda during the install so I'm afraid to change them. Here is my /etc/fstab: # # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=98522577-362c-4c09-ae73-23cfbb529cec / ext4 defaults 1 1 UUID=91e1714f-6ee1-467b-a45f-b60e17ad38be /home ext4 defaults 1 2 UUID=38ad10d9-b8bb-49fa-932d-261ed5b5390b /usr ext4 defaults 1 2 UUID=d1c63c52-8ed6-40ed-aa01-19574a507682 /var ext4 defaults 1 2 UUID=11d33833-3e21-4654-8c0f-ab76a73f7de2 swap swap defaults 0 0 //dap003/Public /mnt/dap003 cifs users,_netdev,gid=users,file_mode=0775,dir_mode=0775,credentials=/etc/samba/auth.dap003.DAP 0 0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StandardOutput and StandardError permissions and ownership
On Fr, 21.09.18 23:26, Kamil Jońca (kjo...@o2.pl) wrote: > I have service unit with is run as user news and have redirected > standard output stderr. > ie. > > --8<---cut here---start->8--- > [Service] > User=news > Type=oneshot > StandardOutput=file:%T/use-newsx/%n.out > StandardError=file:%T/use-newsx/%n.err > > --8<---cut here---end--->8--- > But I standard output is owned by root. How can I make it owned by news? > This is template service, so I cannot use /etc/tmpfiles.d - I do not > know file names in advance. This is currently not explicitly supported. Please file an RFE issue on github if you think this would be useful to you. You should be able to make this work without explicit support however. Adding something like this to [Service] should work (untested): ExecStartPre=+/bin/chown news:news /proc/self/fd/1 /proc/self/fd/2 (It's key to specify "+", as that means the chown is invoked with full privs. And this uses the fact that /proc/self/fd/1 and /proc/self/fd/2 are magic paths that refer to the files opened as stdout/stderr) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dbus service
On Di, 18.09.18 15:07, deepan muthusamy (deepan.m2...@gmail.com) wrote: > What is the difference between dbus service and bus-activatable service? That's really a question to ask the D-Bus mailing list, not the systemd one. That said: a dbus service just means a service offering IPC interfaces via dbus. A bus-activatable service is a special kind of dbus service: it means the IPC interfaces are also offered while the service isn't started yet, and a client talking to such an IPC interface will then implicitly trigger starting of that service by doing so. "activatable" is just a fancy word for saying "can be started by", i.e. "triggred on-demand by". By building systems with bus-activatable services you build more robust, simpler and more efficient systems, as services don't have to run all the time, and clients don't have to know when precisely a service is started, but can talk to the service anyway, and rely that the dbus system will implicitly start any service that is not running yet, fully transparently. Examples for such bus-activable services are "policykit" for example, or systemd's own "hostnamed", both of which normally don't run, but when a client wants to talk to them are implicitly started. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timeout Waiting for Device
On Mo, 17.09.18 11:29, gw1500 (i_was_yah0...@yahoo.com) wrote: > I don't know the significance of this error when I start my network > (CentOS 7) but it does not seem to effect anything I've noticed. Can > someone tell me what this means, what it might effect and how to fix it? > TIA. > > Sep 16 09:34:38 dap002 systemd[1]: Job > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device/start > timed out. > Sep 16 09:34:38 dap002 systemd[1]: Timed out waiting for device > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device. > -- Subject: Unit > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device > has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- -- Unit > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device > has failed. > -- -- The result is timeout. Sep 16 09:34:38 dap002 systemd[1]: > Dependency failed for > /dev/disk/by-uuid/11d33833-3e21-4654-8c0f-ab76a73f7de2. -- Subject: Unit > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap > has failed -- Defined-By: systemd -- Support: > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- -- Unit > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap > has failed. > -- -- The result is dependency. Sep 16 09:34:38 dap002 systemd[1]: Job > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.swap/start > failed with result 'dependency'. Sep 16 09:34:38 dap002 systemd[1]: Job > dev-disk-by\x2duuid-11d33833\x2d3e21\x2d4654\x2d8c0f\x2dab76a73f7de2.device/start > failed with result 'timeout'. Sep 16 09:34:56 dap002 sudo[32540]: dap : > TTY=pts/0 ; PWD=/home/dap/Downloads ; USER=root ; COMMAND=/sbin/service > network status Sep 16 09:35:48 dap002 sudo[306]: dap : TTY=pts/0 ; > PWD=/home/dap/Downloads ; USER=root ; COMMAND=/bin/bash Sep 16 09:35:48 > dap002 dbus[704]: [system] Activating service > name='org.freedesktop.problems' (using servicehelper) Sep 16 09:35:48 > dap002 dbus[704]: [system] Successfully activated service > 'org.freedesktop.problems' It appears you have a swap device configured (most likely in /etc/fstab) that never shows up. Consider removing it from the configuration or fixing it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Lennart Poettering writes: > On Mo, 24.09.18 12:04, Mantas Mikulėnas (graw...@gmail.com) 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 -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Samsung Wave to badziewie ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd behavior during shutdown
On Mi, 19.09.18 18:44, Tiwari, Hari Sahaya (hari-sahaya.tiw...@hpe.com) wrote: > HI, > Many thanks for the reply. > > I tried putting DefaultDependencies=false in both .socket & .service files. > I was able to verify that socket was still in "listening" state when my other > systemd service tried to start a new connection with socket. > Also the "Suppressing connection request since unit stop is scheduled" > message is no more seen. > > Now I am getting below error when the new connection is requested. > > Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Incoming traffic > Sep 19 23:31:33 jara1 systemd[1]: > hacl-cfg@6-127.0.0.1:5302-127.0.0.1:63714.service: Trying to enqueue job > hacl-cfg@6-127.0.0.1:5302-127.0.0.1:63714.service/start/replace > Sep 19 23:31:33 jara1 systemd[1]: Requested transaction contradicts existing > jobs: Transaction is destructive. > Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: One connection closed, 1 > left. > Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Failed to queue service > startup job (Maybe the service file is missing or not a non-template unit?): > Transaction is destructive. > Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Changed listening -> failed > > Do I have to set some other parameter in the systemd unit files ? > > Following are the contents of systemd files, > Service File > --- > # cat hacl-cfg@.service > # cat hacl-cfg.socket Any chance you can verify the precise deps of these services in effect with "systemctl show"? (i.e. paste the output of "systemctl show hal-cfg.socket hacl-cfg@foobar.service" somewhere) My educated guess is that some .mount unit you are shutting down ends up being required by the service, and thus you get the conflicting jobs queued... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bpfilter blocks root unmount during shutdown
On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: > Dracut /shutdown script first tries to kill all processes still running > off old root. Unfortunately this fails for special user process that > runs bpfilter because it does not include reference to /oldroot in > places where dracut looks for in kilall_proc_mountpoint() Hmm, when we invoke the /shutdown executable we already executed our process killing spree as part of systemd-shutdown. How come your processes even survive that long? What am I missing? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mo, 24.09.18 12:04, Mantas Mikulėnas (graw...@gmail.com) 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Michael Biebl writes: > Am So., 23. Sep. 2018 um 22:49 Uhr schrieb Kamil Jońca : [...] > > Fwiw, I tried your example service file, works for me. To be clear: Message was delivered at once; not put in queue, and delivered in queue run? KJ -- http://wolnelektury.pl/wesprzyj/teraz/ LordHavoc: I'm already insane. damn straight. or curvy, crooked, or what have you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On Mon, Sep 24, 2018 at 11:35 AM Lennart Poettering wrote: > On So, 23.09.18 22:48, Kamil Jońca (kjo...@o2.pl) wrote: > > > It is something strange with sending mails from systemd system service: > > assume we have service file /etc/systemd/system/mailtest.service: > > > > --8<---cut here---start->8--- > > [Unit] > > Description="Test maili" > > [Service] > > #User=kjonca > > NoNewPrivileges=false > > Type=oneshot > > ExecStart=-zsh -c 'echo xxx|mail news' > > ExecStart=-zsh -c 'echo xxx|mutt -F /dev/null -s subject -e \'set > copy=no\' kjonca' > > --8<---cut here---end--->8--- > > > > When I call > > sudo systemctl start mailtest.service > > Two messages are put in exim queue, but not deliveried immediately. > > Why? What am I missing? > > 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. (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.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Am So., 23. Sep. 2018 um 22:49 Uhr schrieb Kamil Jońca : > > It is something strange with sending mails from systemd system service: > assume we have service file /etc/systemd/system/mailtest.service: > > --8<---cut here---start->8--- > [Unit] > Description="Test maili" > [Service] > #User=kjonca > NoNewPrivileges=false > Type=oneshot > ExecStart=-zsh -c 'echo xxx|mail news' > ExecStart=-zsh -c 'echo xxx|mutt -F /dev/null -s subject -e \'set copy=no\' > kjonca' > --8<---cut here---end--->8--- > > When I call > sudo systemctl start mailtest.service > Two messages are put in exim queue, but not deliveried immediately. > Why? What am I missing? Fwiw, I tried your example service file, works for me. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
Lennart Poettering writes: > On So, 23.09.18 22:48, Kamil Jońca (kjo...@o2.pl) wrote: > >> It is something strange with sending mails from systemd system service: >> assume we have service file /etc/systemd/system/mailtest.service: >> >> --8<---cut here---start->8--- >> [Unit] >> Description="Test maili" >> [Service] >> #User=kjonca >> NoNewPrivileges=false >> Type=oneshot >> ExecStart=-zsh -c 'echo xxx|mail news' >> ExecStart=-zsh -c 'echo xxx|mutt -F /dev/null -s subject -e \'set copy=no\' >> kjonca' >> --8<---cut here---end--->8--- >> >> When I call >> sudo systemctl start mailtest.service >> Two messages are put in exim queue, but not deliveried immediately. >> Why? What am I missing? > > 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. Another puzzle, when I put "strace" in front of mutt - mail is delivered immediately. So it I suspect something with SUID/SGID binaries called from systemd, but I do not know how to check it :( > > 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... Everything works as expected: - mails from cron - mails from fetchmail - mails from "--user" services KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Imagination is more important than knowledge. -- Albert Einstein ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] exim4 only queues mails sent by systemd service
On So, 23.09.18 22:48, Kamil Jońca (kjo...@o2.pl) wrote: > It is something strange with sending mails from systemd system service: > assume we have service file /etc/systemd/system/mailtest.service: > > --8<---cut here---start->8--- > [Unit] > Description="Test maili" > [Service] > #User=kjonca > NoNewPrivileges=false > Type=oneshot > ExecStart=-zsh -c 'echo xxx|mail news' > ExecStart=-zsh -c 'echo xxx|mutt -F /dev/null -s subject -e \'set copy=no\' > kjonca' > --8<---cut here---end--->8--- > > When I call > sudo systemctl start mailtest.service > Two messages are put in exim queue, but not deliveried immediately. > Why? What am I missing? 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... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
