Files and services

/usr/local/bin/pss

Executable file.

/opt/pss/config/pss.properties

Global settings, logs, folder paths and so on. After making changes, restart the service.

/opt/pss/config/pss.json

Main settings file. Created and updated automatically. At startup the service attempts to load precisely this file.

/opt/pss/config/pss_back.json

Backup copy of the previous working configuration. Saved automatically by the Restore settings action in the web interface and used as the first fallback if the main pss.json cannot be parsed.

/opt/pss/config/pss_default.json

Default settings file. Shipped with the package and applied as the last fallback if neither the main pss.json nor pss_back.json can be loaded. It is also the source of the working pss.json created at the very first start: the file sets the web interface port 8808 and the admin / admin account.

/opt/pss/config/bad/

Archive of corrupted pss.json files. If the main settings file cannot be parsed at startup, it is moved here with a name of the form pss_YYYYMMDD_HHMMSS.json. The directory is created automatically. For more details, see the Behavior at startup and on configuration errors section.

/opt/pss/data

Data storage folder. Created and updated automatically. Can be changed in the global settings file.

/usr/lib/systemd/system/pss.service

systemd unit file for the service.

/var/log/pss

Log output folder. Can be changed in the global settings file.

The service name is pss. Runs as the pss user.

During installation, the accompanying aksusbd package from the protection system is installed; it includes the hasplmd and aksusbd services.

Behavior at startup and on configuration errors

At startup, the service sequentially attempts to load the settings files from the /opt/pss/config folder:

  1. pss.json — main settings file.

  2. pss_back.json — backup copy of the previous working configuration.

  3. pss_default.json — default settings shipped with the package.

The first file loaded successfully is used. If all three files are missing or corrupted, the service starts with empty settings; in that case a manual edit of the administrative password and a restart are required.

Structurally corrupted settings file. If pss.json contains a JSON syntax error, unknown keys, an incorrect value type, or a uniqueness violation (for example, two streams with the same id), the service moves the corrupted file to the /opt/pss/config/bad/ archive under the name pss_YYYYMMDD_HHMMSS.json (the startup date and time). After that, the service continues its loading attempts in the usual order and re-saves the working configuration to pss.json from pss_back.json or pss_default.json. The details (the key name, the error description, the file name in the archive) are written to the operation log.

Only the main pss.json ends up in the archive. The pss_back.json and pss_default.json files are not archived when corrupted — the log entries are sufficient for diagnostics, and the files themselves remain in place and can be corrected manually.

If, at the time of the next load, a file with the same timestamp already exists in /opt/pss/config/bad/ (for example, on quick restarts within the same second), it is overwritten.

Numeric values outside the allowed range. If a numeric value in the settings file is less than the minimum allowed or greater than the maximum allowed for that parameter, the service does not discard the whole file. Instead, a warning is written to the log stating the parameter name, the value read, and the applied bound, and the value itself is clamped to the nearest allowed range boundary (the minimum or the maximum). After loading completes, the service automatically re-saves pss.json with the corrected values, so on the next startup these warnings no longer appear.

This behavior applies only during the initial loading of the settings file. When settings are changed through the web interface or the external API, values outside the allowed range are still rejected with an error — without automatic correction.