Inspect and Prune Mono ASP.NET Sessions with dbsessmgr4

You will use dbsessmgr4 to inspect the Mono ASP.NET session database and remove sessions that have expired. It can also remove every session at once, but only when you have deliberately accepted that consequence. Allow about fifteen minutes for a read-only check and longer if you need to arrange a database backup. This guide describes the mono-xsp4 package version 4.2-2.5 installed on this machine. Its manual page identifies the program as dbsessmgr4 4.2.

The first two commands below are ordinary checks. Editing the package configuration, taking a database backup and running the deletion operations require a suitable database account; editing the installed file normally also requires sudo. Do not start with --remove. It deletes all sessions and can log every user out at once.

1. Check the installed command and configuration

The Debian package provides a small wrapper which runs the executable with Mono. Confirm both the wrapper and the configuration file beside the executable:

$ command -v dbsessmgr4
/usr/bin/dbsessmgr4
$ dpkg-query -W -f='${Package} ${Version}\n' mono-xsp4
mono-xsp4 4.2-2.5
$ ls -l /usr/lib/xsp/4.0/dbsessmgr4.exe /usr/lib/xsp/4.0/dbsessmgr4.exe.config

The wrapper runs /usr/lib/xsp/4.0/dbsessmgr4.exe, so this is the configuration file that matters when you invoke dbsessmgr4. The executable reads the file named dbsessmgr4.exe.config next to itself. A different copy of the executable can therefore use a different adjacent configuration file, but changing an arbitrary file in your current directory will not change the packaged command.

Checkpoint: if either path is missing, stop and repair the package installation through your normal package-management process. Do not create a replacement executable or configuration file in /usr/bin.

2. Understand the database settings before changing them

The manual documents four application settings. They select the provider assembly, the connection type, the connection string and the SQL parameter prefix:

<configuration>
  <appSettings>
    <add key="DBProviderAssembly" value="Npgsql" />
    <add key="DBConnectionType" value="Npgsql.NpgsqlConnection" />
    <add key="DBConnectionString"
         value="SERVER=127.0.0.1;USER ID=SESSION_USER;PASSWORD=SESSION_PASSWORD;dbname=SESSION_DB" />
    <add key="DBParamPrefix" value=":" />
  </appSettings>
</configuration>

Use a real database role and database name from your ASP.NET session-state deployment. The values above are placeholders, not credentials to copy. The package configuration on this machine contains the provider, type and connection string settings but does not contain an explicit DBParamPrefix entry. Read the installed file before changing it and preserve the syntax used by your provider.

Connection strings contain secrets. Keep the configuration readable only by the account that needs it, and avoid pasting it into tickets or shell history. A change to this file is persistent and may affect the next session-database operation, so make a root-owned backup before editing:

$ sudo cp --preserve=all /usr/lib/xsp/4.0/dbsessmgr4.exe.config \
    /usr/lib/xsp/4.0/dbsessmgr4.exe.config.before-dbsessmgr4

This backup is the recovery point for the configuration, not for deleted session rows. If the edit is wrong, restore it with the following command after checking the paths carefully:

$ sudo cp --preserve=all /usr/lib/xsp/4.0/dbsessmgr4.exe.config.before-dbsessmgr4 \
    /usr/lib/xsp/4.0/dbsessmgr4.exe.config

3. Test access with a read-only display

--show displays session data and does not request either deletion operation. Run it only after the configuration points at the intended database:

$ dbsessmgr4 --show
<session data from the configured database>

The exact rows and formatting depend on the installed program and database contents. Treat the output as sensitive: session data can include identifiers or application values. Redirect it only to a protected location, and remove that copy through your organisation's approved data-retention process when it is no longer needed.

On this machine, running dbsessmgr4 --show with the package's current unusable provider setup exits with status 1 and a Mono NullReferenceException from DbSession.GetConnection. That is a connection or provider setup failure, not evidence that the database contains no sessions. Check the assembly, connection type, connection string, database reachability and provider installation before retrying. Do not respond to this error by running --remove.

Checkpoint: a useful smoke test is a successful command exit status, followed by a deliberate review of the displayed data. Capture the status immediately:

$ dbsessmgr4 --show
$ status=$?
$ printf 'dbsessmgr4 exit status: %s\n' "$status"
dbsessmgr4 exit status: 0

If the output includes an error or the status is non-zero, stop here. The deletion commands are not troubleshooting commands.

4. Remove only expired sessions

Once --show works and you have confirmed the target database, --clean removes all expired sessions:

$ dbsessmgr4 --clean
$ printf 'cleanup exit status: %s\n' "$?"
cleanup exit status: 0

The manual promises removal of expired sessions, but it does not specify a row count or a completion message. A zero exit status tells you that the command completed; it is not a portable count of deleted rows. This operation changes the database and may affect applications that still expected to recover an expired session, so run it in an agreed maintenance window if the application has unusual session behaviour.

There is no undo option in dbsessmgr4. If you need recovery, restore the affected database from your database backup using your database team's documented procedure. The configuration backup from step 2 cannot restore session records.

5. Treat --remove as a maintenance event

--remove deletes all sessions, including sessions that have not expired:

$ dbsessmgr4 --remove

Do not run this as a routine cleanup or combine it with an unreviewed deployment script. It can sign out every active user and may discard workflow state. Before using it, warn affected users, confirm the database target, take a tested database backup and record the rollback procedure. There is no command-line undo. If the operation is accidental, stop further writes and contact the database operator immediately rather than trying another dbsessmgr4 option.

6. Keep the session server and database manager separate

dbsessmgr4 manages the database-backed session store. It is not the out-of-process session server. The related asp-state4 command serves session state over the state-server protocol, normally configured with a stateConnectionString such as tcpip=server:port. Do not substitute one for the other when diagnosing an ASP.NET application's session mode.

Likewise, changing DBConnectionString changes where the manager operates, but it does not configure an application's web.config. Review the application's session-state mode separately before maintenance. A successful cleanup against the wrong database is still an operational failure.

Done means