Fixed
Created: Aug 1, 2024
Updated: Aug 29, 2024
Resolved Date: Aug 29, 2024
Found In Version: 10.22.33.2
Fix Version: 10.22.33.18
Severity: Standard
Applicable for: Wind River Linux LTS 22
Component/s: Userspace
When using xinet.d to limit rsync connections, it can't handle changes in system time due to its timestamps being stored in absolute form.
When time is set back, the connection limit is reached very quickly and rsync gets deactivated, if time is changed again, rsync is never reactivated.
This was found during testing where time changes were necessary but it is relevant in normal usage due to daylight savings imposed time changes.
Setup project with:
--machines intel-x86-64
Edit local.conf and add:
IMAGE_INSTALL_append = " rsync"
Build image:
$ bitbake wrlinux-image-small
Deploy to target and connect to network.
On the target, configure rsync server, edit /etc/rsyncd.conf:
test]
path = /
comment = Everything - for testing purposes only
Create xinet.d rsync service file at /etc/xinetd.d/rsync:
service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
}
Configure xinet.d by editing /etc/xinetd.conf:
cps = 50 10
instances = 100
per_source = 100
Restart xinetd:
$ systemctl restart xinetd
Lastly, disable ntp:
$ timedatectl set-ntp 0
On another machine, create generate-rsync-load.sh but don't run it yet:
#!/bin/bash
while : ; do
for i in {1..25}; do ( sleep $(perl -e "print 1-0.01*$i") ; /usr/bin/rsync --timeout=5 --stats -vvvvvv rsync://<TARGET-IP>/test/etc/passwd /test/file/path ) & >/dev/null ; done
sleep 1;
done
Back on the target, first set the time to a consistent starting point
$ date -s "Tue Feb 27 13:56:50 UTC 2024"
Start monitoring xinet.d in another terminal:
$ tail -f /var/log/daemon.log ( grep Deactivating
At roughly the same time, run generate-rsync-load.sh and change the time on the target:
$ date -s "Tue Feb 27 19:56:50 UTC 2024"; sleep .5; date -s "Tue Feb 27 13:56:50 UTC 2024"; sleep .5; date -s "Tue Feb 27 19:56:50 UTC 2024"
Normally, given the rsync request load, the limit will not be hit unless the target's time is changed, at that point you will see:
xinetd[70832): Deactivating service rsync due to excessive incoming connections. Restarting in 10 seconds.
Note that in between tests, xinetd must be restarted and the time set back to the starting point ("Tue Feb 27 13:56:50 UTC 2024"), this ensures consistency between runs.
Setup project with:
--machines intel-x86-64
Edit local.conf and add:
IMAGE_INSTALL_append = " rsync"
Build image:
$ bitbake wrlinux-image-small
Deploy to target and connect to network.
On the target, configure rsync server, edit /etc/rsyncd.conf:
test]
path = /
comment = Everything - for testing purposes only
Create xinet.d rsync service file at /etc/xinetd.d/rsync:
service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
}
Configure xinet.d by editing /etc/xinetd.conf:
cps = 50 10
instances = 100
per_source = 100
Restart xinetd:
$ systemctl restart xinetd
Lastly, disable ntp:
$ timedatectl set-ntp 0
On another machine, create generate-rsync-load.sh but don't run it yet:
#!/bin/bash
while : ; do
for i in {1..25}; do ( sleep $(perl -e "print 1-0.01*$i") ; /usr/bin/rsync --timeout=5 --stats -vvvvvv rsync://<TARGET-IP>/test/etc/passwd /test/file/path ) & >/dev/null ; done
sleep 1;
done
Back on the target, first set the time to a consistent starting point
$ date -s "Tue Feb 27 13:56:50 UTC 2024"
Start monitoring xinet.d in another terminal:
$ tail -f /var/log/daemon.log ( grep Deactivating
At roughly the same time, run generate-rsync-load.sh and change the time on the target:
$ date -s "Tue Feb 27 19:56:50 UTC 2024"; sleep .5; date -s "Tue Feb 27 13:56:50 UTC 2024"; sleep .5; date -s "Tue Feb 27 19:56:50 UTC 2024"
Normally, given the rsync request load, the limit will not be hit unless the target's time is changed, at that point you will see:
xinetd[70832): Deactivating service rsync due to excessive incoming connections. Restarting in 10 seconds.
Note that in between tests, xinetd must be restarted and the time set back to the starting point ("Tue Feb 27 13:56:50 UTC 2024"), this ensures consistency between runs.