Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #173474
| From | Henrique de Moraes Holschuh <hmh@debian.org> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Script vs command line behaviour |
| Date | 2016-10-14 02:50 +0200 |
| Message-ID | <srYRb-2nn-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <srs4W-56s-21@gated-at.bofh.it> <srseB-5aq-1@gated-at.bofh.it> <srsxY-5Bl-17@gated-at.bofh.it> <srsHD-5Fa-7@gated-at.bofh.it> <srB8e-30B-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, 13 Oct 2016, Mark Fletcher wrote: > but I don't completely understand what you mean. Are you saying that, > even though the command to start fetchmail is not an invokation of a > systemd unit, the fact that it is happening from inside a script that is > run by a systemd unit somehow allows systemd to capture the PID for > fetchmail, and that that in turn is having a bearing on my being able to Yes. try "ps xawf -eo pid,user,cgroup:64,args" to see how things are grouped into "cgroups" by systemd (or by the kernel autogroup facility, or by cgmanager on systemd-less systems, etc). Depending on how the systemd unit is configured, systemd will kill everything belonging to that unit's cgroup when you tell it to stop the unit. You can have an unit start processes in a separate cgroup (so they don't get killed along with the unit), refer to the systemd-run command. There are other ways to deal with this as well, and they might be more idiomatic. I was waiting for someone that groks systemd better to reply, but since nobody did, here is an workable answer to get you started :-) -- Henrique Holschuh
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 14:40 +0200
Re: Script vs command line behaviour Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-12 14:50 +0200
Re: Script vs command line behaviour Frédéric Marchal <frederic.marchal@wowtechnology.com> - 2016-10-12 15:30 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 15:50 +0200
Re: Script vs command line behaviour Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-12 16:00 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 16:20 +0200
Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-12 16:30 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 17:10 +0200
Re: Script vs command line behaviour Darac Marjal <mailinglist@darac.org.uk> - 2016-10-12 17:20 +0200
Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-12 17:20 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 16:50 +0200
Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-13 17:00 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-14 01:10 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:30 +0200
Re: Script vs command line behaviour Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-14 02:50 +0200
Re: Script vs command line behaviour Gene Heskett <gheskett@shentel.net> - 2016-10-12 16:40 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 17:20 +0200
Re: Script vs command line behaviour Frank <zuiderduin@gmx.com> - 2016-10-12 18:00 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:20 +0200
Re: Script vs command line behaviour Andre Majorel <aym-naibed@teaser.fr> - 2016-10-15 11:50 +0200
Re: Script vs command line behaviour Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-15 15:50 +0200
Re: Script vs command line behaviour Jude DaShiell <jdashiel@panix.com> - 2016-10-12 23:00 +0200
Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:00 +0200
csiph-web