{"action":"created","issue":{"url":"https://api.github.com/repos/systemd/systemd/issues/1495","labels_url":"https://api.github.com/repos/systemd/systemd/issues/1495/labels{/name}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/1495/comments","events_url":"https://api.github.com/repos/systemd/systemd/issues/1495/events","html_url":"https://github.com/systemd/systemd/issues/1495","id":110449780,"number":1495,"title":"Don't freeze system when /etc/mtab is not a symlink","user":{"login":"martinpitt","id":200109,"avatar_url":"https://avatars.githubusercontent.com/u/200109?v=3","gravatar_id":"","url":"https://api.github.com/users/martinpitt","html_url":"https://github.com/martinpitt","followers_url":"https://api.github.com/users/martinpitt/followers","following_url":"https://api.github.com/users/martinpitt/following{/other_user}","gists_url":"https://api.github.com/users/martinpitt/gists{/gist_id}","starred_url":"https://api.github.com/users/martinpitt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/martinpitt/subscriptions","organizations_url":"https://api.github.com/users/martinpitt/orgs","repos_url":"https://api.github.com/users/martinpitt/repos","events_url":"https://api.github.com/users/martinpitt/events{/privacy}","received_events_url":"https://api.github.com/users/martinpitt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-10-08T13:21:56Z","updated_at":"2015-10-09T11:12:16Z","closed_at":null,"body":"This was already discussed in PR #986, but didn't get finished. systemd 227 now freezes the system at boot if `/etc/mtab` is not a symlink, but a file. This is really obnoxious, as that gives the user zero chance to actually unbreak the system after this happened. Remember, this isn't anything a vendor/distro can influence -- have some weird backup/restore program/strategy, some weird script to run `sed -i` on the thing, or whatnot -- we've seen actual bug reports where this happened.\r\n\r\nAt the very least there should be a rescue shell, so that you have the chance to clean up. But then again, there's only one solution, and e. g. in Debian we have a unit that turns `/etc/mtab` back into a symlink on boot, but with the early freeze this now won't help any more. The visible effect is now that we moved from \"your system fixes itself\" to \"your system became completely useless and hard to fix\" (remote servers!), which is not at all an improvement.\r\n\r\nNobody likes `/etc/mtab`, it should have burned and died many years ago, and we all agree that it is an utter misconception. So I rather ask: Why are we still paying attention to it?\r\n\r\nsystemd itself only uses it in `shell-completion/zsh/_udevadm` (which is trivially fixable to use `/proc/mounts` instead), and `tmpfiles.d/etc.conf.m4`, which could just stay as it is. All other references are just for asserting that `/etc/mtab` is a symlink.\r\n\r\nThis was merged because allegedly util-linux' mount monitor breaks if `/etc/mtab` is a file -- so it seems to me that *this* is the place to fix: Pretty please let's just make the mount monitor stop paying attention to a potentially broken `/etc/mtab` and always use `/proc`. Isn't that what `--enable-libmount-force-mountinfo` is supposed to do anyway? Can't that just become the default, and we declare `/etc/mtab` dead once and for all?\r\n\r\n@karelzak, what exactly in util-linux still pays attention to `/etc/mtab`, and can we make that stop?\r\n\r\nI'm happy  to send a PR with that cleanup, which will be straightforward but let's agree to what we'll do first.\r\n\r\nThanks for considering!"},"comment":{"url":"https://api.github.com/repos/systemd/systemd/issues/comments/146835717","html_url":"https://github.com/systemd/systemd/issues/1495#issuecomment-146835717","issue_url":"https://api.github.com/repos/systemd/systemd/issues/1495","id":146835717,"user":{"login":"martinpitt","id":200109,"avatar_url":"https://avatars.githubusercontent.com/u/200109?v=3","gravatar_id":"","url":"https://api.github.com/users/martinpitt","html_url":"https://github.com/martinpitt","followers_url":"https://api.github.com/users/martinpitt/followers","following_url":"https://api.github.com/users/martinpitt/following{/other_user}","gists_url":"https://api.github.com/users/martinpitt/gists{/gist_id}","starred_url":"https://api.github.com/users/martinpitt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/martinpitt/subscriptions","organizations_url":"https://api.github.com/users/martinpitt/orgs","repos_url":"https://api.github.com/users/martinpitt/repos","events_url":"https://api.github.com/users/martinpitt/events{/privacy}","received_events_url":"https://api.github.com/users/martinpitt/received_events","type":"User","site_admin":false},"created_at":"2015-10-09T11:12:16Z","updated_at":"2015-10-09T11:12:16Z","body":"FTR, we've shipped http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/units/debian-fixup.service for many years now (it's even in wheezy), to cleanup a broken `/etc/mtab` symlink during boot. If systemd wants to care about this, perhaps this would be something to adopt upstream, instead of the freezing?"}}