HomeDefectsLIN1022-10245
Fixed

LIN1022-10245 : xinet.d can't handle system time changes

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

Description

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.

Steps to Reproduce

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.