Linux MID Server fails to restart when using non-root user during upgrade - Support and Troubleshooting

Linux MID Server fails to restart when using non-root user during upgrade .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Issue This article applies to Linux MID Servers configured to run as a non-root user ( RUN_AS_USER ).

The following issues may be observed:

MID Server upgrade fails or does not complete successfully. MID Server goes down during upgrade and does not come back up automatically. Operations triggered from the instance, such as Upgrade , Rekey , and Validate actions , fail to execute successfully. The MID Server remains in a Down state until manually started from the host machine when performing Rekey and Invalidate/Validate . The restart command does not perform any action. Manual restart using systemctl fails with an Access denied error when executed by the non-root user. The MID Server only starts successfully when executed with elevated privileges (for example, using sudo ). Solution Note: The following steps involve operating system level configuration changes and should be performed by a system administrator, as they depend on the specific environment configuration and security policies.

Perform the following steps:

1. Identify the MID Server service user Run: systemctl cat

Note: The default service name is mid.service , but this may vary based on configuration.

Look for: User= . This is the user running the MID Server.

2. Verify PolicyKit (polkit) is available Run: pkaction --version

Expected output: pkaction version

Example: pkaction version 125

3. Install polkit (if not present) If the above command does not return a version, install polkit based on your Linux distribution:

Amazon Linux 2023 / RHEL / CentOS: sudo dnf install polkit -y

Ubuntu / Debian: sudo apt-get install policykit-1 -y

Note: Ensure polkit is installed by your system administrator if required.

After installation, verify again: pkaction --version

4. Start polkit service Check for polkit service or socket:

systemctl status polkit.socket

If the socket exists:

sudo systemctl enable polkit.socket sudo systemctl start polkit.socket

If the socket does not exist, use:

sudo systemctl start polkit.service

5. Configure polkit rule Create a polkit rule to allow the MID Server user to manage the systemd service.

Create the file:

/etc/polkit-1/rules.d/00-midserver.rules

Option A: User-based rule (recommended)

Use this option if you are managing permissions directly for a specific MID Server user identified in Step 1.

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.systemd1.manage-units" && subject.user == " " && action.lookup("unit") == " ") { return polkit.Result.YES; } }); Option B: Group-based rule

Use this option if you are managing MID Server users through a common group (for example, when multiple MID Servers run on the same host using different users).

Ensure all MID Server users are part of a common group (for example, midservergrp ), then use the following rule:

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.systemd1.manage-units" && subject.isInGroup("midservergrp") && action.lookup("unit") == " ") { return polkit.Result.YES; } }); Note:

Replace with the MID Server service user identified in Step 1. Replace with your service name (default is mid.service ). For group-based configuration, ensure the MID Server user is added to the specified group. After adding the rule, restart polkit:

sudo systemctl restart polkit.service

Validate by running the following as the MID Server user:

systemctl restart

The command should execute successfully without requiring sudo or prompting for a password.

After applying the above configuration and restarting the polkit service, the MID Server should be able to restart successfully without requiring elevated privileges. The MID Server upgrade process should complete successfully, and actions such as Restart, Rekey, and Validate initiated from the instance should work as expected.