blob: d9bb3a29079619d038fe62790f7cce240dda45ee (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
+++
date = 2021-10-27T12:46:24+02:00
title = "proc(5) hidepid=2 and systemd"
[taxonomies]
tags = ["TIL", "systemd"]
+++
A couple of days ago I turned on
[`hidepid=2`](https://manpages.debian.org/bullseye/manpages/proc.5.en.html#hidepid)
for the `/proc` mount on my desktop PC. Today I saw the `systemd-userdbd`
service failing on bootup, and realized that it had been failing to start for a
few days. Aside from the fact that there really should be a well-supported and
easy way to notify administrators of failing units, this obviously needed some
investigation.
`systemctl status systemd-userdbd.service` wasn't very helpful, but `journalctl`
had the specific error:
```
[..] spawning /lib/systemd/systemd-userdbd: Read-only file system
```
I didn't immediately jump to the conclusion that this had to do with enabling
`hidepid=2`. After all, why would that result in a read-only file system?
Investigating a failure very early on in boot is a pain, so instead of wasting
my time on that I took to GitHub issues.
As it turns out, `hidepid=` is just
[not supported](https://github.com/systemd/systemd/issues/12955#issuecomment-508490893)
[at all](https://github.com/systemd/systemd/issues/20848#issuecomment-930185888)
in systemd. This doesn't seem to be pointed out anywhere, and I certainly was
not aware of it before. Services can set
[`ProtectProc=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=),
but there doesn't seem to be a clean way of restricting /proc for unprivileged
users like a global `hidepid=2` did. I've removed the option for now.
|
