Linux - Software This 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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
 |
|
05-19-2015, 07:34 AM
|
#16
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep: 
|
Quote:
Originally Posted by pan64
mkdir -p /var/run/dbus probably helps
|
#mkdir -p /var/run/dbus/system_bus_socket
succeeded .... many thanks 
but still unable to start haldaemon
#hald --verbos=yes --daemon=no
gives this error now
dbus_bus_get(): Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
What do you think I should to ?
Thanks |
|
|
|
|
05-19-2015, 07:40 AM
|
#17
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 24,208
|
remove that, and create /var/run/dbus directory instead.
|
|
|
|
|
05-19-2015, 07:47 AM
|
#18
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by pan64
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 ? |
|
|
|
|
05-19-2015, 07:49 AM
|
#19
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 24,208
|
what about dbus daemon? is it running?
|
|
|
|
|
05-19-2015, 08:01 AM
|
#20
|
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
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?
|
|
|
|
|
05-19-2015, 08:23 AM
|
#21
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by pan64
what about dbus daemon? is it running?
|
how to check ? |
|
|
|
|
05-19-2015, 08:39 AM
|
#22
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by jpollard
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?
|
put it back ?
can you write the command line ? |
|
|
|
|
05-19-2015, 08:45 AM
|
#23
|
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
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.
|
|
|
1 members found this post helpful.
|
|
05-19-2015, 09:28 AM
|
#24
|
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Quote:
Originally Posted by esraam
put it back ?
can you write the command line ?
|
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:
Code:
/var/run:
----------. root root system_u:object_r:automount_var_run_t:s0 autofs-running
drwxr-xr-x. root root system_u:object_r:certmonger_var_run_t:s0 certmonger
drwxr-xr-x. root root system_u:object_r:pam_var_console_t:s0 console
drwxr-xr-x. root root system_u:object_r:consolekit_var_run_t:s0 ConsoleKit
----------. root root system_u:object_r:crond_var_run_t:s0 cron.reboot
drwxr-xr-x. root lp system_u:object_r:cupsd_var_run_t:s0 cups
drwxr-xr-x. root root system_u:object_r:system_dbusd_var_run_t:s0 dbus
drwxr-xr-x. root root system_u:object_r:faillog_t:s0 faillock
drwx--x--x. root gdm system_u:object_r:xdm_var_run_t:s0 gdm
drwx------. haldaemon haldaemon system_u:object_r:hald_var_run_t:s0 hald
drwx--x---. root apache system_u:object_r:httpd_var_run_t:s0 httpd
drwx------. root root system_u:object_r:lvm_var_run_t:s0 lvm
drwx------. root root system_u:object_r:mdadm_var_run_t:s0 mdadm
drwxrwxr-x. root root system_u:object_r:var_run_t:s0 netreport
drwxr-xr-x. root root system_u:object_r:var_run_t:s0 net-snmp
drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0 NetworkManager
drwxr-xr-x. root root system_u:object_r:plymouthd_var_run_t:s0 plymouth
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 pm-utils
drwxr-xr-x. root root system_u:object_r:portreserve_var_run_t:s0 portreserve
drwxr-xr-x. root root system_u:object_r:pppd_var_run_t:s0 ppp
-r--r--r--. root root system_u:object_r:rpcbind_var_run_t:s0 rpcbind.lock
drwxr-xr-x. root root system_u:object_r:saslauthd_var_run_t:s0 saslauthd
drwxr-xr-x. root root system_u:object_r:pam_var_run_t:s0 sepermit
drwxr-xr-x. root root system_u:object_r:setrans_var_run_t:s0 setrans
drwxr-xr-x. root root system_u:object_r:vdagent_var_run_t:s0 spice-vdagentd
drwxr-xr-x. root root system_u:object_r:cupsd_config_var_run_t:s0 udev-configure-printer
drwx------. root root system_u:object_r:devicekit_var_run_t:s0 udisks
-rw-rw-r--. root utmp system_u:object_r:initrc_var_run_t:s0 utmp
drwxr-xr-x. root root system_u:object_r:winbind_var_run_t:s0 winbindd
drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0 wpa_supplicant
/var/run/cups:
dr-x--x--x. lp sys system_u:object_r:cupsd_var_run_t:s0 certs
/var/run/cups/certs:
-r--r-----+ root sys system_u:object_r:cupsd_var_run_t:s0 0
/var/run/pm-utils:
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 locks
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 pm-powersave
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 storage
/var/run/pm-utils/locks:
/var/run/pm-utils/pm-powersave:
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 storage
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. |
|
|
|
|
05-20-2015, 03:57 AM
|
#25
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by jpollard
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:
Code:
/var/run:
----------. root root system_u:object_r:automount_var_run_t:s0 autofs-running
drwxr-xr-x. root root system_u:object_r:certmonger_var_run_t:s0 certmonger
drwxr-xr-x. root root system_u:object_r:pam_var_console_t:s0 console
drwxr-xr-x. root root system_u:object_r:consolekit_var_run_t:s0 ConsoleKit
----------. root root system_u:object_r:crond_var_run_t:s0 cron.reboot
drwxr-xr-x. root lp system_u:object_r:cupsd_var_run_t:s0 cups
drwxr-xr-x. root root system_u:object_r:system_dbusd_var_run_t:s0 dbus
drwxr-xr-x. root root system_u:object_r:faillog_t:s0 faillock
drwx--x--x. root gdm system_u:object_r:xdm_var_run_t:s0 gdm
drwx------. haldaemon haldaemon system_u:object_r:hald_var_run_t:s0 hald
drwx--x---. root apache system_u:object_r:httpd_var_run_t:s0 httpd
drwx------. root root system_u:object_r:lvm_var_run_t:s0 lvm
drwx------. root root system_u:object_r:mdadm_var_run_t:s0 mdadm
drwxrwxr-x. root root system_u:object_r:var_run_t:s0 netreport
drwxr-xr-x. root root system_u:object_r:var_run_t:s0 net-snmp
drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0 NetworkManager
drwxr-xr-x. root root system_u:object_r:plymouthd_var_run_t:s0 plymouth
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 pm-utils
drwxr-xr-x. root root system_u:object_r:portreserve_var_run_t:s0 portreserve
drwxr-xr-x. root root system_u:object_r:pppd_var_run_t:s0 ppp
-r--r--r--. root root system_u:object_r:rpcbind_var_run_t:s0 rpcbind.lock
drwxr-xr-x. root root system_u:object_r:saslauthd_var_run_t:s0 saslauthd
drwxr-xr-x. root root system_u:object_r:pam_var_run_t:s0 sepermit
drwxr-xr-x. root root system_u:object_r:setrans_var_run_t:s0 setrans
drwxr-xr-x. root root system_u:object_r:vdagent_var_run_t:s0 spice-vdagentd
drwxr-xr-x. root root system_u:object_r:cupsd_config_var_run_t:s0 udev-configure-printer
drwx------. root root system_u:object_r:devicekit_var_run_t:s0 udisks
-rw-rw-r--. root utmp system_u:object_r:initrc_var_run_t:s0 utmp
drwxr-xr-x. root root system_u:object_r:winbind_var_run_t:s0 winbindd
drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0 wpa_supplicant
/var/run/cups:
dr-x--x--x. lp sys system_u:object_r:cupsd_var_run_t:s0 certs
/var/run/cups/certs:
-r--r-----+ root sys system_u:object_r:cupsd_var_run_t:s0 0
/var/run/pm-utils:
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 locks
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 pm-powersave
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 storage
/var/run/pm-utils/locks:
/var/run/pm-utils/pm-powersave:
drwxr-xr-x. root root system_u:object_r:hald_var_run_t:s0 storage
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
Last edited by esraam; 05-20-2015 at 04:29 AM.
|
|
|
|
|
05-20-2015, 05:33 AM
|
#26
|
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Try "yum -y reinstall..."
To identify a specific package that contains a file, use "yum provides '*/<file>'".
For the haldaemon the result looks like:
Code:
$ yum provides "*/haldaemon"
Loaded plugins: refresh-packagekit, security
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : sl
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : sl6x
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : installed
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
The multiple entries are from the various repositories that happen to contain it, and the list of installed packaged.
Last edited by jpollard; 05-20-2015 at 05:36 AM.
|
|
|
|
|
05-20-2015, 06:10 AM
|
#27
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by jpollard
Try "yum -y reinstall..."
To identify a specific package that contains a file, use "yum provides '*/<file>'".
For the haldaemon the result looks like:
Code:
$ yum provides "*/haldaemon"
Loaded plugins: refresh-packagekit, security
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : sl
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : sl6x
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.el6.x86_64 : Hardware Abstraction Layer
Repo : installed
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
The multiple entries are from the various repositories that happen to contain it, and the list of installed packaged. |
I tried the above commands ...
#yum provides "*/haldaemon"
hal-0.5.8.1-64.e15.i386 : Hardware Abstraction Layer
Repo: base
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.e16.x86_64 : Hardware Abstraction Layer
Repo: s16x
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
hal-0.5.14-14.e16.x86_64 : Hardware Abstraction Layer
Repo: installed
Matched from:
Filename : /etc/rc.d/init.d/haldaemon
then
#yum -y reinstall hal
then
#service haldaemon start
[ FAILED ]
also
#service haldaemon restart
stopping HAL daemon : [FAILED]
starting HAL daemon : [FAILED]
how to solve this failure ? |
|
|
|
|
05-20-2015, 06:12 AM
|
#28
|
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 24,208
|
it was asked several times: did you reboot that host already?
|
|
|
|
|
05-20-2015, 06:18 AM
|
#29
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by pan64
it was asked several times: did you reboot that host already?
|
yes ...
and still having the same problem |
|
|
|
|
05-20-2015, 07:24 AM
|
#30
|
|
Member
Registered: Apr 2015
Posts: 110
Original Poster
Rep:
|
Quote:
Originally Posted by pan64
it was asked several times: did you reboot that host already?
|
yes ...
and still having the same problem |
|
|
|
All times are GMT -5. The time now is 07:37 PM.
|
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
|
 Latest Threads
LQ News
|
|
