Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
remove that, and create /var/run/dbus directory instead.
When I removed that and created /var/run/dbus
I returned to the same previous error on trying
#--verbos =yes --daemon=no
gives :
dbus_bus_get(): failed to connect to socket /var/run/dbus/system_bus_socket : No such file or directory
so , it is always unable to connect to socket either because the directory doesn't exist ( in this case)
or because connection refused ( in the previous case)
still unable to start haldaemon
What do you suggest ?
Depending on your distribution, /var/run is a symbolic link to /run (in which case just put it back).
/run is a mountpoint for a tmpfs filesystem - thus it gets recreated on every boot. The mountpoint itself needs to exist (I don't think it gets created if it is missing on boot, but it is an interesting thought).
If the symbolic link exists and the /run directory exists, have you tried a simple reboot?
Depending on your distribution, /var/run is a symbolic link to /run (in which case just put it back).
/run is a mountpoint for a tmpfs filesystem - thus it gets recreated on every boot. The mountpoint itself needs to exist (I don't think it gets created if it is missing on boot, but it is an interesting thought).
If the symbolic link exists and the /run directory exists, have you tried a simple reboot?
In a systemd based distribution, it has to be running or the system will halt/crash as systemd will spend a lot of its time trying to restart it.
The problem when you are missing /run is that the startup/shutdown procedures record pids there, it is also used for user credentials (can't login when the credentals can't be recorded). It is also used for domain socket files that are used by systemd, dbus, dhcp, NetworkManager, rpcbind, cups ...
Basically, if you deleted the contents, the ONLY thing you can do is reboot the system.
Because EVERYTHING in /run is volitile, the only way to recover is to have the mount point. On my system it is /run, with a symbolic link from /var/run pointing to it. Others may have it switched around, or even only have /var/run.
There is nothing in the mount point to back up. The only recovery for having the contents deleted is to force a reboot.
It is also not a systemd based distribution (SL 7 should be), so dbus is not mandatory yet.
I got distracted from the references to systemd in early posts. Sorry about that.
There are a number of utilities that have directories there (it isn't a tmpfs mount in SL 6), and ownership has to be correct. Most are owned by root, group root - but there are a number of exceptions. I don't believe the regular files have to be recreated (they should be after a reboot) so don't try to re-create the "autofs-running" type of files
I have a generic installation, and the contents of /var/run are:
I have included the ownership, access modes AND security flags. The security flags can be recovered easily once the directories exist with a "restorecon -R /var/run", if there is a problem you might have to resort to a reboot with autolabel turned on (just "touch /.autolabel" and reboot).
Since SL 6 is not current, a "mkdir /var/run" to start with. The rest can be created by changing your working directory to /var/run, then doing "mkdir <directory>" where the directory is from the list I include, and a "chown user:group" <directory>" and "chmod ... <directory>" where appropriate. After creating them a "restorecon -R /var/run" should recover the security flags, though if there is a problem you might have to resort to a reboot with autolabel turned on (just "touch /.autolabel" and reboot).
If you have problems with particular tools/libraries afterwards, you should be able to get them back by forcing a reinstall of just those packages (you might have to determine the package name useing "yum provides '*/<utility-name>'" to identify the associated package, then a "yum reinstall <package>" should recreate any directories with the correct ownership, access modes, and security flags.
As an option to recreating the directories manually, you could just reinstall each installed package you have. It might take longer, but be a simpler process. I've done it once for a laptop - rather painful for me as I had a lot of packages, and the laptop network connection was SLOW. Reinstalling groups of packages (10-15 at a time) worked fairly well.
It is also not a systemd based distribution (SL 7 should be), so dbus is not mandatory yet.
I got distracted from the references to systemd in early posts. Sorry about that.
There are a number of utilities that have directories there (it isn't a tmpfs mount in SL 6), and ownership has to be correct. Most are owned by root, group root - but there are a number of exceptions. I don't believe the regular files have to be recreated (they should be after a reboot) so don't try to re-create the "autofs-running" type of files
I have a generic installation, and the contents of /var/run are:
I have included the ownership, access modes AND security flags. The security flags can be recovered easily once the directories exist with a "restorecon -R /var/run", if there is a problem you might have to resort to a reboot with autolabel turned on (just "touch /.autolabel" and reboot).
Since SL 6 is not current, a "mkdir /var/run" to start with. The rest can be created by changing your working directory to /var/run, then doing "mkdir <directory>" where the directory is from the list I include, and a "chown user:group" <directory>" and "chmod ... <directory>" where appropriate. After creating them a "restorecon -R /var/run" should recover the security flags, though if there is a problem you might have to resort to a reboot with autolabel turned on (just "touch /.autolabel" and reboot).
If you have problems with particular tools/libraries afterwards, you should be able to get them back by forcing a reinstall of just those packages (you might have to determine the package name useing "yum provides '*/<utility-name>'" to identify the associated package, then a "yum reinstall <package>" should recreate any directories with the correct ownership, access modes, and security flags.
As an option to recreating the directories manually, you could just reinstall each installed package you have. It might take longer, but be a simpler process. I've done it once for a laptop - rather painful for me as I had a lot of packages, and the laptop network connection was SLOW. Reinstalling groups of packages (10-15 at a time) worked fairly well.
ok , I am trying to re-install the packages as follow
#yum list l grep <package name>
#yum -y install ( all related packages )
is that what you mean ?
I am having a problem with haldaemon
#yum list ! grep hald
< no output >
on the same time
#service haldaemon start
gives [ FAILED ]
How can i find the packages for hald ? haldaemon ?
and how can i get this service to start
many thanks for your help
Hope we will get things to work
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.