Red HatThis forum is for the discussion of Red Hat Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
This weekend, the automount daemon didn't come back after a reboot of an old server, and I can't figure out how to restart it. Suggestions are welcome.
This server is (they tell me) a strange hybrid of Red Hat 7.1 and 7.2 -- it's weird enough that although all the other local Linux servers are running newer versions of RH or its clones, this one has been left as is. Unfortunately, I don't know offhand what patches have and have not been applied.
What I've tried so far:
- Re-rebooting; said "Starting automount [FAILED]"
- Running /etc/init.d/autofs with various parameters: start, restart, stop then start, status.
- Removing the lock file, then re-running autofs start.
- Putting echo statements in a copy of the autofs script and running the copy as a sort of trace.
This last, combined with other strategies, made me aware of the lock file and the fact that it seems to be created even if after the script runs, the automount daemon is not running. The script (with or without the extra debug statements) sometimes thinks it has successfully started the daemon (which doesn't show up in ps -ef) and sometimes admits it has failed.
Yes, I know that the long term solution is to upgrade. An interim solution may be to hard-mount anything that the users really need. It would, however, be nice to get it working the way it was before the reboot.
Thanks for the response. The problem is fixed now, and I'm surprised at what apparently went wrong. It turned out that the automaps were missing because of a problem in /etc/fstab that I would have thought was unrelated.
There was a bad label in /etc/fstab: /var/log/messages said "fsck: Couldn't find matching filesystem: LABEL=/u1" and "mount: special device LABEL=/u1 does not exist". There _is_ a directory named /u1, so I don't know quite what the problem was, but the error seems to have prevented the mounting of some or all of the file systems that came after it in the fstab. After I ran mount -a, a couple of additional file systems were mounted, including the one where the automaps are stored. Then I re-ran the autofs init script, and the automount daemon finally came up and stayed up.
Is it correct to conclude that some kinds of errors in /etc/fstab can prevent other file systems from being mounted? And any idea how to figure out why it said the label didn't exist?
"... Once you have created and formated a partition, you should assign it a label using the e2label command. This allows you to add the partition to /etc/fstab using a label instead of using a device path, thereby making the system more robust ..."
In your case "/u1" is a directory and the label, which is written to disk. I don't know why the label is gone. Did you
change disks or partitions ? So you can now either add a label or change /etc/fstab to use the "normal" /dev/hdX instead of the LABEL.
I was'nt aware that problems in /etc/fstab prevent the mounts on the following lines to be executed.
I got some history of the system from someone who has
been around it longer than I have. Apparently it used
to have a couple of internal drives whose labels/mount
points were /u0 and /u1. The second internal drive was
removed but the mount point wasn't. What we decided to
do was comment out the offending line, and no trouble
I've never seen the problem with an error in fstab
blocking mounts of following lines, either. However,
it turns out there was another problem, unrelated to
the automounts, that was also fixed by mounting
the filesystems that came after the line with the bad
label in fstab. It could just be a problem with the
mutant kernel this particular machine is running.
Thanks again -- I appreciate the information and