Summary: | boot failure if /var/run is not a symlink to /run , dbus should create its socket in /run not /var/run | ||
---|---|---|---|
Product: | systemd | Reporter: | Adam Williamson <adamw> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
Severity: | critical | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Adam Williamson
2014-02-26 01:04:40 UTC
We hardly can start going back and moving everything things to /var/run. This discussion happened in Fedora in https://bugzilla.redhat.com/show_bug.cgi?id=825466. dbus.socket should be fixed to point to use /run. dbus is in freedesktop.org too... dbus devs, I think /usr/lib/systemd/system/dbus.socket needs this change: -ListenStream=/var/run/dbus/system_bus_socket +ListenStream=/run/dbus/system_bus_socket Humm, no. the dbus spec says /var/run is where the socket has to be. I see no reason to change that. That path is compiled into a myriad of programs, and there's really no point in changing that. /var/run must be a symlink to /run, end of story. If FEdora doesn't get that right, then Fedora is broken. Note however that actually the upgrade logic back when the /run transition happened (which is years ago) carefully made sure that /var/run was turned into a symlink. If that didn't happen for you, then there must have been a bug in that, or you didn't follow the usual upgrade procedure? (maybe bcause you updated manually with just naked rpm? but in that case, you of course get to keep both pieces...) Anyway, I am pretty sure neither dbus nor systemd should be changed here. If anything, Fedora should be fixed. Ah, this was all part of /usr merge? If the dracut hook for that handles it, then it usually should be fine. For historical interest: I upgrade with yum (well, these days I use fedup, but at the time I used yum because the old upgrade methods stank), and the F16->F17 upgrade notes for yum upgraders say this: If you have /var on a separate partition, you will have to manually convert "/var/run" and "/var/lock" to a symbolic link. # mv -f /var/run /var/run.runmove~ # ln -sfn ../run /var/run # mv -f /var/lock /var/lock.lockmove~ # ln -sfn ../run/lock /var/lock So, it sounds like that note is wrong: you need to do it manually even if /var is *not* a separate partition. (It's not for me). So systemd will use /var/run/dbus/system_bus_socket again everywhere. (In reply to comment #4) > Ah, this was all part of /usr merge? If the dracut hook for that handles it, > then it usually should be fine. > > For historical interest: I upgrade with yum (well, these days I use fedup, > but at the time I used yum because the old upgrade methods stank), and the > F16->F17 upgrade notes for yum upgraders say this: > > If you have /var on a separate partition, you will have to manually convert > "/var/run" and "/var/lock" to a symbolic link. > > # mv -f /var/run /var/run.runmove~ > # ln -sfn ../run /var/run > # mv -f /var/lock /var/lock.lockmove~ > # ln -sfn ../run/lock /var/lock > > So, it sounds like that note is wrong: you need to do it manually even if > /var is *not* a separate partition. (It's not for me). The dracut upgrade module did that conversion, it could only not reach the directories to convert if /var was separate. So the text should be right. No idea how that did not apply to your box: https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/30convertfs/convertfs.sh#n24 Possibly I used an earlier version that didn't do that? It's a long time ago, I don't exactly recall. I may have been running Rawhide at the time. (In reply to comment #7) > Possibly I used an earlier version that didn't do that? It's a long time > ago, I don't exactly recall. I may have been running Rawhide at the time. Yeah, that could be that this wasn't included in the early days before the release. Also for a while, we had mount units in systemd which did bind-mounts to cover for stuff that wasn't converted. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.