Bug 850427

Summary:	sysctl.service fails with no such file or directory
Product:	[Fedora] Fedora	Reporter:	Henrique Martins <fedora>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	johannbg, lczerner, lnykryn, lpoetter, metherid, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-24 23:25:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Henrique Martins 2012-08-21 14:57:20 UTC

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):
systemd-44-17.fc17.x86_64

How reproducible:
every time

Steps to Reproduce:
1. Boot the system. Type escape at the plymouth display to see the error messages.
or
1. as root run systemctl with either status sysctl.service or stop/start it.
  
Actual results:
Message above

Expected results:
No error message, and probably run/start the service

Additional info:

Comment 1 Lukáš Czerner 2012-09-03 17:08:48 UTC

This has nothing to do with system-storage-manager. Reassigning to sestemd component.

-Lukas

Comment 2 Michal Sekletar 2012-09-04 10:17:18 UTC

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).

Comment 3 Lennart Poettering 2012-09-12 03:30:55 UTC

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.

Comment 4 Henrique Martins 2012-09-20 16:42:11 UTC

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
            Docs: man:systemd-sysctl.service(8)
                  man:sysctl.d(5)
         Process: 422 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/systemd-sysctl.service

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 ...

Comment 5 Lennart Poettering 2012-09-21 08:23:48 UTC

Do you find anything related in the logs?

Comment 6 Henrique Martins 2012-09-21 16:15:27 UTC

Not sure what you mean by "the logs."

In /var/log/messages I have these tagged by systemd, from the last reboot:
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: Reloading.
  systemd[1]: PID 1525 read from file /var/spool/postfix/pid/master.pid does not exist.
  systemd[1]: Reloading.
  systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1
  systemd[1]: Unit systemd-sysctl.service entered failed state.
  systemd[1259]: Failed at step EXEC spawning /usr/sbin/rpc.rquotad: No such file or directory
  systemd[1]: PID 19707 read from file /var/spool/postfix/pid/master.pid does not exist.
  systemd[1]: plymouth-quit-wait.service operation timed out. Terminating.
  systemd[1]: Unit plymouth-quit-wait.service entered failed state.
  systemd[1]: Startup finished in 1s 533ms 403us (kernel) + 3s 530ms 562us (initrd) + 1min 26s 265ms 155us (userspace) = 1min 31s 329ms 120us.
  systemd[1]: systemd-tmpfiles-clean.service: main process exited, code=exited, status=1
  systemd[1]: Unit systemd-tmpfiles-clean.service entered failed state.

And these from dmesg:
  systemd[1]: systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora)
  systemd[1]: 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.

Comment 7 Henrique Martins 2012-09-22 23:12:16 UTC

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[419]: 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
on /etc/sysctl.cnf

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.

Comment 8 Lennart Poettering 2012-09-24 23:25:23 UTC

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.