Bug 1255983 - Failed to start Apply Kernel Variables.
Summary: Failed to start Apply Kernel Variables.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 22
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-22 21:11 UTC by Leek Soup
Modified: 2015-09-04 12:35 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-04 12:35:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Leek Soup 2015-08-22 21:11:51 UTC
Description of problem:
Rebooted to fully updated Fedora 22 and all looked good except for this error on boot.


Version-Release number of selected component (if applicable):
219-21.fc22


How reproducible:



Steps to Reproduce:
1. Boot f22
2. systemctl status systemd-sysctl.service
3.

Actual results:
[FAILED] Failed to start Apply Kernel Variables.
See "systemctl status systemd-sysctl.service" for details.


systemctl status systemd-sysctl.service result:

$ systemctl -l status systemd-sysctl.service
● systemd-sysctl.service - Apply Kernel Variables
   Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2015-08-22 13:47:34 PDT; 2min 41s ago
     Docs: man:systemd-sysctl.service(8)
           man:sysctl.d(5)
  Process: 745 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)
 Main PID: 745 (code=exited, status=1/FAILURE)

Aug 22 13:47:34 localhost.ftrdhcpuser.net systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE
Aug 22 13:47:34 localhost.ftrdhcpuser.net systemd[1]: Failed to start Apply Kernel Variables.
Aug 22 13:47:34 localhost.ftrdhcpuser.net systemd[1]: Unit systemd-sysctl.service entered failed state.
Aug 22 13:47:34 localhost.ftrdhcpuser.net systemd[1]: systemd-sysctl.service failed.


Expected results:
Apply Kernel Variables start normally.


Additional info:

Comment 1 Carrick 2015-08-23 05:32:39 UTC
I suffer from this bug as well. I believe it also doubles the boot time. but unsure what commands I can run to proof the issue.

here is my log output.

[cam@tosh ~]$ systemctl --state=failed
  UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
● systemd-sysctl.service loaded failed failed Apply Kernel Variables

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
[cam@tosh ~]$ systemctl -l status systemd-sysctl.service
● systemd-sysctl.service - Apply Kernel Variables
   Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2015-08-23 12:07:09 AEST; 6min ago
     Docs: man:systemd-sysctl.service(8)
           man:sysctl.d(5)
  Process: 694 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)
 Main PID: 694 (code=exited, status=1/FAILURE)

Aug 23 12:07:09 tosh.tux.localdomain systemd[1]: Starting Apply Kernel Variables...
Aug 23 12:07:09 tosh.tux.localdomain systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE
Aug 23 12:07:09 tosh.tux.localdomain systemd[1]: Failed to start Apply Kernel Variables.
Aug 23 12:07:09 tosh.tux.localdomain systemd[1]: Unit systemd-sysctl.service entered failed state.
Aug 23 12:07:09 tosh.tux.localdomain systemd[1]: systemd-sysctl.service failed

Comment 2 Neil 2015-08-28 08:45:45 UTC
I suffer this bug too.

[root@infinity duff]# systemctl status systemd-sysctl.service -l
● systemd-sysctl.service - Apply Kernel Variables
   Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since vie 2015-08-28 03:36:14 COT; 1min 42s ago
     Docs: man:systemd-sysctl.service(8)
           man:sysctl.d(5)
  Process: 575 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)
 Main PID: 575 (code=exited, status=1/FAILURE)

ago 28 03:36:14 infinity systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE
ago 28 03:36:14 infinity systemd[1]: Failed to start Apply Kernel Variables.
ago 28 03:36:14 infinity systemd[1]: Unit systemd-sysctl.service entered failed state.
ago 28 03:36:14 infinity systemd[1]: systemd-sysctl.service failed.





systemd-sysctl.service fails to start along with auditd.service:
[root@infinity duff]# systemctl status auditd.service -l
● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since vie 2015-08-28 03:36:14 COT; 6min ago
  Process: 597 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)
  Process: 596 ExecStart=/sbin/auditd -n (code=exited, status=6)
 Main PID: 596 (code=exited, status=6)

ago 28 03:36:14 infinity systemd[1]: Starting Security Auditing Service...
ago 28 03:36:14 infinity systemd[1]: auditd.service: main process exited, code=exited, status=6/NOTCONFIGURED
ago 28 03:36:14 infinity auditctl[597]: No rules
ago 28 03:36:14 infinity systemd[1]: Failed to start Security Auditing Service.
ago 28 03:36:14 infinity systemd[1]: Unit auditd.service entered failed state.
ago 28 03:36:14 infinity systemd[1]: auditd.service failed.




firewalld.service
[root@infinity duff]# systemctl status firewalld.service -l
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since vie 2015-08-28 03:37:44 COT; 5min ago
  Process: 606 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=killed, signal=TERM)
 Main PID: 606 (code=killed, signal=TERM)

ago 28 03:36:14 infinity systemd[1]: Starting firewalld - dynamic firewall daemon...
ago 28 03:37:44 infinity systemd[1]: firewalld.service start operation timed out. Terminating.
ago 28 03:37:44 infinity systemd[1]: Failed to start firewalld - dynamic firewall daemon.
ago 28 03:37:44 infinity systemd[1]: Unit firewalld.service entered failed state.
ago 28 03:37:44 infinity systemd[1]: firewalld.service failed.


And NetworkManager.service which it sometimes starts after like 2 minutes from being logged, or I can just restart the system and runs fine.

Comment 3 Neil 2015-08-28 08:47:08 UTC
(In reply to Duff Padmasana from comment #2)
> And NetworkManager.service which it sometimes starts after like 2 minutes
> from being logged, or I can just restart the system and runs fine.

I meant restart the service.

Comment 4 Neil 2015-08-28 18:19:42 UTC
I'm pretty sure it is a duplicate for this bug https://bugzilla.redhat.com/show_bug.cgi?id=1253926

Comment 5 Jan Synacek 2015-09-02 07:44:31 UTC
Are there any AVCs related to systemd-sysctl in the logs? Does setting selinux to permissive in the configuration and rebooting resolve the issue?

Comment 6 Neil 2015-09-02 16:03:47 UTC
I didn't had any AVCs log related to this bug, so I didn't even think about SELinux being the problem. Yes, setting selinux to permissive resolved the issue. But I don't need to set it to permissive since selinux-policy-13.1-128.12.fc22

Comment 7 Leek Soup 2015-09-02 23:49:03 UTC
/var/log/audit/audit.log contains the following:

type=AVC msg=audit(1440806765.799:1306): avc:  denied  { sys_ptrace } for  pid=18016 comm="systemd-sysctl" capability=19  scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permissive=0

Comment 8 Jan Synacek 2015-09-04 12:35:24 UTC
(In reply to Duff Padmasana from comment #6)
> I didn't had any AVCs log related to this bug, so I didn't even think about
> SELinux being the problem. Yes, setting selinux to permissive resolved the
> issue. But I don't need to set it to permissive since
> selinux-policy-13.1-128.12.fc22

I consider this bugzilla fixed by the above package then.


Note You need to log in before you can comment on or make changes to this bug.