/etc/sysctl.d is not applied on boot

Bug #1485683 reported by Simon Eisenmann
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snappy
Expired
High
Unassigned

Bug Description

Changes to files in /etc/sysctl.d are not applied on boot. They get applied once one restarts systemd-sysctl.service.

- To reproduce add .conf file to /etc/sysctl.d or change any of the existing values there.
- Then reboot and check if they are applied (sysctl -a). They are not (snappy armhf 15.04 ubuntu-core 4).
- Then run systemctl restart systemd-sysctl.service and check again (the setting will be applied now).

I guess this is an issue with the mounting. It might be that /dev/mmcblk0p4 on /etc/sysctl.d type ext4 is not yet mounted when the early systemd service is run.

description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

This sounds like another instance of the old problem that the root file system isn't actually the root fs until later in the boot, due to mounting stuff in /etc. Snappy/system-image fell into this trap countless times, and I can just repeat my recommendation to mount everything that belongs into the root file system (/etc/*, /lib/*) in initramfs.

If you don't want this for some reason, I suggest to add a /lib/systemd/system/systemd-sysctl.service.d/snappy.conf with

[Unit]
RequiresMountsFor=/etc/sysctl.d

this should generate the appropriate Requires=/After=etc-sysctl.d.mount dependencies, but avoids hardcoding the unit name.

Revision history for this message
Oliver Grawert (ogra) wrote :

if we would mount in initramfs we wouldn't be able to rely on the fsck settings the default job uses when mounting based on fstab.
we initially used the fstab mounting to please mountall in the upstart world (and to not have fake events from it for depending jobs) and to have it apply fsck's based on the "pass" field there.

moving everything to the initrd would be pretty much duplication of functionality, though it might indeed make sense.

Michael Vogt (mvo)
Changed in snappy:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Leo Arias (elopio) wrote :

Thanks for your report Simon. I tried to reproduce your problem using the latest rolling all-snaps image, but couldn't.

I replaced a value in /etc/sysctl.d/10-zeropage.conf, rebooted and now systemctl -a shows the new value.

Is this still affecting you?

Changed in snappy:
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Snappy because there has been no activity for 60 days.]

Changed in snappy:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.