nfs-server daemonset messes up host tty #961

Activity

1. WanzenBug commented on Feb 27, 2026

   

   WanzenBug

   on Feb 27, 2026

   Member

   More actions

   The nfs-server daemonset currently has its getty systemd units enabled and has privileged access. This means that it could read/write to system tty devices. And it will fight with host system getty service (if any) and render the terminals completely unusable.

   That does sound bad and we should mitigate this.

   We could get away with disabling getty from the pod systemd configuration but I feel running systemd in a privileged container is such a bad idea even though we have cap_drop set to all. Things like this just don't need caps to happen since privileged still gives access to any device nodes owned by root (which is almost all of them)

   In short term, this will probably be what we need to do.

   I feel Piraeus needs to use nfs-ganesha instead of the in-kernel nfs server. This mitigates the complexity of adding another host-kernel-subsystem manager (on top of drbd) and avoids a lot of the headaches that running systemd here might introduce.

   It already does. The reason we use systemd is because we internally use DRBD Reactor. See also here. And systemd still adds value in this case, orchestrating starts and stops in the correct order. And cricitcally, monitoring that the ganesha instance is actually running.
2. chaserhkj commented on Feb 27, 2026

   

   chaserhkj

   on Feb 27, 2026

   Author

   More actions

   We could get away with disabling getty from the pod systemd
   In short term, this will probably be what we need to do.

   Agreed, this is the fastest mitigation.

   I feel Piraeus needs to use nfs-ganesha instead of the in-kernel nfs server.
   It already does.

   Oh I wasn't aware of that. Good to know since this clears any concern that kernel space nfsd is not namespace-aware enough.

   The reason we use systemd is because we internally use DRBD Reactor.

   I am not very familiar with DRBD system details but isn't the satellite pods running DRBD reactor as an extra app container as well? In other words systemd might not be needed for this purpose?

   And systemd still adds value in this case, orchestrating starts and stops in the correct order. And cricitcally, monitoring that the ganesha instance is actually running.

   So systemd is actually used as a process supervisor here. I feel that we might be mis-configuring systemd in some way since systemd explicitly said that it won't do anything about VTs or multiple getty on VTs when running in a container (ref, see Section "Execution Environment" paragraph 5), in the long term one solution is just to fix this behavior

   Or we could use other means of process supervision, like supervisord.

   But I feel the most kubernetes-native way would be to add a sidecar container to provide a liveness probe for ganesha. If start order needs to be managed, kubernetes can put sidecar containers in initContainers section with restartPolicy: always and use startup probes to signal synchronization points. (see this)
3. rck

   closed this as completedin linstor-csi#417on Mar 2, 2026
4. lexfrei

   added a commit that references this issue on Oct 29, 2026

   fix(linstor): update piraeus-operator to v2.10.7

   ...

   1c6c6bd
5. lexfrei

   added 5 commits that reference this issue on Nov 12, 2026

   fix(linstor): update piraeus-operator to v2.10.7

   ...

   49865e3

   fix(linstor): update piraeus-operator to v2.10.7

   ...

   9b3ad0a

   fix(linstor): update piraeus-operator to v2.10.7

   ...

   03dd779

   fix(linstor): update piraeus-operator to v2.12.1

   ...

   0bc115c

   fix(linstor): update piraeus-operator to v2.12.1

   ...

   acfae30