On 05/13/2011 07:54 PM, DJ Lucas wrote:
sjs205<[email protected]> 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
[email protected]
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
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
