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
logindis 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:
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.