I get this error: # systemctl status systemd-sysctl.service ● systemd-sysctl.service - Apply Kernel Variables Loaded: loaded (/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2017-12-25 01:32:00 CET; 10h ago Docs: man:systemd-sysctl.service(8) man:sysctl.d(5) Process: 299 ExecStart=/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE) Main PID: 299 (code=exited, status=1/FAILURE) dic 25 01:32:00 dell-2017 systemd[1]: Starting Apply Kernel Variables... dic 25 01:32:00 dell-2017 systemd-sysctl[299]: Couldn't write 'fq_codel' to 'net/core/default_qdisc': Input/output error dic 25 01:32:00 dell-2017 systemd-sysctl[299]: Couldn't write '1' to 'kernel/sysrq', ignoring: No such file or directory dic 25 01:32:00 dell-2017 systemd[1]: systemd-sysctl.service: Main process exited, code=exited, status=1/FAILURE dic 25 01:32:00 dell-2017 systemd[1]: systemd-sysctl.service: Failed with result 'exit-code'. dic 25 01:32:00 dell-2017 systemd[1]: Failed to start Apply Kernel Variables. The usage of fq_codel needs to have NET_SCH_FQ_CODEL enabled... I am not sure if it's a really hard requirement but, in any case, that switch is being forced by # Fair Queue CoDel packet scheduler to fight bufferbloat net.core.default_qdisc = fq_codel in /usr/lib/sysctl.d/50-default.conf I guess that upstream wants us to enable it as, otherwise, they should have made it behave similar to sysrq switch... that is ignored when not found
I don't think this setting is critical, and the error can be ignored (by us). > I guess that upstream wants us to enable it as, otherwise, they should have made it behave similar to sysrq switch... that is ignored when not found Not sure what you mean by that. How is sysrq handled differently?
On the other hand, it would be easy to add a kernel check and enable it in gentoo-sources by default. Sound reasonable?
It is different because sysrq error doesn't end up with the service exiting with "1" status (the error is "ignored"), while fq_codel does Yeah, for me adding the check would be enough, but I am unsure if maybe some people will complain if it's not really needed :/
To summarize: as soon as the service keeps exiting as a failure when the file is missing, I would request the kernel option to be enabled... but if that is optional, probably upstream should make it not die so hardly in future versions and, then, we could drop the requirement
Oh, I see; systemd-sysctl behave differently in response to certain errors: https://github.com/systemd/systemd/blob/v236/src/sysctl/sysctl.c#L55
Created an issue upstream.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d5e6bd1566e3851b6c4be2b9a263897cf29422 commit 79d5e6bd1566e3851b6c4be2b9a263897cf29422 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2017-12-31 02:23:33 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2017-12-31 02:30:37 +0000 sys-apps/systemd: backport sysctl fix Closes: https://bugs.gentoo.org/642192 Package-Manager: Portage-2.3.19_p3, Repoman-2.3.6_p37 sys-apps/systemd/Manifest | 2 +- sys-apps/systemd/{systemd-236-r3.ebuild => systemd-236-r4.ebuild} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Thanks a lot!
