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@xxxxxxxxxxx
www.neonova.net
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
