Description of problem: (been meaning to post this for a while) Since start of fc25, something has changed in that rwhod now reliably sends out info claiming to be 'localhost' instead of the real host name of the device. This only seems to happen if DHCP is used, probably due to changes in the systemd startup behaviour, and the way NetworkManager works. This worked fine in fc24 and prior. Version-Release number of selected component (if applicable): rwho-0.17-56.fc24.x86_64 (NB: I'm on fc25; looks like rwhod hasn't been updated) How reproducible: 100% on a desktop using DHCP Steps to Reproduce: 1. start desktop with rwhod and DHCP client (NetworkManager) enabled 2. wait a few minutes 3. rwho or ruptime on some other host on the LAN Actual results: Note you see your desktop mentioned as 'localhost' in rwho or ruptime output, or you don't see it at all as some other host has since sent out a similarly bogus broadcast as 'localhost' Expected results: see your desktop's host name, not 'localhost' Additional info: workaround is to restart rwhod after it starts and is on the network systemctl restart rwhod Suggested fix is to have rwhod not broadcast if the host name is 'localhost' and do a gethostname() repeatedly, so it starts working when NetworkManager has done the DHCP initialization
Hi Ian, thanks for reporting this! I have not tried to reproduce this yet but from what I can see the issue might lie with rwhod not waiting until the network configuration is completed. Can you try modifying your rwhod service file so that its unit section looks like this: [Unit] Description=Remote Machine Logged In User Lister Requires=network.target Wants=network-online.target After=syslog.target network-online.target So using `network-online.target` instead of just `network.target` while also pulling it as a dependency.
That change seems to work and would fix it for the localhost case which is probably the most common; it wouldn't necessarily fix it for the case where the DHCP server handed out a different IP after the system leased one at startup. Not worth fixing that case IMHO; probably pretty rare, if not impossible unless the DHCP server lost its mapping and restarted. So your fix should suffice. # diff rwhod.service.dist rwhod.service 4c4,5 < After=syslog.target network.target --- > Wants=network-online.target > After=syslog.target network-online.target Let me know when your suggested change hits rpm testing stage and I'll test it. Thanks Ian D
Curiously, on fc22 the systemd rwho.service file is the same as on fc25, so something else must have changed in the startup sequence to trigger this issue.
Thanks for testing out the patch, I am glad it fixed the issue for you. Pushed into git for F25 and later: http://pkgs.fedoraproject.org/cgit/rpms/rwho.git/commit/?id=1a579ce682e226702b895217f0ac1585fc553109 Builds should hit updates-testing in a few days.
rwho-0.17-57.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e91f4d5bcf
rwho-0.17-58.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-82346f7374
rwho-0.17-57.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e91f4d5bcf
rwho-0.17-58.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-82346f7374
rwho-0.17-58.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
rwho-0.17-57.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Reopening... I've done a fresh-kickstart of fc26 with this version of rwho and all updates and unfortunately the fix isn't working. $ ls -l /etc/systemd/system/multi-user.target.wants/rwhod.service lrwxrwxrwx. 1 root root 37 Aug 1 16:13 /etc/systemd/system/multi-user.target.wants/rwhod.service -> /usr/lib/systemd/system/rwhod.service $ cat /etc/systemd/system/multi-user.target.wants/rwhod.service [Unit] Description=Remote Machine Logged In User Lister Requires=network.target Wants=network-online.target After=syslog.target network-online.target [Service] Type=forking ExecStart=/usr/sbin/rwhod StandardError=syslog [Install] WantedBy=multi-user.target $ rpm -q rwho rwho-0.17-58.fc26.x86_64 $ uptime 13:39:38 up 2:31, 2 users, load average: 0.01, 0.03, 0.00 $ ps -ef|grep rwho root 872 1 0 11:08 ? 00:00:00 /usr/sbin/rwhod root 873 872 0 11:08 ? 00:00:00 /usr/sbin/rwhod # strace -f -p 873 ... sendto(3, "\1\1\0\0Y\202\232\324\0\0\0\0localhost\0\0\0\0\0\0\0\0\0\0\0"..., 108, 0, {sa_family=AF_INET, sin_port=htons(513), sin_addr=inet_addr("192.168.122.255")}, 16) = 108 sendto(3, "\1\1\0\0Y\202\232\324\0\0\0\0localhost\0\0\0\0\0\0\0\0\0\0\0"..., 108, 0, {sa_family=AF_INET, sin_port=htons(513), sin_addr=inet_addr("192.168.41.255")}, 16) = 108 hostname isn't localhost though... its the correct value, via DHCP IP assignment and reverse DNS lookup. So maybe plan B is required after all... have rwhod not broadcast if the hostname part of gethostname() is 'localhost'.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Adjusting to fc26 ...
issue still present in fresh install of fc27 rwho-0.17-60.fc27.x86_64
issue still present in fresh install of fc28 rwho-0.17-61.fc28.x86_64 note that my kickstart did this as a potential help for this issue (and similar ypbind startup race condition) systemctl enable NetworkManager-wait-online.service I have this in /etc/rc.local as a workaround, which seems to work, mostly: (sleep 60; systemctl restart rwhod) &
(In reply to Ian Donaldson from comment #15) > note that my kickstart did this as a potential help for this > issue (and similar ypbind startup race condition) > > systemctl enable NetworkManager-wait-online.service network-online.target pulls in NetworkManager-wait-online.service as a "wants" dependency (does not fail if its not available). We cannot depend on NetworkManager-wait-online.service in rwho since not every installation chooses to use NetworkManager - some users choose to have it disabled. Not sure if there is much more we can do from the side of rwho, seems more like a configuration issue now (enabling NetworkManager-wait-online.service).
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.