[SOLVED] rm -rf /var/run

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

Booting takes veryyyyyyyyyyy long time with many messages failures

system logger takes very much time
NFS mountd : failed
NFS quotes : failed
Hyper V drivers not loaded
Hyper V Fcopy daemon not started
Hyoer V VSS daemon not started
hyper V KVP daemon not started

And finally it switches to the cli
I boot to level 3 as my keyboard and mouse are not working on gui ( mostly due to haldaemon failure )

Can some body help ?

esraam · 05-20-2015, 08:17 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.

After re-installing the packages and rebooting ;
i tried :
#cd /var/run
#chmod 755 hal
#restorecon -R /var/run

#service haldeamon start

[failed ]

#hald --verbos=yes daemon=no
hal 0.5.14
using child timeout 250s
will daemonize
Becoming a daemon

then #service haldaemon restart
stopping [FAILED]
starting [FAILED]

so where do you think the problem is ?

jpollard · 05-20-2015, 08:32 AM

I can see it failing both times (and after a reboot), but there should be some log entries.

The usual failure to stop would be if the procedure can't identify that it is running. And the restart could fail if it couldn't register the pid.. or if it were already running. Usually there would some additional messages about why - but it may be missing log entries.

You ought to be able to reinstall the other packages (the filesystem package for instance as that one appears to recreate the /var/log and /var/run but doesn't create all the contents of /var/run) that might help with that.

Unfortunately, the ideal reinstall isn't available (a "groupreinstall" for instance).

You can try the following packages (determined by doing a "yum provids /var/run/<directory>") to start.

Code:

<package name>             <directory>
certmonger                 /var/run/certmonger
pam                        /var/run/console
                           /var/run/faillock
                           /var/run/sepermit
ConsoleKit                 /var/run/ConsoleKit
cups                       /var/run/cups
dbus                       /var/run/dbus
gdm                        /var/run/gdm
hald                       /var/run/hald
httpd                      /var/run/httpd
lvm2                       /var/run/lvm
mdadm                      /var/run/mdadm
initscripts                /var/run/netreport
net-snmp                   /var/run/net-snmp
NetworkManager             /var/run/NetworkManager
plymouth                   /var/run/plymouth
pm-utils                   /var/run/pm-utils
portreserve                /var/run/portreserve
ppp                        /var/run/ppp
cyrus-sasl                 /var/run/saslauthd
libselinux                 /var/run/setrans
spice-vdagent              /var/run/spice-vdagentd
system-config-printer-udev /var/run/udev-configure-printer
udisks                     /var/run/udisks
samba-winbind              /var/run/winbindd
wpa_supplicant             /var/run/wpa_supplicant

You might check to verify you do have these packages (I don't remember why spice-vdagent got installed, or samba-winbind... but it may be these are in the default). Hopefully, these would be the only ones you have to reinstall. And after that you would have to reboot.

From a brief check, these packages will create any needed contents of the base directories (cups for instance creates a /var/run/cups/certs, but does not create anything in the certs directory).

One way to force the reinstall is to download the rpm then use "rpm -ivh --force <package>". This isn't TOO unreasonable for only 24 packages... It would be unreasonable for several hundred. (I found this from http://forums.fedoraforum.org/showthread.php?t=119863)

esraam · 05-28-2015, 03:51 AM

#service messagebus start
gives error:
messagebus : unrecognized service

How to solve this error ?
I think this causes the haldaemon failure problem

jpollard · 05-28-2015, 05:07 AM

Quote:

Originally Posted by esraam

#service messagebus start
gives error:
messagebus : unrecognized service

How to solve this error ?
I think this causes the haldaemon failure problem

It is provided by the package "dbus". Did you install/reinstall it?

esraam · 05-28-2015, 06:06 AM

Quote:

Originally Posted by jpollard

It is provided by the package "dbus". Did you install/reinstall it?

yes .. I installed all packages in you /var/run
and then message bus existed
and I could start it.
But , the problem is It was working then stopped
Do you think something may uninstall this package and so stops the service ?

jpollard · 05-28-2015, 06:09 AM

I wouldn't have thought so.

The error "messagebus : unrecognized service" implies that the /etc/init.d/messagebus script is missing, which it shouldn't if the dbus package is installed.