Bug 1518916

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.

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.

It's easily configured with the following drop-in:

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

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?

(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.

(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?

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.