Red Hat Bugzilla – Bug 850427
sysctl.service fails with no such file or directory
Last modified: 2012-09-24 19:25:23 EDT
Description of problem:
systemctl start sysctl.service fails with error message:
Failed to issue method call: Unit sysctl.service failed to load: No such file or directory. See system logs and 'systemctl status sysctl.service' for details.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the system. Type escape at the plymouth display to see the error messages.
1. as root run systemctl with either status sysctl.service or stop/start it.
No error message, and probably run/start the service
This has nothing to do with system-storage-manager. Reassigning to sestemd component.
I'm running f17 on my development machine and I didn't notice behavior you describe, moreover I believe there is no sysctl.service file installed by systemd, hence "No such file or directory" error. systemd owns and enables by default systemd-sysctl.service, this is the service you might want to take a look at. For more information please see manpages, sysctl.d(5), systemd-sysctl(8).
There is no service "sysctl.service" I was aware of and if you start it manually you will get the error message you see. I don't think there's anything to fix here.
Feel free to reopen if I am missing the point of this bug report.
In steps to reproduce I had two choices, guess that was unwise, please ignore the second option.
Thus, if I reboot my system, type escape to see the messages (and/or go to /var/log/boot.log when done booting) I see the following:
[FAILED] Failed to start Apply Kernel Variables.
See 'systemctl status systemd-sysctl.service' for details.
If I run 'systemctl status systemd-sysctl.service' I get:
systemd-sysctl.service - Apply Kernel Variables
Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static)
Active: failed (Result: exit-code) since Thu, 20 Sep 2012 02:08:21 -0700; 7h ago
Process: 422 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)
As I don't remember configuring anything of the sort, have nothing in /etc/sysctl.d, /usr/lib/sysctl.d or /run/sysctl.d (and this last one doesn't exist in any of my systems), I'm not sure what's causing the error message. It could be something in /etc/sysctl.conf, but I haven't edit this in a long while.
Just trying to clear all boot error messages ...
Do you find anything related in the logs?
Not sure what you mean by "the logs."
In /var/log/messages I have these tagged by systemd, from the last reboot:
systemd: PID 1525 read from file /var/spool/postfix/pid/master.pid does not exist.
systemd: systemd-sysctl.service: main process exited, code=exited, status=1
systemd: Unit systemd-sysctl.service entered failed state.
systemd: Failed at step EXEC spawning /usr/sbin/rpc.rquotad: No such file or directory
systemd: PID 19707 read from file /var/spool/postfix/pid/master.pid does not exist.
systemd: plymouth-quit-wait.service operation timed out. Terminating.
systemd: Unit plymouth-quit-wait.service entered failed state.
systemd: Startup finished in 1s 533ms 403us (kernel) + 3s 530ms 562us (initrd) + 1min 26s 265ms 155us (userspace) = 1min 31s 329ms 120us.
systemd: systemd-tmpfiles-clean.service: main process exited, code=exited, status=1
systemd: Unit systemd-tmpfiles-clean.service entered failed state.
And these from dmesg:
systemd: systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora)
systemd: Set hostname to ....
The tmpfiles thing was a jetty problem (no user/group jetty). Haven't looked at what's up with plymouth-quit yet or rpc.quotad.
After another reboot I think I got the reason this is failing logged to /var/log/messages (not sure why it wasn't there before). I now see:
systemd-sysctl: Failed to write '0' to '/proc/sys/net/ipv4/conf/all/mc_forwarding': Permission denied
and I do have:
net.ipv4.conf.all.mc_forwarding = 0
Turns out /proc/syc/net/ipv4/con/all/mc_forwarding is -r--r--r-- root root and somehow as root I can't change it or echo 0> into it. Not sure if this ever worked before or why it isn't working now.
Hmm, OK. This seems to be a kernel interface confusion. If you think the file should be writable, please file a kernel bug. Since there appears to be nothing wrong with systemd I'll close the bug now.