Mark Haney <mark.haney@xxxxxxxxxxx> writes:
> 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?
This isn´t true, the directory is persistent, and the FHS says:
"Files under this directory must be cleared (removed or truncated as
appropriate) at the beginning of the boot process."[1]
[2] doesn´t tell you that files in /var/run will disappear at shutdown.
Using a ramdisk to store such files is not compliant with the FHS
because the files are neither truncated, nor removed; they are being
disappeared, and not at the beginning of the boot process but at
shutdown. Using a ramdisk is not appropriate.
The safe and compliant way would be to truncate the files and not to
remove or to disappear them.
The FHS doesn´t say /which/ files should be cleared or removed. I would
say that all files the removal or truncation of is not explicitly
specified must neither be removed, nor truncated, and that automatically
removing files is generally questionable and needs to be done, if at
all, with great care.
I can only speculate (and hope) that the intention of the FHS here is
that programs creating files under /var/run are supposed to remove or
truncate the files they created during the previous runtime, and only
those, when the system boots, which would be the time when those
programs are being started.
[1]:
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
[2]:
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-filesystem-fhs.html
> 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.
Then how come that the first time I´m seeing an issue like this is only
after someone made the utterly stupid decision to use a ramdisk for
/var/run?
It is a change that has been made at some time, and we weren´t told
about it. Assuming that people not being informed about a change are
stupid because they don´t know about it is a stupid thing to do.
> 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.
Making things worse by providing dirty scalpels or vehicles without
brakes --- with or without telling those who are going to use them ---
doesn´t make things better, and it can be argued that someone providing
those should be fired because of their stupidity.
Alas, the only thing that helps against stupidity is more stupidity.
Getting upset about it does not.
--
"Didn't work" is an error.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
