Description of problem: After some days, my tftp server is dead. Does not help, if there is automatic restart planned in systemd (may be this is an systemd bug too). Version-Release number of selected component (if applicable): tftp-server-5.2-15.fc22.x86_64 systemd-219-21.fc22.x86_64 How reproducible: dayly/weelky Steps to Reproduce: 1. systemctl start tftp 2. transfer (download) at least one file from this server (not sure if required) 3. wait some days 4. systemctl status tftp Actual results: ● tftp.service - Tftp Server Loaded: loaded (/usr/lib/systemd/system/tftp.service; indirect; vendor preset: disabled) Drop-In: /etc/systemd/system/tftp.service.d └─restart.conf Active: inactive (dead) Docs: man:in.tftpd Expected results: running tftp service Additional info: I have this content in restart.conf: [Service] Restart=always But service is still dead. Looks like there are 2 bugs: 1. tftp server is dying 2. systemd doesn't restart tftp server Same problem on multiple machines, so I think this is reproducible.
I think that systemd is automatically shutting down the connection if it's not needed (i.e. is idle for some time). Since the service is socket activated, it really doesn't affect the service functioning. Zbyszek, could you please comment?
But my problem is not that service is dead, but that tftp doesn't respond to tftp client requests. Tftp is not functioning after it's in dead state.
Systemd would not shut down the server on it's own, even if it's idle. So it must be some other reason. I suspect that the socket is getting closed for some reason, and Restart=always in the service unit has no effect. Can you paste the output from 'journalctl -u tftp.service -u tftp.socket'?
Here are last messages from journal: aug 10 13:35:55 work.salstar.sk systemd[1]: Started Tftp Server. aug 10 13:35:55 work.salstar.sk systemd[1]: Starting Tftp Server... aug 10 13:50:56 work.salstar.sk systemd[1]: tftp.service holdoff time over, scheduling restart. aug 10 13:50:56 work.salstar.sk systemd[1]: Started Tftp Server. aug 10 13:50:56 work.salstar.sk systemd[1]: Starting Tftp Server... aug 10 14:05:56 work.salstar.sk systemd[1]: tftp.service holdoff time over, scheduling restart. aug 10 14:05:56 work.salstar.sk systemd[1]: Started Tftp Server. aug 10 14:05:56 work.salstar.sk systemd[1]: Starting Tftp Server... aug 10 14:17:03 work.salstar.sk systemd[1]: Stopping Tftp Server... aug 10 14:20:05 work.salstar.sk systemd[1]: Closed Tftp Server Activation Socket. aug 10 14:20:05 work.salstar.sk systemd[1]: Stopping Tftp Server Activation Socket. [root@work ~]# systemctl status tftp ● tftp.service - Tftp Server Loaded: loaded (/usr/lib/systemd/system/tftp.service; indirect; vendor preset: disabled) Drop-In: /etc/systemd/system/tftp.service.d └─restart.conf Active: inactive (dead) Docs: man:in.tftpd [root@work ~]# As you see, tftp is again in dead state. I think it has been restarted yesterday, but may be I am wrong.
Hm, could you turn on debugging with: systemctl-analyze set-log-level debug and than let it run for a while... It will show what happens (e.g. if systemd think the process has exited, etc.).
Unable to reproduce this, but after reboot, my tftp service is always dead. How I can debug systemd boot? [root@ftp ~]# systemctl status tftp.service tftp.socket ● tftp.service - Tftp Server Loaded: loaded (/usr/lib/systemd/system/tftp.service; indirect; vendor preset: disabled) Drop-In: /etc/systemd/system/tftp.service.d └─restart.conf Active: inactive (dead) Docs: man:in.tftpd ● tftp.socket - Tftp Server Activation Socket Loaded: loaded (/usr/lib/systemd/system/tftp.socket; enabled; vendor preset: disabled) Active: active (listening) since Pi 2015-10-09 07:41:28 CEST; 10h ago Listen: [::]:69 (Datagram) okt 09 07:41:28 ftp.upjs.sk systemd[1]: Listening on Tftp Server Activation .... okt 09 07:41:28 ftp.upjs.sk systemd[1]: Starting Tftp Server Activation Socket. Hint: Some lines were ellipsized, use -l to show in full.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.