1

We have a nodejs based server that is configured to be launched by systemd and on our dev server new versions are deployed via continuous integration. The issue we have is that a non-root user can not restart the application using the systemctl command, so we are curious how we should approach the problem?

The command we tried:

sudo systemctl start my-nodejs-server

And the contents of the systemd script:

[Unit]
Description=NodeJS Based Server

[Install]
WantedBy=multi-user.target

[Service]
User=myserver-user
Group=myserver-userh
Environment=ENV=production NODE_ENV=production
WorkingDirectory=/home/myserver-user/my-nodejs-server/
#ExecStart=/home/myserver-user/my-nodejs-server/scripts/appctl.sh restart
ExecStart=/usr/bin/node lib
Restart=on-failure

I have also tried the following command, as suggested:

systemctl --user start my-nodejs-server

but I get the following:

Failed to connect to bus: No such file or directory

Any ideas?

We are running on Ubuntu 16.

Andre M
  • 443

1 Answers1

2

For my needs a 'system unit file' is needed, rather than a 'user unit file' (see here), since the latter lives in the user's home directory and is only for programs that are meant to run for the duration of a login session.

The solution I ultimately went with is described in the following answer:

How could we allow non-root users to control a system.d service?

Essentially you give the user sudo privileges for running specific commands. Here it is:

myserver-user ALL= NOPASSWD: /bin/systemctl start my-nodejs-server
myserver-user ALL= NOPASSWD: /bin/systemctl stop my-nodejs-server
myserver-user ALL= NOPASSWD: /bin/systemctl restart my-nodejs-server

Note that if you want to apply this privilege to a group, then use a percentage symbol in front of the identifier so:

%myserver-group ALL= NOPASSWD: /bin/systemctl start my-nodejs-server
%myserver-group ALL= NOPASSWD: /bin/systemctl stop my-nodejs-server
%myserver-group ALL= NOPASSWD: /bin/systemctl restart my-nodejs-server

Also, based on the referenced answer, I'll probably change the deployment user to be deployment, or something similar, to avoid the deployment user being the same one that is running the application.

Andre M
  • 443