View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006947 | Kali Linux | [All Projects] General Bug | public | 2020-12-25 01:25 | 2022-03-25 13:58 |
| Reporter | L1ghtn1ng | Assigned To | sbrun | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0006947: Redis-Server packaging issues | ||||
| Description | Dec 24 22:02:58 kali systemd[1]: Stopped Advanced key-value store. Dec 24 22:21:58 kali systemd[1]: Starting Advanced key-value store... Dec 24 22:21:58 kali systemd[1]: redis-server.service: Can't open PID file /run/redis/redis-server.pid (yet?) after start: Operation not permitted This seems to be due to the unit file from what has been set in it, this is what I get on my system but on another system it fails to start when using systemctl start redis-server and this is what it spits out in the journal Dec 24 18:59:11 kali redis-server[5696]: *** FATAL CONFIG FILE ERROR (Redis 6.0.9) *** Dec 24 18:59:11 kali redis-server[5696]: Reading the configuration file, at line 260 Dec 24 18:59:11 kali redis-server[5696]: >>> 'logfile /var/log/redis/redis-server.log' Dec 24 18:59:11 kali redis-server[5696]: Can't open the log file: Permission denied The other odd thing is that if you do redis-server /etc/redis/redis.conf it works fine just not with the unit file when doing systemctl start redis-server | ||||
|
|
This bug also breaks openvas |
|
|
This is likely an issue with the systemd unit config shipped by default. Redis will start after setting "ProtectSystem=False" or correcting the ReadWriteDirectories-Entries |
|
|
Upstream issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002738 For me the workaround was to set "ProtectSystem=strict" and to comment out "ReadOnlyDirectories=/". This seems to also be the way systemd recommends protecting the root directory: (manpage systemd.exec) ProtectSystem= Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr/ and the boot loader directories (/boot and /efi) read-only for processes invoked by this unit. If set to "full", the /etc/ directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev/, /proc/ and /sys/ (protect these directories using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used, ReadWritePaths= may be used to exclude specific directories from being made read-only. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below. Defaults to off. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-25 01:25 | L1ghtn1ng | New Issue | |
| 2021-06-30 08:49 | g0tmi1k | Priority | high => normal |
| 2021-12-28 14:48 | JmbFountain | Note Added: 0015573 | |
| 2021-12-28 15:14 | JmbFountain | Note Added: 0015575 | |
| 2021-12-29 08:24 | JmbFountain | Note Added: 0015577 | |
| 2021-12-29 13:17 | sbrun | Assigned To | => sbrun |
| 2021-12-29 13:17 | sbrun | Status | new => assigned |
| 2022-03-25 13:57 | g0tmi1k | Severity | crash => feature |
| 2022-03-25 13:58 | g0tmi1k | Severity | feature => minor |