# Why do my ThinLinc sessions get killed when I restart or upgrade the agent service?

**URL:** <https://community.thinlinc.com/t/why-do-my-thinlinc-sessions-get-killed-when-i-restart-or-upgrade-the-agent-service/2076>\
**Category:** Knowledge Base\
**Created:** [14 September 2026 11:08 UTC](https://community.thinlinc.com/t/why-do-my-thinlinc-sessions-get-killed-when-i-restart-or-upgrade-the-agent-service/2076 "2026-09-14T11:08:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![wilsj](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/wilsj/32/554_2.png) [@wilsj](https://community.thinlinc.com/u/wilsj)\
**Post date:** [14 September 2026 11:08 UTC](https://community.thinlinc.com/t/why-do-my-thinlinc-sessions-get-killed-when-i-restart-or-upgrade-the-agent-service/2076/1 "2026-09-14T11:08:55Z")

</div>

Restarting `vsmagent.service`, or upgrading ThinLinc, is supposed to leave running sessions uninterrupted. Every so often we get a question in our support channels from someone whose experience contradicts this, usually during their first upgrade. They stop the agent expecting sessions to carry on, but instead every session on the server are terminated alongside `vsmagent.service`.

The cause is where the session processes are living. `vsmagent.service` starts each session. The session itself and the desktop environment begin as children of the agent service, inside its cgroup. With systemd’s default `KillMode=control-group`, stopping the service kills everything still in that cgroup, sessions included.

The recommended arrangement is for each session to be registered with `systemd-logind` as its own login session, which moves it into a separate scope under `user.slice`, independent of the agent. The PAM module `pam_systemd` does this: when ThinLinc opens the PAM session at login, `pam_systemd` hands it to `logind` and the session is migrated out of the agent’s cgroup, so restarting the agent leaves it alone.

ThinLinc’s PAM configuration normally points at your existing `sshd` stack, which on a standard systemd distribution already loads `pam_systemd`, so this works out of the box almost everywhere. It only bites when the inherited stack doesn’t load it. For example:

- A hardened or hand-edited PAM profile.
- A stripped image where the PAM module or `logind` is missing.
- Configuration management (Ansible, Puppet, and similar) enforcing an outdated PAM template that overwrites the distribution’s default and drops `pam_systemd`.

To check a running session on the agent:

```auto
cat /proc/$(pgrep -n Xvnc)/cgroup

```

A healthy session shows `.../session-N.scope` under `user.slice`; one still inside `system.slice/vsmagent.service` is the problem in one line. `loginctl list-sessions` should also list the user. If it doesn’t, `pam_systemd` isn’t in the stack ThinLinc is using, and adding it back (as your distribution configures it for its own login services) is the fix.

If you’ve hit this on a particular distribution or PAM setup, feel free to share below.