Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518916 - Please consider adding "KillMode=process" to the "[Service]" section of the default systemd unit file for xinetd. [NEEDINFO]
Summary: Please consider adding "KillMode=process" to the "[Service]" section of the d...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xinetd
Version: 7.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1477664 1630908 1630917 1643104
TreeView+ depends on / blocked
 
Reported: 2017-11-29 18:27 UTC by Thomas Gardner
Modified: 2019-03-28 14:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-28 14:04:22 UTC
kwalker: needinfo? (thgardne)


Attachments (Terms of Use)

Description Thomas Gardner 2017-11-29 18:27:12 UTC
Description of problem:

User is complaining that when they do a "service restart" for xinetd in RHEL6, it would simply restart xinetd without killing everything that xinetd started (like telnet login sessions and the like), but in RHEL7 (i.e. systemd) everything xinetd started gets killed.  Well, adding a "KillMode=process" to the "[Service]" section of the default systemd unit file should make this behave the way the user wants it to, but is that the right thing to do?  I don't know what all the possible implications are, you I'm asking y'all to give it a think and decide if there's a downside to that or not.  I don't think there is, but then again, I've been wrong before, and I'm sure I'll be wrong again.

Comment 1 Jan Synacek 2017-11-30 06:15:25 UTC
The best thing to do would be to convert the xinetd service files into systemd units and stop using xinetd, as it is just an added layer that doesn't have to be there. Systemd does much better job managing services. If they really insist on using xinetd, the can try adding the KillMode=process into the service file, but I'm not sure if that will behave the same as in RHEL6. I don't see a reason why that would be a wrong thing to do.

I'd rather not touch xinetd functionality anymore if it's not really necessary.

Comment 2 Thomas Gardner 2017-12-04 16:29:24 UTC
The customer is aware that they could make the services they are managing with xinetd be managed with systemd unit files instead.  They want to use xinetd, for whatever reason, though.  The truth is that for whatever reason, we've chosen to include support for xinetd in RHEL7.  If we didn't want to support it, we should have simply never supported it.  We are where we are now, though, so if we're going to support it, we need to support it.  We can't just say we support it, and then turn around and say, well, you shouldn't use it....

Now, in RHEL6, a restart of xinetd did not kill all processes that can trace their lineage back through xinetd.  In RHEL7, it does.  If we're going to claim backward compatibility, we need to fix the fact that it now does.  I believe adding "KillMode=process" to the "[Service]" section of the default systemd unit file for xinetd should do that, but I could be wrong.  If you've got another idea for getting it to behave the same way, by all means, go ahead and propose a different approach.

Comment 3 Jan Synacek 2018-02-28 11:20:47 UTC
It's easily configured with the following drop-in:

# cat /etc/systemd/system/xinetd.service.d/killmode.conf 
[Service]
KillMode=process

Comment 4 Thomas Gardner 2018-02-28 16:23:37 UTC
Yes, you _can_ do that.  In fact, that's what I'm asking you to do by default, so that it works the way it always has.  Why should each and every user who comes across this problem have to figure that out for themselves, each time, over and over again, instead of just letting it work the way it always has (literally, for the better part of half a century it has had the behavior this change would give back to them).

Can you at least give a reasonable explanation as to why the new behavior is desired?

Comment 5 Jan Synacek 2018-04-09 08:54:26 UTC
(In reply to Thomas Gardner from comment #4)
> Can you at least give a reasonable explanation as to why the new behavior is
> desired?

We (xinetd/systemd maintainers) didn't think about every possible combination of new behaviour before RHEL-7.0 was released, that's simply not possible. That's why the xinetd behaves like it does. I can switch the default, it's easy. I don't want to do that, since it might affect services running via xinetd in an incompatible way that I can't think of right now, and also don't know how to test for, and I don't want to switch the behaviour in RHEL-7.6, because: 1) the "workaround" is trivial, 2) it's very late for such changes. Besides, nobody complained throughout the entire RHEL-7 lifetime. The reason is probably 1), or they don't care.

Comment 6 Thomas Gardner 2018-04-09 21:29:21 UTC
(In reply to Jan Synacek from comment #5)
> (In reply to Thomas Gardner from comment #4)
> > Can you at least give a reasonable explanation as to why the new behavior is
> > desired?
> 
> We (xinetd/systemd maintainers) didn't think about every possible
> combination of new behaviour before RHEL-7.0 was released, that's simply not
> possible. That's why the xinetd behaves like it does. I can switch the
> default, it's easy.

Please do.

>                     I don't want to do that, since it might affect services
> running via xinetd in an incompatible way that I can't think of right now,

Incompatible with what?  The way it has worked in RHEL for the last,
oh, year or two?  You are making the default behavior of xinetd
incomplatable with how it has worked for decades.

> and also don't know how to test for, and I don't want to switch the
> behaviour in RHEL-7.6, because: 1) the "workaround" is trivial,

The workaround is trivial.  I pointed it out at the begining of this
bug.  What is not trivial is figuring out what the workaround is if
you're a customer and suddenly realize you have this problem.  I have
also pointed this out.

>                                                                 2) it's very
> late for such changes.

It may be late, but it is not too late.

>                        Besides, nobody complained throughout the entire
> RHEL-7 lifetime.

This statement is demonstrably false.  The entire RHEL-7 lifetime is
not over, and I have pointed out a complaint to you.

>                  The reason is probably 1), or they don't care.

This customer cares.  Do you?

My original question to which you were responding in your last update
was:  "Can you at least give a reasonable explanation as to why the
new behavior is desired?"  Although you responded to the question (and
by "responded" I mean that you quoted the question and then went on
to write many words that were completely unrelated to the question),
you didn't actually answer it, so I'll ask it again:  Can you at least
give a reasonable explanation as to why the new behavior is desired?

Comment 8 Lukáš Nykrýn 2019-03-28 14:04:22 UTC
This would be a huge change in the behaviour and we can't guarantee that there is no customer depending on the current one. Since there is an easy workaround (just create a drop-in with KillMode=process), engineering management prefers to close this as WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.