Clear orphan user sessions in SyteLine

Short answer

When a SyteLine client crashes or loses its network connection, the session record can be left behind, frozen. It still counts as a login, and can still hold a licence. Clear it on the Session Management form: find the user's old session, check it isn't using any licence modules, and delete it. Never delete sessions where the User Name is $service. Those belong to TaskMan and other services, and deleting one stops that service monitoring its configuration. To stop orphans building up, set the Minutes to close orphan sessions process default, then restart the IDO Runtime Service. SyteLine then closes unresponsive sessions on its own.

Why orphan sessions happen

Normally each user has one session. Infor gives two reasons why a user can end up with more:

Abnormal endings. A client crash or a dropped network connection, such as a VPN drop or a laptop closed mid-session, leaves the earlier session frozen. The server never heard that the user left.
Multiple logins. Some users are allowed to sign in more than once, with an unlimited licence or as a multi-session user.

The first kind is the problem. The frozen session sits there until someone, or something, removes it, and it can tie up a licence the business is paying for.

How to clear one safely

Open Session Management.
Find the user's sessions. If there's more than one, the frozen one is usually the oldest, from before the crash or disconnection the user reported.
Check licence usage first. Select the session and click License Module Usage. This opens License Modules per User Connection. Infor's guidance: a session using no licence modules is likely inactive and can be safely deleted.
Tick the session in the Selected column. Use Select All only if you've checked every row.
Click Delete Selected Sessions.
Ask the user to sign in again and confirm everything works.

Button names vary slightly between versions. The steps above follow Infor's documentation for SyteLine 10.

If you delete a session that was still active, the user's screen doesn't close straight away, but their next action that talks to the server fails with an error. They should close SyteLine and sign back in. Nothing is damaged, but it's an unpleasant surprise in the middle of order entry, so check before deleting.

The one rule: never delete $service sessions

Session Management also lists sessions belonging to TaskMan and other SyteLine services. Their User Name is $service.

Infor's warning is clear: don't delete them unless you're certain they're unused. Deleting one removes the IDO runtime's connection information, ends that service's session, and stops the service monitoring that configuration. In practice, background work that relies on it stops being picked up. Reports and scheduled tasks pile up in the queue, as described in SyteLine report stuck in WAITING.

If it does happen on-premises, the system administrator will need to restart the affected service on the server so it re-establishes its session. Check Active Background Tasks afterwards to confirm work is moving again.

The simplest protection is a habit: filter out $service before you select anything.

Stop orphans building up: Minutes to close orphan sessions

SyteLine can clean up for you. Two process defaults work together:

Process default	What it does
Client minutes to ping session	How often a client sends a "ping" to show it's still connected
Minutes to close orphan sessions	How long a session can go without a ping before SyteLine closes it

If Minutes to close orphan sessions has no value, orphan sessions are never closed automatically. That's the situation at many sites.

To turn it on:

Open Process Defaults and set Minutes to close orphan sessions to a sensible value. Start with something comfortably longer than your ping interval, for example 60 minutes, then adjust.
Restart the IDO Runtime Service. The new value doesn't take effect until you do. On-premises, the system administrator does this at a quiet time.
Delete the existing orphans by hand in Session Management. Sessions that were orphaned before the restart aren't cleaned up automatically.

Two things to know:

Sessions with work still running aren't closed. If a session has a process running through the IDO layer, SyteLine leaves it alone. That's what you want.
Don't set it too low. A very short value risks closing sessions on slow or briefly interrupted connections, such as shop-floor Wi-Fi or remote users.

Crash Recovery: the big hammer

SyteLine also has a Crash Recovery utility. It's not a way to clear one stuck user:

It ends the sessions of every user except the person running it.
It unlocks all locked functions and journals.
It's meant mainly for after a utility server crash. After a database server crash it isn't needed, because the database does this itself on restart.

Infor's own warning is not to run it against a database that users are still using. For one user, use Session Management. For stuck locks, use Unlock Locked Functions or Unlock Locked Journals. See SyteLine "Locked" message.

While you're on Process Defaults:

Browser inactivity lock minutes: locks an idle browser session until the user re-enters their password. 0 means never.
User inactivity threshold: disables user accounts that haven't been used for a set number of days. 0 means never. It's useful for the leaver problem in the SyteLine security audit.

On multi-tenant cloud

In multi-tenant CloudSuite Industrial you can still use Session Management, but you can't restart services. If changing Minutes to close orphan sessions needs a service restart, or a $service session has been deleted by mistake, raise it with Infor support.

Good habits

Filter out $service first, every time.
Check License Module Usage before deleting.
Turn on Minutes to close orphan sessions so this becomes rare, not a daily task.
Keep Crash Recovery for actual crashes.

FAQ

How do I clear a stuck user session in SyteLine?

Open Session Management, find the user's frozen session, check License Module Usage shows no modules in use, select it, and delete it. The user then signs in again.

Why does SyteLine say a user is still logged in after a crash?

The crash or dropped connection left the old session frozen. It stays until it's deleted in Session Management, or closed automatically if Minutes to close orphan sessions is set.

What happens if I delete a $service session in SyteLine?

The service, such as TaskMan, loses its IDO session and stops monitoring that configuration, so background work stops being picked up until the service is restarted. Don't delete $service sessions.

How do I make SyteLine close orphan sessions automatically?

Set the Minutes to close orphan sessions process default, restart the IDO Runtime Service, and delete any existing orphans by hand.