[WMARN38] warningfor when using external_line1 hint for ICON

[solarmon]

Hi,

I'm making use of the "TARGET !scriptname" datasource method - as per https://network-weathermap.com/manual/0 ... tml#script.

I'm able to successfully run a script (after enabling lib/datasources/WeatherMapDataSource_external.php) and it returns the four line values as required.

I want to then use ICON and use the hint variable external_line1 to choose which image to display - for example:

Code: Select all

ICON 16 16 images/updown_{node:this:external_line1}.png

However, it seems that weathermap generates the following warning:

Code: Select all

WARNING: configs/simple.conf: ICON 'images/updown_down.png' does not exist, or is not readable. Check path and permissions. [WMARN38]

It resolves the hint variable as expected, and the image file path and name is correct and does exist. If I use that file path/name directly, or if I use another hint variable that has been created by SET, it does not have the warning/error.

Any ideas why using the hint variable external_line1 would cause this error, even though it seems to resolve OK?

Thank you.

[Howie]

Interesting one!

When you are switching to the other variable, are you also removing the target? I'm just wondering if the external DS plugin changes the working directory, so that the relative path for your icon is no longer valid. Can't think of much else that would cause this...

Or maybe I'm doing something silly like not removing the CR-LF from the lines, so the filename has a \n on the end.

I'll investigate further.

[solarmon]

Thanks for your quick response.

An interesting update from me. I also run the same script (to start the weathermap processing) in cron.

When it runs in cron (as root) it does not seem to have this issue (the status icons appear as expected) and I assume there are no warnings as I don't get to see the output.

It is only when I run the script manually (as root) that I get this error, and the status icons do not get drawn.

Yes, to answer you question about using another SET variable, I've kept the TARGET as is, and only change ICON to use the SET variable.

[solarmon]

I wanted to test that when manually running the script whether there was a permissions issue with the image path/filename.

So I created NODE to draw the (down status) image:

Code: Select all

NODE Test_updown
	ICON 16 16 images/updown_down.png
	POSITION 20 20

When I manually run the script, there are no issues with this test NODE, but there is still the issue with the NODEs that use the "external_line1" hint variable.

[solarmon]

I added some debugging output to the DS external plugin:

#### Working Dir: /usr/local/weathermap | external_line1 = 'down' ####
#### Working Dir: /usr/local/weathermap | external_line1 = 'up' ####

(Note: I'm actually using weathermap in standalone mode and not as a plugin in Cacti).

So it doesn't change the working directory, and it does strip any whitespace characters (since it uses rtrim) for the line.

[Howie]

Thanks for the updates. I'll try to recreate this one this evening.

(btw, for the cron job, check /var/mail/root - cron typically mails output to the local user than ran the task)

[solarmon]

OK - I think I've figured it out.

Although the plugin trims the end of the line, it does not trim the start of the line.

I figured out that my script (or rather, what it was subsequently launching) was adding the hidden whitespace to the start of the line:

Code: Select all

[ESC][?1034h

Even though I tried changing the DS plugin to use trim(), but that didn't seem to work.

I eventually figured out how to get rid of the hidden whitespace, and the error was resolved.

Maybe you can figure out how to trim such whitespace for the start of a line.

[Howie]

Well... that's not technically whitespace. Looks like it's an ANSI terminal control character (e.g. bold on, or something like that).

So in your script, you could do something like

Code: Select all

the_other_script | sed '/[^a-zA-Z0-9]//g'

If you know everything that is valid output.

[solarmon]

Yeah, whitespace was the wrong term to use - I was just too lazy to lookup what correct terminology.

The issue seems to be with how python outputs depending on the environment terminal type.

Some articles I've found related to the issue:

https://stackoverflow.com/questions/157 ... ing-import
https://sft.its.cern.ch/jira/browse/ROOT-5041

It seems that if terminal type is xterm then it outputs these control characters. If the terminal type is vt100 then it doesn't.

I suppose this maps to why when I ran the script manually (terminal type xterm?) it see the issue, but when cron runs it (terminal type vt100?) then there was no issue.