1821985
Members
3302
Online
109638
Solutions
SOLVED
Hi Tom,
As Sridhar wrote, /etc/auto_master might tell you where to look next. However, if you're using NIS or NIS+ to distribute your AutoFS maps, you may need to use either ypcat or niscat to get the contents of your auto_master map. Once you have the full auto_master map contents, from which ever repository holds them, you can determine which direct or indirect maps contain the reference to server "phooey".
However, it is easily possible to see this error message in syslog even if your AutoFS maps do not contain any reference to a server named "phooey". If you are using the standard AutoFS map entry:
/net -hosts
then all someone on the client has to do is issue the command:
# ls /net/phooey
and you'll get this error message, or something very similar to it.
In fact, any reference to /net/phooey will likely generate this message (i.e. not just an ls of the directory) regardless of whether your AutoFS maps directly contain a reference to a server named "phooey". Perhaps some script on your system is referencing the path "/net/phooey"?
Just something else to consider in case your AutoFS maps don't contain a server named "phooey".
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
As Sridhar wrote, /etc/auto_master might tell you where to look next. However, if you're using NIS or NIS+ to distribute your AutoFS maps, you may need to use either ypcat or niscat to get the contents of your auto_master map. Once you have the full auto_master map contents, from which ever repository holds them, you can determine which direct or indirect maps contain the reference to server "phooey".
However, it is easily possible to see this error message in syslog even if your AutoFS maps do not contain any reference to a server named "phooey". If you are using the standard AutoFS map entry:
/net -hosts
then all someone on the client has to do is issue the command:
# ls /net/phooey
and you'll get this error message, or something very similar to it.
In fact, any reference to /net/phooey will likely generate this message (i.e. not just an ls of the directory) regardless of whether your AutoFS maps directly contain a reference to a server named "phooey". Perhaps some script on your system is referencing the path "/net/phooey"?
Just something else to consider in case your AutoFS maps don't contain a server named "phooey".
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Tom,
What does your /etc/nsswitch.conf file look like, specifically the entry for automount? Does it only look at "files" - i.e. local files in /etc, or does it look at any other repository, like NIS or NIS+?
Also, can you cut/paste a copy of your /etc/mnttab file so I can see if there are any other "autofs" type entries in your /etc/mnttab file, as that will indicate that there are other maps being used other than the /net entry from your local auto_master file.
If your investigation still only shows the /net entry in /etc/auto_master then you're stuck trying to find out where these references to /net/phooey are coming from. Again, I'd start looking at scripts that run on the system at the same time as the entries are logged in /var/adm/syslog/syslog.log.
One other trick that might yield some additional information would be to send a SIGUSR2 signal to the running automountd process (i.e. kill -17). That will enable full debug logging into the file /var/adm/automount.log. Then monitor the /var/adm/syslog/syslog.log file and wait for another of these "phooey" errors to appear.
When you see another "phooey" entry added to syslog then send another SIGUSR2 signal to the running automountd pid to disable debug logging. Then either analyze the log file yourself or post it here and I can take a look at the log file to potentially tell you more about where the phooey reference is coming from.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
What does your /etc/nsswitch.conf file look like, specifically the entry for automount? Does it only look at "files" - i.e. local files in /etc, or does it look at any other repository, like NIS or NIS+?
Also, can you cut/paste a copy of your /etc/mnttab file so I can see if there are any other "autofs" type entries in your /etc/mnttab file, as that will indicate that there are other maps being used other than the /net entry from your local auto_master file.
If your investigation still only shows the /net entry in /etc/auto_master then you're stuck trying to find out where these references to /net/phooey are coming from. Again, I'd start looking at scripts that run on the system at the same time as the entries are logged in /var/adm/syslog/syslog.log.
One other trick that might yield some additional information would be to send a SIGUSR2 signal to the running automountd process (i.e. kill -17
When you see another "phooey" entry added to syslog then send another SIGUSR2 signal to the running automountd pid to disable debug logging. Then either analyze the log file yourself or post it here and I can take a look at the log file to potentially tell you more about where the phooey reference is coming from.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Tom,
Ok, it looks like /net -hosts is really the only AutoFS mount point on your system. Let's see if the debug trace picks up anything else useful.
By the way, doing the SIGUSR2 is different than starting automountd with a -T. The SIGUSR2 logging is much more verbose than -T logging.
Let me know if you get a debug automountd log file that captures an instance of the "phooey" error message.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Ok, it looks like /net -hosts is really the only AutoFS mount point on your system. Let's see if the debug trace picks up anything else useful.
By the way, doing the SIGUSR2 is different than starting automountd with a -T. The SIGUSR2 logging is much more verbose than -T logging.
Let me know if you get a debug automountd log file that captures an instance of the "phooey" error message.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Tom,
Um, actually I was expecting you to turn on debug logging via "kill -17" and then sit back and wait for some other process to cause a syslog entry to happen, not for you to do an "ls /net/phooey". I already *know* that will cause an entry to happen. :)
The popper program is as good a candidate as any other for causing this problem. Is there some popper configuration file that has a reference to "phooey" or "/net/phooey" in it?
However, an errno of 239 indicates an ECONNREFUSED, which typically means that an application is trying to connect to a service on a working system and getting denied. I would expect that whatever application is causing this error would log an RPC_UNKNOWNHOST error or some similar type of error indicating the hostname could not be resolved.
If you enable debug AutoFS logging and then wait for the offending application to cause a "phooey" syslog entry to happen then the debug log file will hopefully be more meaningful than generating the message yourself.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Um, actually I was expecting you to turn on debug logging via "kill -17" and then sit back and wait for some other process to cause a syslog entry to happen, not for you to do an "ls /net/phooey". I already *know* that will cause an entry to happen. :)
The popper program is as good a candidate as any other for causing this problem. Is there some popper configuration file that has a reference to "phooey" or "/net/phooey" in it?
However, an errno of 239 indicates an ECONNREFUSED, which typically means that an application is trying to connect to a service on a working system and getting denied. I would expect that whatever application is causing this error would log an RPC_UNKNOWNHOST error or some similar type of error indicating the hostname could not be resolved.
If you enable debug AutoFS logging and then wait for the offending application to cause a "phooey" syslog entry to happen then the debug log file will hopefully be more meaningful than generating the message yourself.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Tom,
Happy to help. One other thing to do - as soon as you see an entry in the syslog.log file for "phooey", collect a "ps -ef" output to a file so that you'll have some idea what processes were running when the log entry was made.
Of course, if the offending process is a short-lived one, or one that exits because it can't find "phooey" then the ps output might not catch it, but it's worth collecting anyway.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Happy to help. One other thing to do - as soon as you see an entry in the syslog.log file for "phooey", collect a "ps -ef" output to a file so that you'll have some idea what processes were running when the log entry was made.
Of course, if the offending process is a short-lived one, or one that exits because it can't find "phooey" then the ps output might not catch it, but it's worth collecting anyway.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Tom,
Yes, our AutoFS daemon is multi-threaded. I don't see anything in the debug output that gives me any indication where these "phooey" references are coming from. All they confirm is that the map entry being hit is "/net", which we pretty much already knew from looking at your maps and /etc/mnttab contents.
The only other information this debug logfile provides is the timestamps of when the offending application caused a lookup of "phooey", which you may be able to use to reconcile against the "ps -ef" output to help determine where these "phooey" references are coming from.
When you say you have a lead on debugging the phooey messages, do you mean you think you know which application is referencing the /net/phooey directory?
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Yes, our AutoFS daemon is multi-threaded. I don't see anything in the debug output that gives me any indication where these "phooey" references are coming from. All they confirm is that the map entry being hit is "/net", which we pretty much already knew from looking at your maps and /etc/mnttab contents.
The only other information this debug logfile provides is the timestamps of when the offending application caused a lookup of "phooey", which you may be able to use to reconcile against the "ps -ef" output to help determine where these "phooey" references are coming from.
When you say you have a lead on debugging the phooey messages, do you mean you think you know which application is referencing the /net/phooey directory?
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]