topic I caused it: rm_log_init: fopen of file in Insight Remote Support

I caused it: rm_log_init: fopen of file

Records Management — Tue, 14 Apr 2009 11:15:39 GMT

I was reloading OnlineDiag due to the fun that I am having getting Remote Support Pak (RSP) to work. A whole other story.

But the result is that I am now receiving this in the syslog file every five minutes.

Apr 14 08:10:52 rmsvmh1 syslog: rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed: Permission denied

I have compared the entire directory structure to a non-complaining server, have stopped EMS, removed the files, and restarted it. And the file is growing, so it is being written to.

Re: I caused it: rm_log_init: fopen of file

Dennis Handly — Tue, 14 Apr 2009 11:44:53 GMT

>/etc/opt/resmon/log/client.log failed: Permission denied

Do you know what user is running rmsvmh1, if not root?

Re: I caused it: rm_log_init: fopen of file

Records Management — Tue, 14 Apr 2009 12:22:39 GMT

rmsvmh1 is the server name. This is a Integrity VM host server, so there are no users on it other than normal processes.

Re: I caused it: rm_log_init: fopen of file

Andre Froebel — Thu, 16 Apr 2009 11:40:11 GMT

Hello,

just experienced the same error while implementing RSP. The problem seems to be due to using non-root users for WBEM communications between HP SIM and managed nodes. This causes cimprovagt processes to be started as this non-root user, which in turn can't write to the logfile. The faulty cimprovider Module is HPUXFCIndicationProviderModule, which regularly wakes up and tries to access the logfile, if WBEM subscriptions to HP SIM are active. At least this seems to be a known problem at HP, as there is already a change request for it. But unfortunalely I couldn't see any hint about, when we might expect a fix for it.

Hope this helps and kind regards,

Andre FrÃ¶bel (HP)!

Re: I caused it: rm_log_init: fopen of file

Records Management — Thu, 16 Apr 2009 11:53:36 GMT

Thanks for the info. That makes sense. I'm going to have to wait for the fix for this one.

But it is not a major issue, so now I can move on to the next one. This one appears in the syslog whenever I create a test event

Apr 15 09:06:56 rmsimage cimserver[12922]: PGS10405: Failed to
deliver an indication: PGS11405: THE CIMEXPORT HTTP HEADER IS
MISSING.
Apr 15 09:06:56 rmsimage cimserver[12922]: PGS10405: Failed to
deliver an indication: PGS11405: THE CIMEXPORT HTTP HEADER IS
MISSING.

Re: I caused it: rm_log_init: fopen of file

ROBERTO CATALINA — Fri, 08 May 2009 07:14:37 GMT

The error "rm_log_init: fopen of file" is caused by the FCProvider...

Will be fixed in the next realease of WBEM FCPprovider

Best regards

Re: I caused it: rm_log_init: fopen of file

Jeff_Traigle — Mon, 11 May 2009 16:19:48 GMT

Must be caused by something else, too. We're only seeing this on HP-UX 11.11 with the December 2008 OnlineDiag. We don't have WBEMSvcs, much less FCProvider, installed anywhere on these systems. None of our 11.23 (which also don't have WBEMSvcs installed) or 11.31 (which all do have WBEMSvcs installed) systems are doing this.

Re: I caused it: rm_log_init: fopen of file

Michael Leu — Fri, 10 Jul 2009 12:36:43 GMT

Does anybody know when the next WBEM FCPprovider will be released?

By the way, after a few days the syslog messages change to
rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed: Too many open files

lsof on the HPUXFCIndicationProviderModule process shows it has /etc/opt/resmon/lib/nls/msg/C/resmon.cat opened about 2000 times ;-)

Re: I caused it: rm_log_init: fopen of file

Marko Möbius — Tue, 21 Jul 2009 16:11:51 GMT

We have the same problem, after updating Serviceguard A.11.18 to A.11.19.

Is the fix now available?

Re: I caused it: rm_log_init: fopen of file

Marko Möbius — Wed, 05 Aug 2009 11:46:33 GMT

Same for our environment after updating Serviceguard A.11.18 to A.11.19 (HP-UX 11.23 and 11.31 systems)!

Re: I caused it: rm_log_init: fopen of file

Records Management — Fri, 04 Sep 2009 18:09:10 GMT

I just loaded the new version of WBEM A.02.09, and I still have the error message.

Re: I caused it: rm_log_init: fopen of file

Records Management — Fri, 04 Sep 2009 18:50:24 GMT

Turns out I need to load EMS A.04.20.31.04, which I did.

It didn't fix the problem, but the syslog entry now tells us who is causing it.

Sep 4 15:43:32 hampvmh syslog: rm_log_init: fopen of file /etc/opt/resmon/log/client.log by /opt/wbem/lbin/cimprovagt failed: Permission denied

Re: I caused it: rm_log_init: fopen of file

Michael Leu — Sat, 05 Sep 2009 12:06:43 GMT

Did you also update the WBEM FCProvider?
https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=FCPROVIDER01

They released a new version (.0909) with a fix that might be related, see here:
http://docs.hp.com/en/5900-0170/ch01s05.html

Re: I caused it: rm_log_init: fopen of file

Records Management — Tue, 08 Sep 2009 15:14:28 GMT

Just installed the 0909 FC provider as well as the rest of the updated providers. Also had to load CommonIO.

But, so far the syslog is error free. That's a first for this stuff.

Re: I caused it: rm_log_init: fopen of file

Andre Froebel — Fri, 02 Oct 2009 07:36:17 GMT

Hello All,

seems nobody has yet answered the question regarding the syslog messages:

Apr 15 09:06:56 rmsimage cimserver[12922]: PGS10405: Failed to
deliver an indication: PGS11405: THE CIMEXPORT HTTP HEADER IS
MISSING.

This error appears, whenever a WBEM indication is send to WEBES. WEBES receives the indication and replies with an XML packet, but the entry "CIMEXPORT" is missing in the XML header. So in fact the indication could be delivered, but the reply from WEBES isn't conform to the WBEM specification. This issue should be addresses with the current WEBES release 5.6.

Hope this helps and kind regards,

Andre!

Re: I caused it: rm_log_init: fopen of file

hk_3 — Wed, 11 Nov 2009 08:09:04 GMT

http://bizsupport.austin.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=110&prodSeriesId=3204147&prodTypeId=18964&objectID=c01814954

HP Event Monitoring Service - "rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed: Permission denied"

ISSUE:
The Support Tools Manager (STM) version June 2009 is installed on a HP-UX 11i v2 (11.23) server. After updating Event Monitoring Service (EMS) to version A.04.20.23.02, the following error is now logged every few minutes to /var/adm/syslog/syslog.log :
Jun 15 11:59:58 test1 syslog: rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed: Permission denied
Updating to the current EMS version A.04.20.23.03 does not resolve the error. This also affects HP-UX 11.11 and 11.31 servers.

SOLUTION:
The /etc/opt/resmon/log/client.log file has permissions of 644 and it is owned by the user root. If a non root user process tries to open the file, the error is logged.
A System Fault Management (SFM) process was found which accesses the file. When configuring Remote Support Pack (RSP) for a non root WBEM user, several cimprovagt processes are now running as that user. These processes are started when WBEM subscriptions for the HP-UX server are added to HP Systems Insight Manager (HP SIM).
The HPUXFCIndicationProviderModule is one of those processes.
# ps -ef | grep cimprovagt wbem 15711 15205 0 12:59:03 ? 0:00 /opt/wbem/lbin/cimprovagt 0 5 9 wbem HPUXFCProviderModule
A tusc trace shows the Permission denied error:
open("/etc/opt/resmon/log/client.log", O_WRONLY|O_APPEND|O_CREAT|0x800, 0666) ERR#13 EACCES
The permissions, and owner of the EMS client.log file have not changed. The recent versions added logging the error message for a non root user. This message will be removed again in a future EMS release. The defect request is:
QXCR1000932860 rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed

Workaround:
Change the permissions of the client.log file to 666.
NOTE: Permissions will revert back to 644 when EMS is updated. Every time the log file reaches 500 KB, EMS will automatically create a new log file with 644 permissions. To avoid this, create a file /etc/opt/resmon/unlimited_log:# touch /etc/opt/resmon/unlimited_log This removes the 500 KB limit and rotating log files. It is recommended to make /etc/opt/resmon/log a separate file system in that case to avoid filling up the root file system.