Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init: mount /var instead of systemd var.mount service #1554

Closed
wants to merge 1 commit into from
Closed

init: mount /var instead of systemd var.mount service #1554

wants to merge 1 commit into from

Conversation

MilhouseVH
Copy link
Contributor

@MilhouseVH MilhouseVH commented Apr 20, 2017

Based on suggestion from @stefansaraev: #1469 (comment)

@MilhouseVH
Copy link
Contributor Author

@stefansaraev this looked like a good idea but systemd continues to unmount /var during shutdown (while lock files are open)... systemd automatically manages all mount points present at runtime (ie. mounted by init) based on /proc/self/mountinfo - see man systemd.mount.

This is systemctl status var.mount on a system with this PR:

NUC:~ # systemctl status var.mount
● var.mount - /var
   Loaded: loaded (/proc/self/mountinfo)
   Active: active (mounted) since Thu 2017-04-20 08:55:04 BST; 24min ago
    Where: /var
     What: none
   CGroup: /system.slice/var.mount

Any thoughts on how to prevent systemd from unmounting /var? noauto as a mount option might work, but busybox doesn't understand it...

Otherwise the original solution, while ugly, worked and ensured /var would be unmounted after all dependencies has been stopped.

@stefansaraev
Copy link
Contributor

stefansaraev commented Apr 20, 2017

stupid thing. the generated var.mount has no DefaultDependencies=no now so that happens.. even more pain indeed. keep it as it was. and sorry for the noise.

honestly I dont know why would systemd would ever try umounting tmpfs mounts on shutdown EDIT: before it stopped all services, or do you perhaps have too many services with defaultdependencies=no?

I am happy that I dont have to use systemd now /me runs ;)

@MilhouseVH
Copy link
Contributor Author

No worries, worth a try and I learned something new (and unpleasant) about Systemd!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants