Changing Usergroup of asd process under systemd

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

Changing Usergroup of asd process under systemd

Warning

Do not configure /etc/systemd/system/aerospike.service.d/user.conf as outlined below on Aerospike Server 4.5.3.2 or newer.
One unexpected possibility would be Failed Assertion on insufficient privileges to switch user to X
Upgrade to Aerospike Server 4.5.3.2 or newer to prevent having to perform these additional steps.

Problem Description

When using the configuration (aerospike.conf) user and group stanza, the effects do not take place at all. The asd process still runs as root.

Explanation

Using standard sysVinit (/etc/init.d/) startup (as well as upstart), asd process daemonizes. This means it performs a double-fork (fork new process, detach from and terminate current). This is a standard procedure under linux. During this double-forking, aerospike forks a new asd process with the selected user/group. This is how this user/group selection works.

Under systemd, this does not happen. Systemd expects the asd process to remain in the foreground and output its logging to stdout, so that journald can take care of the log dispatch. As such, asd allows for this behaviour using the following process parameter: --fgdaemon

The output of ps will show asd process parameters as follows under systemd:

/usr/bin/asd --config-file /etc/aerospike/aerospike.conf --fgdaemon

As the asd daemon stays in the foreground, not detaching from the current stdout/stderr/stdin pipes, outputting logs to stdout, as per systemd design → it does not fork. Since asd does not fork, it cannot change its own user/group it runs under. This results in asd process running under whatever user systemd starts it under - by default ‘root’.

Solution

Systemd allows you to specify the user/group under which a process should be run in an addon configuration to it, as follows (change aerospike to the chosen user/group to run under. Note that the user/group MUST resolve in PAM - i.e. MUST exist!):

cat > /etc/systemd/system/aerospike.service.d/user.conf <<EOF
[Service]
User=aerospike
Group=aerospike
EOF

Keywords

ASD SYSTEMD USER GROUP

Timestamp

10/27/17