3

I am trying to install the GitLab community package on a Debian Stretch system, but one of its dependencies, redis-server, fails to install when starting the service using systemd.

Complete log:

$ sudo dpkg --configure redis-server
Setting up redis-server (3:3.2.5-4) ...
Job for redis-server.service failed because the control process exited with error code.
See "systemctl status redis-server.service" and "journalctl -xe" for details.
invoke-rc.d: initscript redis-server, action "start" failed.
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Thu 2016-12-15 15:00:17 UTC; 31ms ago
 Docs: http://redis.io/documentation,
       man:redis-server(1)
  Process: 8764 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=227/NO_NEW_PRIVILEGES)
  Process: 8761 ExecStartPre=/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d (code=exited, status=227/NO_NEW_PRIVILEGES)
 Main PID: 24283 (code=exited, status=227/NO_NEW_PRIVILEGES)

Dec 15 15:00:17 Serverdatorn-Debian systemd[1]: redis-server.service: Unit entered failed state.
Dec 15 15:00:17 Serverdatorn-Debian systemd[1]: redis-server.service: Failed with result 'exit-code'.
dpkg: error processing package redis-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 redis-server

Starting redis-server by running the executable manually works perfectly:

$ sudo /usr/bin/redis-server /etc/redis/redis.conf
$ sudo tail /var/log/redis/redis-server.log
...
* The server is now ready to accept connections on port 6379

If there is any other information you want me to provide, please tell me.

EDIT:

I tried setting NoNewPrivileges to both yes and no in the redis.service file, reloading and starting it again, but no luck, same error. I did find that running journalctl -xe showed another message that might be helpful: 

redis-server.service: Failed at step NO_NEW_PRIVILEGES spawning /usr/bin/redis-server: Invalid argument
Improve this question

5 Answers 5

Reset to default
1

I would guess you are running into this result of the systemd NoNewPrivileges= directive. Assuming that the redis-server package generally works Ubuntu 16.04 systems, this suggests that your system may custom global settings for NoNewPrivileges= or a related directive that's causing Redis to fail to start.

Read the docs linked about about NoNewPrivileges= and the related directives, then search in your /etc/systemd/ directory to see if any of those values have been customized on your system. If not, confirm that the redis package you are installing is indeed supported on the operating system version you are installing it on.

Improve this answer
1
  • 1
    At first when I tried this, it didn't work. I tried it just now, and all of sudden, it works. I can now install the package and everything.
    – Tankernn
    Commented Jan 16, 2017 at 17:22
1

This has been raised as a Debian bug, back in December 2017, but the bug was closed without a service fix. If you have the details that Chris Lamb requested, please supply them.

A similar problem was reported for Debian's MariaDB 10.1 package back in July 2017, which was closed without fix when the package was removed from Debian.

A local fix is to change the service's settings to be 

NoNewPrivileges=no
PrivateDevices=no

Do not edit /etc/systemd/system/redis.service or /usr/lib/systemd/system/redis-server.service directly. The latter is not supposed to be hand-edited by local administrators at all, and the former isn't the actual service unit file that comes with the Debian package.

Instead use systemctl edit redis.service to create a unit drop-in file and put the settings there. This also does a daemon-reload implicitly, which one would have to do by hand if one were modifying unit files by hand.

For those trying to find this in the source package: The packaged redis.service and [email protected] files are generated by a Debian program called generate-systemd-service-files.

This is one of several problems that people have had with use of systemd's restriction mechanisms in the service units that are generated and packaged by the Debian people. Others are that its ProtectHome=yes setting stops a symbolically linked /home from working, in a launchpad bug, and that its ReadOnlyDirectories=/ setting yields a 226/NAMESPACE error code, in a StackOverflow Q&A. The local fix takes the same form for all, a drop-in unit file with a setting override.

Further reading

Improve this answer
0

You can set PrivateDevices=false in the systemd service file to get it working.

Improve this answer
1
  • You are right, however, need to do systemctl daemon-reload to make it effective.
    – fcm
    Commented May 15, 2019 at 15:49
0

I do a resume:

You need to add to the /etc/systemd/system/redis.service file the follow lines:

NoNewPrivileges=no

PrivateDevices=no

After uncounted times I found that corrections works.

Improve this answer
0

In my case I was running old Linux kernel from previous Debian version and couple of services failed to start with "(code=exited, status=227/NO_NEW_PRIVILEGES)" error. For example:

ExecStart=/lib/systemd/systemd-logind (code=exited, status=227/NO_NEW_PRIVILEGES)

Installing current distribution kernel with sudo apt-get install linux-image-amd64 && reboot fixed my problem.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .