[SOLVED] rm -rf /var/run

esraam · 05-19-2015, 08:34 AM

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

pan64 · 05-19-2015, 08:40 AM

remove that, and create /var/run/dbus directory instead.

esraam · 05-19-2015, 08:47 AM

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 ?

pan64 · 05-19-2015, 08:49 AM

what about dbus daemon? is it running?

jpollard · 05-19-2015, 09:01 AM

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?

esraam · 05-19-2015, 09:23 AM

Quote:

Originally Posted by pan64

what about dbus daemon? is it running?

how to check ?

esraam · 05-19-2015, 09:39 AM

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 ?

jpollard · 05-19-2015, 09:45 AM

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.

jpollard · 05-19-2015, 10:28 AM

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.

esraam · 05-20-2015, 04:57 AM

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

jpollard · 05-20-2015, 06:33 AM

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.

esraam · 05-20-2015, 07:10 AM

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 ?

pan64 · 05-20-2015, 07:12 AM

it was asked several times: did you reboot that host already?

esraam · 05-20-2015, 07:18 AM

Quote:

Originally Posted by pan64

it was asked several times: did you reboot that host already?

yes ...
and still having the same problem

esraam · 05-20-2015, 08:24 AM

Quote:

Originally Posted by pan64

it was asked several times: did you reboot that host already?

yes ...
and still having the same problem