[Clfs-dev] /var/run

sjs205 sjs205.linux at gmail.com
Sat May 14 05:47:24 PDT 2011


On 05/13/2011 07:54 PM, DJ Lucas wrote:
> sjs205<sjs205.linux at gmail.com>  wrote:
>
>> Final update... I have updated the book patch to include mounting the
>> /var/lock directory as a tmpfs filesystem... The two patches are as
>> follows:
>>
>> Book patch - http://pastebin.cross-lfs.org/230504
>> bootscripts-cross-lfs-1.1.0 http://pastebin.cross-lfs.org/230503
>>
>>
>> On 05/13/2011 05:09 PM, sjs205 wrote:
>>> Ok, have looked into this a little further and have a working tmpfs
>>> /var/run fs.
>>>
>>> What I did:
>>> * Added a line to /etc/fstab:
>>>      varrun /var/run tmpfs defaults 0 0
>>>      This was enough to get the basic tmpfs dir.
>>> * Then edited the /etc/rc.d/init.d/cleanfs script and added a section
>>> just before all files get removed from /var/run as follows:
>>>                  if [ ! -f ./utmp ]
>>>                  then
>>>                          touch ./utmp
>>>                  fi
>>>
>>>
>>> I have created a patch for this. Obviously this patch implies a few
>>> amendments to the book - added line in fstab and no need to 'touch'
>>> umtp - so I have created a patch for this too.
>>>
>>> If anybody thinks I have gone about this the wrong way then please do
>>> let me know, or just feel free to pass comments.
>>>
>>>
>>> sjs205
>>>
>>> Book patch - http://pastebin.cross-lfs.org/230502
>>> bootscripts-cross-lfs-1.1.0 http://pastebin.cross-lfs.org/230503
>>>
>>>> Hello All,
>>>>
>>>> Every couple of days I manage to inadvertently cut the power to my
>>>> CLFS x86 server. Since I only really SSH to this box this presents a
>>>> problem since the SSH pid file doesn't get removed on power failure
>> so
>>>> I have to connect up a screen, delete /var/run/sshd.pid then restart
>>>> ssh.
>>>>
>>>> This is caused by the static setup of the /var/run dir so I have
>>>> decided to address this.
>>>>
>>>> My plan:
>>>> * Create a start-up script in /etc/rc.d/init.d that will remove all
>>>> files from the /var/run directory, then mount a tmpfs using /var/run
>>>> as the mount point.
>>>>
>>>> With this in mind, before I start, just a few questions related to
>> this:
>>>> * Should this be a separate script in init.d or should I add it to
>> an
>>>> existing one? I am thinking that a script is required for the
>> removing
>>>> old PID files, but the mounting of the tmpfs could be carried out by
>>>> S30mountfs - by adding a mount point to /etc/fstab - in the
>>>> /etc/rc.d/rcsysinit.d/ directory.
>>>> * Can anybody recommend a size for the tmpfs. Running 'du -ah' on
>> the
>>>> /var/run dir, the contents are only 96 k, but then the same command
>> on
>>>> my Fedora box shows the dir to be 1.8 MB in size.
>>>>
>>>> Does everyone agree that this is a necessary course of action? Any
>>>> comments or recommendations welcome - I am generally on the CLFS IRC
>>>> so come chat there or just return email.
>>>>
>>>> sjs205
>>>>
>>>>
>> _______________________________________________
>> Clfs-dev mailing list
>> Clfs-dev at lists.cross-lfs.org
>> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content, and is believed to be clean.
> FHS-2.4 will require /run. Udev-167+ likes to see /run/udev. Might be better to make that /run tmpfs very early in boot process (CLFS equivalent of mountkernfs/mountvirtfs) and create dirs there and symlink there for /var/{lock,run} and /dev/shm as in LFS. See relevant discussions on lfs-dev and decide if it is appropriate for CLFS as well. I believe that is correct but I've not used CLFS's init.
>
> -- DJ
Dj,

Thanks for the reply.

According to http://www.pathname.com/fhs/ the current FHS standard is 
2.3, I'm not sure about 2.4, but the CLFS book certainly uses 2.3 and 
udev-124.

With regards to the boot process timing, the tmpfs filesystems are all 
mounted together. During the design process I created a test script that 
would print the contents of the /var/run dir to a file along with ps and 
found that at this point the dir is empty of any lock files. So I think 
that is perfect.

I did think about creating a script solely for the mounting process but 
thought that since it was initially only one tmpfs it would be better 
just implemented within the standard clfs mountfs script - and this 
script didn't require any amendment. But if anyone else thinks this 
should be implemented differently then please do let me know.

Had a look through the LFS-dev mailing archives too... is there no way 
to search these?

So failing any further response, the patches are still valid :)

sjs205




More information about the Clfs-dev mailing list