Rsync spawns new logins

I have a client with a poor internet connection. I use rsync to backup the files to a remote machine.
Every time the internet connection times out, ssh creates a new login, without causing the original login to close. Eventually, the machine runs out of user licenses.
This is a problem with SCO, where user licenses are limited, whereas with most Linux distributions this is not a problem.
We use passwordless login so the problem is not discovered until a user tries to log in the following morning.
Is this a known problem?

Which is the SCO? The client or the remote backup machine?

Both are SCO. The remote machine initiates the job to receive data from the "host". The multiple logins accumulate on the host.

Not being a SCO person, assume SCO has /etc/ssh/sshd_config and you can modify these configuration params:

ClientAliveInterval 
ClientAliveCountMax

Also, I put your question to our hallucinating AI friend, and it replied:

ChatGPT 4o

Yes, this is a known problem — particularly on systems like SCO Unix or SCO OpenServer, which enforce strict per-user license limits. When rsync over SSH is used across unstable or lossy connections, and the remote end hangs or doesn't detect the disconnection properly, zombie SSH sessions may remain active. Over time, this exhausts the per-user login license quota, blocking new logins.

OODA LOOP

1. Observe (Facts)

• SCO Unix uses per-user license enforcement (often via licensemgr, osr5.0.7, or osr6 systems).
• rsync over SSH creates a new shell login on each run.
• Unclean connection drops can leave SSH sessions in a defunct or idle state (ps will show them).
• These sessions accumulate because they don’t clean up on timeout/disconnect.
• Unlike most modern Linux systems, SCO systems treat each SSH login as consuming a license slot, even if no terminal is attached.

2. Orient (Context)

• This is not a bug in rsync or ssh per se — it’s a consequence of how SCO enforces user logins and how it handles dead SSH processes.
• Many sysadmins hit this when using automated or batch SSH jobs on SCO.
• Linux distros don’t enforce such licensing, so this doesn't become visible until used on legacy UNIX.

3. Decide (Best Option)

Mitigation depends on how aggressively you want to solve it:

Short-term workaround:

• Add a ClientAliveInterval and ClientAliveCountMax in the remote SSHD config to kill idle connections.
• Add a logout-cleaner script via cron or similar to kill stale sshd and rsync processes.

Long-term solution:

• Use rsync over a persistent connection (e.g. autossh, matar or muxed ControlMaster session).
• Use rsh (legacy and insecure, but doesn’t count against SSH logins).
• Switch to a push model from the client side if possible.

4. Act (What to Do)

Fix 1: SSH timeout cleanup on SCO box
Edit /etc/ssh/sshd_config:

ClientAliveInterval 60
ClientAliveCountMax 2

Then:

# Restart SSHD
/etc/init.d/sshd restart

This causes SSHD to kill idle connections after 2 minutes of no client activity.

Fix 2: Kill idle SSH processes daily
Add to root's crontab:

# Clean out idle SSH sessions (adjust threshold as needed)
0 * * * * /usr/bin/kill -9 $(ps -eo pid,etime,comm | awk '$3=="sshd" && $2 ~ /[0-9]-|[3-9][0-9]:/ {print $1}')

Fix 3: Use autossh to maintain a single multiplexed tunnel
On the client machine:

autossh -M 0 -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 2" -o "ControlMaster=auto" -o "ControlPath=~/.ssh/cm-%r@%h:%p" user@remotehost
rsync -e "ssh -o ControlPath=~/.ssh/cm-%r@%h:%p" ...

Let me know if you want a wrapper script or cron-based workaround for automating cleanup of dead sessions.

I have already written a script to kill all the errant processes.
I spoke with the client and found that there has been a competing backup from another server for the available internet bandwidth. Hopefully with better scheduling, and getting a complete data set on the target machine, there will be less traffic and fewer problems.
By the way, a console login will override the user limit.