| Summary: | Dbus and /var/run management | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | vincent |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | minor | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Remove /var/run from target | ||
Hi Vincent, Do you still experience this bug with a recent buildroot version (2013.11 or git)? If so, can you clarify a bit more? In buildroot, when you use the default target skeleton, /var/run is indeed a symbolic link to /tmp. And the S30dbus script does indeed: # Create needed directories. [ -d /var/run/dbus ] || mkdir -p /var/run/dbus [ -d /var/lock/subsys ] || mkdir -p /var/lock/subsys [ -d /tmp/dbus ] || mkdir -p /tmp/dbus However, I don't understand how both conflict with each other. The creation of /var/run/dbus will actually result in /tmp/dbus, which should be fine. So maybe I don't fully understand the problem you experience. Please clarify. Note that the patch you propose is not correct in my opinion: removing the entire /var/run directory during the building of dbus, may remove files created by other packages, which is not the intended behavior. No feedback from submitter after request for clarification. There seems to be no problem in the handling of /tmp and /var/run/dbus, even with symbolic links. Please reopen if you still have the problem, in which case you should provide more details. |
Created attachment 4466 [details] Remove /var/run from target Some BSP vendors manage /var/run as a symlink to /tmp. Dbus package creates a target/var/run/dbus directory which can prevent the final symlink. Since S30dbus handles the creation of /var/run/dbus, it can be removed from target directory.