On 10/04/2017 04:23 AM, Gary Stainburn wrote: > > Mark, Many Non-Centos originated packages create directories in /var/run as > part of the install, and expect them to still exist after a reboot. > > They then fail when starting the service because they're trying to create a > PID / Lock file in a directory that no longer exists. This problem has been > around ever since /var/run was moved to tmpfs. > > Unfortunately, sometimes we have to use packages other than the official > Centos ones, usually as in this case because we need newer versions. > > There is a solution that saves /var/run to disk at shutdown and restores it at > bootup but I can't remember what it is. Sorry, but if you have to use packages that don't originate from CentOS and they do that, then I wouldn't use them. Period. I'd compile from source before I used something configured that way. Why is it so hard for people to understand that var/run IS NOT PERSISTENT and was never meant to be? Do they not teach basic Unix concepts anymore? If you think that setup is acceptable, I wouldn't hire you to water my lawn as you'd likely water the electrical box along with said lawn. These are VERY VERY basic concepts. Banging a square peg into a round hole, even in a test environment is a good way to get fired and become unemployable. And believe me, word gets around quickly in IT circles. If you can't build from source to keep from using non-standard packages, then you really shouldn't be doing whatever it is you were hired to do. This is extremely basic arithmetic here. You don't do surgery with dirty scalpels, you don't drive without brakes, these are axiomatic just like /var/run isn't persistent. It's been that way at least since I was in HS and college in the 80s and very very likely since the early Unix days. Honestly, I feel bad for your employer if you think this is an acceptable way to get a system working. There, I've said my piece. Call it a flame if you want, truth hurts and ignoring basic rules is a good way to hurt yourself or other people. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney at neonova.net www.neonova.net