I'm trying to better understand a behavior I see - I took control of a server that had TFTP running and am trying to turn it off. I've already ran:

systemctl stop tftp

systemctl stop xinetd

However, when stopping the tftp service it says

Warning: Stopping tftp.service, but it can still be activated by: tftp.socket

ss -lnpu afterwards gives me

UNCONN      0      0                             :::69                                        
:::*                   users:(("systemd",pid=1,fd=60))

I checked and the port is indeed still listening, but the PID is listed as systemd? I don't understand the behavior - how is TFTP being run directly by systemd?

Edit: I figured out there was another "service" called tftp.socket running that kept the socket open after I killed the tftp.service. What I still don't understand is why this shows up as being part of the systmed pid.


The tftp-server is started to handle a tftp request. As log as there is no such request, systemd does not start the tftp server. But there needs to be a process that listens to the incoming request on port 69, otherwise that request lands in the bitbucket.

That process is systemd.

When a requests on port 69 comes in, systemd forks-off a tftp server to handle the request. When the tftp server is finished, it just dies.

| improve this answer | |
  • In other words, systemd behaves just like the xinetd service which OP mentioned... – user1686 Jul 26 '19 at 16:43
  • Did he? The only mentioning of xinetd in the question that I have seen is that he used systemctl stop xinetd. But then, the OP edited the question, so he might have taken it out before I read it. – Ljm Dullaart Jul 26 '19 at 17:52
  • You're correct - I'm not using xinetd. I just stopped it. The only change I made with the edit is the indicated. – Grant Curell Jul 27 '19 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.