Logwatch dont find logfiles in Windows OS if agent called from remote

Troubleshooting
1

CMK version:
1.6
OS version:
Windows
Error message:
No error, just shows nothing
Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)

Hello,

I have here a weird issue.
I want to run logwatch plugin on Windows host against some log files.
If I run the agent with `.\check_mk_agent.exe test’ locally as administrator, all works as expected and I can see the logfiles in the [[[]]] sections.
If I run the agent from remote, via WATO or Telnet, it just shows me the empty sections from system log which comes from agent and not from plugin:

<<<logwatch>>>
[[[Application]]]
[[[System]]]

The drive where the logfiles are located is a local drive and the permissions on the file is everyone Full Control. In Effective access permissions I see that the SYSTEM account has rights too read the fies.

image
image891×710 27 KB

I guess its an issue with permission but I am not a Windows expert and dont know where else the access may blocked.

Any help is much appreciated.

Thanks in advance

Michael

2

Hi @mike1098 ,
if every one is having full control, why system just have read rights?! And why is the access limited by share?
Because we have also trouble with logwatch (with 2.1p9 and above) here a fast pic from a testlog file from us:

logwatch-system
logwatch-system765×813 76.9 KB

3

The effectve rights of `everyone on this file is 0

Thats the questions I cannot answer because I have no idea about Windows right´s system.

I just create a file c:\temp\test.txt. It shows me exact effective rights as you showed, but the same results. Nothing in remote agent output :frowning:

regards

Michael

4

I just download psexec from sysinternals and started a shell with system account:

C:\Temp>whoami
nt authority\system

C:\Temp>more TEST.txt
WARNING
CRITICAL
Test

C:\Temp>

Smells like a bug…

5

Just to be sure, the plugin for windows logwatch is there?

6

If not I wouldn’t see the files if I run the agent locally with option test :wink:

7

Ah, right :wink:

In 2.1 with p9 & p10 there was changes on the logwatch.
It is the line with “BATCH”… the server could not deal with it.
But i did not think thats your problem, doesn´t matter if your are admin or system.
If it works as admin and not as system sounds like permissons.

Please show me the output when you do the test with the admin account:

logtest.log:

OK
Warnung
Warnung
Kritisch
Kritisch

logwatch output:

<<<logwatch>>>
[[[c:\temp\logtest.log]]]
BATCH: 1662392860-211095051134062069186092075043192051122177080009
C Kritisch
C Kritisch
8

Its even worth, I started logwatch in a cmd as system user and all works fine.

My logwatch.cfg:

C:\temp\test.txt
 W WARNING
 C CRITICAL
 
CLUSTER monpilot
 10.20.30.40
 10.20.30.41

C:\ProgramData\checkmk\agent\plugins>whoami
nt authority\system

C:\ProgramData\checkmk\agent\plugins>mk_logwatch.exe -vvv
<<<logwatch>>>
[[[C:\temp\test.txt]]]

If I do it with telnet I get only <<>>
So I did another test and wrote a little test plugin:

@echo off
echo ^<^<^<test^>^>^>
more c:\temp\test.txt

Agent output from telnet:

<<<logwatch>>>
<<<test>>>
WARNING
CRITICAL
Test

Both way demonstrate that system account has access to the files.

Finally I found out that the problem comes from the CLUSTER option. If I complete remove that it works. IP´s are correct set.
Will do further investigations and finally open a ticket.

thanks

Michael

1 Like
9

Hitting the same problem with 2.1.p12 agent on Windows with the python logwatch plugin.

I get the same output of “BATCH: 1663648993-190202132092003060165118230195049120189104124175” in the logwatch plugin output.

When running the logwatch command manually it seems to work ok and produce output for the logfile. When running from the agent there is no output produced.

10

Hi @burgeau
the “BATCH” thing is a bug, will be fixed in a coming update.
Look here but is a german discussion.

11

Do you use the CLUSTER option in logwatch.cfg?

12

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.