Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#824931: openbsd-inetd: systemctl stop inetd kills all children of inetdx
17 views
Skip to first unread message
Marc Lehmann
May 21, 2016, 8:50:04 AM5/21/16
to
Package: openbsd-inetd
Version: 0.20140418-2
Severity: important
Dear Maintainer,
while backing up a failing disk, I tried to take down inetd to avoid
logins/connections form outside interfering with the the data rescue
operation.
I used this command:
systemctl stop inetd
this unexpectedly not only killed inetd, but also all remote shells (which
means the cp that was labouring for hours to copy a big faile form a disk
was also interrupted...) and other services started via inetd. This is a
serious regression compared to pre-systemd behaviour.
-- System Information:
Debian Release: 8.4
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.3-040503-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages openbsd-inetd depends on:
ii init-system-helpers 1.22
ii libbsd0 0.7.0-2
ii libc6 2.22-7
ii libwrap0 7.6.q-25
ii lsb-base 4.1+Debian13+nmu1
ii tcpd 7.6.q-25
ii update-inetd 4.43
openbsd-inetd recommends no packages.
openbsd-inetd suggests no packages.
-- no debconf information
Version: 0.20140418-2
Severity: important
Dear Maintainer,
while backing up a failing disk, I tried to take down inetd to avoid
logins/connections form outside interfering with the the data rescue
operation.
I used this command:
systemctl stop inetd
this unexpectedly not only killed inetd, but also all remote shells (which
means the cp that was labouring for hours to copy a big faile form a disk
was also interrupted...) and other services started via inetd. This is a
serious regression compared to pre-systemd behaviour.
-- System Information:
Debian Release: 8.4
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.3-040503-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages openbsd-inetd depends on:
ii init-system-helpers 1.22
ii libbsd0 0.7.0-2
ii libc6 2.22-7
ii libwrap0 7.6.q-25
ii lsb-base 4.1+Debian13+nmu1
ii tcpd 7.6.q-25
ii update-inetd 4.43
openbsd-inetd recommends no packages.
openbsd-inetd suggests no packages.
-- no debconf information
Marco d'Itri
May 21, 2016, 9:10:02 AM5/21/16
to
On May 21, Marc Lehmann <debian-r...@plan9.de> wrote:
> this unexpectedly not only killed inetd, but also all remote shells (which
> means the cp that was labouring for hours to copy a big faile form a disk
> was also interrupted...) and other services started via inetd. This is a
> serious regression compared to pre-systemd behaviour.
It is different... I am not sure yet about which semantic is better as
> this unexpectedly not only killed inetd, but also all remote shells (which
> means the cp that was labouring for hours to copy a big faile form a disk
> was also interrupted...) and other services started via inetd. This is a
> serious regression compared to pre-systemd behaviour.
the default.
Can you better describe your setup? Which kind of shells were you
spawning from inetd?
If you want to restore the old behaviour right now then you can use:
mkdir /etc/systemd/system/cron.service.d/
echo KillMode=process > /etc/systemd/system/cron.service.d/local.conf
--
ciao,
Marco
Marco d'Itri
May 21, 2016, 3:00:02 PM5/21/16
to
On May 21, Marc Lehmann <sch...@schmorp.de> wrote:
> The semantic that debian used before and is used by similar programs (such
> as sshd) is obviously the right one - killing everything that was ever
> started directly or indirectly from inetd is obviously wrong?
I am not sure: if I stop inetd then I want to stop all running daemons,
not just prevent new connections.
> > Can you better describe your setup? Which kind of shells were you
> > spawning from inetd?
> Anything gets killed, not just shells - I can start a screen session with
> e.g. "nohup gzip" inside, log out, and systemctl stop inetd
> kills screen, the shell inside, gzip etc.
Yes, this is the whole point of KillMode=control-group.
But how do you start from inetd and then get a shell? Are you starting
sshd from inetd?
It looks like your setup is a bit unusual, since nobody has noticed this
since before jessie was released.
--
ciao,
Marco
> The semantic that debian used before and is used by similar programs (such
> as sshd) is obviously the right one - killing everything that was ever
> started directly or indirectly from inetd is obviously wrong?
I am not sure: if I stop inetd then I want to stop all running daemons,
not just prevent new connections.
> > Can you better describe your setup? Which kind of shells were you
> > spawning from inetd?
> e.g. "nohup gzip" inside, log out, and systemctl stop inetd
> kills screen, the shell inside, gzip etc.
Yes, this is the whole point of KillMode=control-group.
But how do you start from inetd and then get a shell? Are you starting
sshd from inetd?
It looks like your setup is a bit unusual, since nobody has noticed this
since before jessie was released.
--
ciao,
Marco
Marc Lehmann
May 22, 2016, 2:30:02 AM5/22/16
to
On Sat, May 21, 2016 at 08:47:57PM +0200, Marco d'Itri <m...@Linux.IT> wrote:
> I am not sure: if I stop inetd then I want to stop all running daemons,
> not just prevent new connections.
Then the package should implement it - interactive login sessions and screen
> I am not sure: if I stop inetd then I want to stop all running daemons,
> not just prevent new connections.
sessions are not daemons.
In any case, the new behaviour overturns decade of correct behaviour for
no reason other than "I prefer to kill everything". It also doesn't match
the behaviour of the rest of debian - if I login via standalone ssh and
then restart sshd, it's not expected that every daemon and every shell and
every process ever started via ssh will be killed.
> > Anything gets killed, not just shells - I can start a screen session with
> > e.g. "nohup gzip" inside, log out, and systemctl stop inetd
> > kills screen, the shell inside, gzip etc.
> Yes, this is the whole point of KillMode=control-group.
> But how do you start from inetd and then get a shell? Are you starting
> sshd from inetd?
gives a shell. Most unix services offerring interactive shell go via
inetd. I also stated ftp as another example, which is not a shell.
This is not at all unusual - debian even has two different rlogin/rsh
implementations, and multiple telnetd daemons.
> It looks like your setup is a bit unusual, since nobody has noticed this
> since before jessie was released.
inetd, and that is quite common. Besides, unusual setups should work just
as well, and did, in older releases or wiht sysvinit.
In either case, I don't understand why it is so hard to fix a simple
regression bug - jessie works when used with sysvinit, as well as polder
releases of debian.
There should be a good reason for introducing breakage like this. Personal
preference for your personal setup is not a good reason.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / sch...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
0 new messages