Bug 38281

Summary: altlinux-kmsg-loglevel fails in unprivileged containers
Product: Sisyphus Reporter: Arseny Maslennikov <arseny>
Component: systemdAssignee: Alexey Shabalin <shaba>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: arseny, shaba, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   

Description Arseny Maslennikov 2020-03-26 18:32:26 MSK
Юнит переходит в состояние failed в окружениях, в которых его бессмысленно пытаться запускать.

/bin/dmesg -n $LOGLEVEL вызывает klogctl(8, NULL, 3):

# strace -e trace=syslog dmesg -n 3
syslog(8 /* SYSLOG_ACTION_CONSOLE_LEVEL */, NULL, 3 /* LOGLEVEL_ERR */) = -1 EPERM (Operation not permitted)
dmesg: klogctl failed: Operation not permitted
+++ exited with 1 +++

man:klogctl(2) says:

All commands except 3 and 10 require privilege.  In Linux kernels before 2.6.37, command types 3 and 10 are allowed to unprivileged processes; since Linux 2.6.37, these commands are allowed to unprivileged processes only if /proc/sys/kernel/dmesg_restrict has the value 0. Before  Linux  2.6.37, "privileged"  means  that  the  caller  has  the  CAP_SYS_ADMIN  capability. Since Linux 2.6.37, "privileged" means that the caller has either the CAP_SYS_ADMIN capability (now deprecated for this purpose) or the (new) CAP_SYSLOG capability.

В достаточно непривилегированном lxc-контейнере таких капов нет.
Более того, если их выдать, dmesg всё равно работать не будет.

Предлагаю дописать туда в секцию [Unit]:
ConditionCapability=CAP_SYSLOG
ConditionCapability=|CAP_SYS_ADMIN

и, возможно:
ConditionVirtualization=!container

или предотвратить срабатывание сервиса в окружениях без доступа к /bin/dmesg -n $number как-то лучше.