SUMMARY: Suddenly "automountd not running, retrying"
2007-12-25 5:28:00
> Message-Id: <20050920131220.34A9FE158 at jimsun.linxnet.com>
>
> Hi All,
>
> Two mornings lately I've arrived to find our Sun E250 running Solaris 8
> all but totally "seized up." (This morning even *I* couldn't log in,
> and had to nerve-pinch it.) At first it seemed to be behaving like a
> NIS+ problem, but, on further examination, I suspect the problem to lie
> with the automounter. Each time, this
>
> ...autofs: [ID 593912 kern.notice] automountd not running, retrying
>
> was the last thing in /var/adm/messages, prior to rebooting the
> system. (This was in /var/adm/messages at 05:22. Tripwire runs at
> 05:21.)
>
> Searching the web and SunSolve, the only thing I found that appeared
> to be relevant was:
>
> http://sunsolve.sun.com/search/document.do?assetkey=1-26-55340-1
> Title: Automountd(1M) May Stop and/or OpenSSH May Experience
> Authentication Issues
>
> Patch 108993-33 is installed.
>
> Coincidentally (?), a week ago I built, installed and have been
> experimenting with OpenLDAP on this machine--incl. with TLS.
>
> I don't recall whether or not I've left slapd (the OpenLDAP server
> daemon) running over-night, either time.
>
> Could it be that whatever mechanisms support FNS are "noticing"
> OpenLDAP running (at some point) and that's getting the automounter
> all tied up in knots (under load?)?
>
> Anyway, I've commented-out "/xfn -xfn" in /etc/auto_master
> and restarted automountd. I also removed the xfn entry from
> /etc/nsswitch.conf. We'll see what happens. Or not...
Okay, contrary to what Sun's docs say, or maybe because this is/was a
different problem with similar symptoms, the work-around in that last
paragraph didn't improve matters.
By alternately running the OpenLDAP over-night and not letting it run,
I did determine the problem was related to it running.
"That" Bill Cole :) had the answer, where he wrote:
| Another thing I found from a quick look at Sunsolve was this:
| http://sunsolve.sun.com/search/document.do?assetkey=1-26-57786-1. That might
| actually be closer to your problem...
Applying patch 116997 appears to have done-away with the problem.
Thanks, Bill! Thanks also to Darren Dunham for the follow-up.
Lastly, lest they think me ungrateful, special thanks to
"Patni, Sandeep" <Sandeep.Patni at gs.com>,
Juergen Waiblinger <jwaiblin at transtec.de>,
"Wianecki, Christopher" <Christopher.Wianecki at sothebys.com> and
Barrett_Derek at emc.com
for being so kind as to let me know they'd be out of the office.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.linxnet.com/scform.php>.
Comments
Got something to say?
You must be logged in to post a comment.
