Bug 5420 - Dbus and /var/run management
Summary: Dbus and /var/run management
Status: RESOLVED WORKSFORME
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-31 07:37 UTC by vincent
Modified: 2014-02-23 14:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
Remove /var/run from target (477 bytes, patch)
2012-07-31 07:37 UTC, vincent
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vincent 2012-07-31 07:37:57 UTC
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.
Comment 1 Thomas De Schampheleire 2014-02-11 21:05:58 UTC
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.
Comment 2 Thomas De Schampheleire 2014-02-23 14:45:42 UTC
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.