Strange issue in correlation of newwanip (updaterrd.sh)

fireodo

Hi, me again,

today I made a change to a wireless interface that made rc.newwanip to run. This was around 15:22 (local time). As you can see in the screenshot the temperature measuring stopped. After restarting GUI and Webconfigurator on the CLI you can see at ca. 16:15 the temperature measuring working again.
My only clou is that it has something to do with rc.newwanip when it is running from GUI environment.

EDIT: I made a test: running rc.newwanip from GUI CLI - temperature measuring stops, running rc.newwanip from Console CLi - temperature measuring works again. The other monitoring (Quality, Memory, Processor) are not affected ...

EDIT 2: After some observation it seams to be generated by the way updaterrd.sh is rebuild ... (This is replicable in 23.05.1 and 2.7.0 CE and it affects only temperatue monitoring)

Maybe some of the coders could tell more ...

Regards,
fireodo Bildschirmfoto 2023-07-06 um 16.16.42.png

stephenw10

Hmm, curious. The thermal data is collected by /var/db/rrd/updaterrd.sh the same as the other data.

Check that it's running still. Check that the thermal sensors are still in the script.

How exactly are you running rc.newwanip?

What do you see logged when you run it?

Steve

fireodo

@stephenw10 said in Strange issue in correlation of newwanip:

How exactly are you running rc.newwanip?

/etc/rc.newwanip on GUI CLI or
/etc/rc.newwanip on CLI on console or
started by reconfiguration script of an interface

What do you see logged when you run it?
This is when I reconfigurated the WiFi interface:

Jul 6 15:22:47	php	95365	lcdproc: Start client procedure. Error counter: (0)
Jul 6 15:22:44	php_pfb	83409	[pfBlockerNG] filterlog daemon started
Jul 6 15:22:44	tail_pfb	82986	[pfBlockerNG] Firewall Filter Service started
Jul 6 15:22:44	lighttpd_pfb	81487	[pfBlockerNG] DNSBL Webserver started
Jul 6 15:22:43	php_pfb	79353	[pfBlockerNG] filterlog daemon stopped
Jul 6 15:22:43	lighttpd_pfb	79041	[pfBlockerNG] DNSBL Webserver stopped
Jul 6 15:22:43	tail_pfb	79013	[pfBlockerNG] Firewall Filter Service stopped
Jul 6 15:22:42	xinetd	32785	Reconfigured: new=0 old=1 dropped=0 (services)
Jul 6 15:22:42	xinetd	32785	readjusting service 19000-tcp
Jul 6 15:22:42	xinetd	32785	Swapping defaults
Jul 6 15:22:42	xinetd	32785	Starting reconfiguration
Jul 6 15:22:42	php-fpm	83883	/rc.start_packages: Restarting/Starting all packages.
Jul 6 15:22:41	check_reload_status	2364	Starting packages
Jul 6 15:22:41	php-fpm	13437	/interfaces.php: Generiere RRD Update Script
Jul 6 15:22:41	check_reload_status	2364	Reloading filter
Jul 6 15:22:41	php-fpm	13437	/interfaces.php: Statische Route für Monitor 217.xxx.xxx.xxx wird entfernet und eine neue Route über 62.155.245.88 hinzugefügt
Jul 6 15:22:41	php-fpm	13437	/interfaces.php: Neusynchronisierung von OpenVPN-Instanzen für die Schnittstelle WIFI.
Jul 6 15:22:39	check_reload_status	2364	updating dyndns opt1
Jul 6 15:22:39	check_reload_status	2364	Restarting IPsec tunnels

stephenw10

You don't actually see rc.newwanip logged? Like:

Jul 6 16:47:25 	php-cgi 	73825 	rc.newwanip: rc.newwanip: Info: starting on .
Jul 6 16:47:25 	php-cgi 	73825 	rc.newwanip: rc.newwanip: on (IP address: 172.21.16.232) (interface: WAN[wan]) (real interface: ix3).
Jul 6 16:47:25 	check_reload_status 	1155 	Carp backup event
Jul 6 16:47:25 	kernel 		carp: 1@ix3: MASTER -> INIT (hardware interface up)
Jul 6 16:47:25 	kernel 		carp: 1@ix3: INIT -> BACKUP (initialization complete)
Jul 6 16:47:25 	check_reload_status 	1155 	Carp backup event
Jul 6 16:47:25 	kernel 		gre0: link state changed to DOWN
Jul 6 16:47:25 	kernel 		gre0: link state changed to UP
Jul 6 16:47:25 	kernel 		gif0: link state changed to DOWN
Jul 6 16:47:25 	kernel 		gif0: link state changed to UP
Jul 6 16:47:26 	php-fpm 	69339 	/rc.carpbackup: HA cluster member "(45.65.87.21@ix3): (WAN)" has resumed CARP state "BACKUP" for vhid 1
Jul 6 16:47:26 	php-fpm 	11883 	/rc.carpbackup: HA cluster member "(45.65.87.21@ix3): (WAN)" has resumed CARP state "BACKUP" for vhid 1
Jul 6 16:47:26 	ppp 	38099 	[opt1_link0] PPPoE connection timeout after 9 seconds
Jul 6 16:47:26 	ppp 	38099 	[opt1_link0] Link: DOWN event
Jul 6 16:47:26 	ppp 	38099 	[opt1_link0] LCP: Down event
Jul 6 16:47:26 	ppp 	38099 	[opt1_link0] Link: reconnection attempt 6760 in 2 seconds
Jul 6 16:47:27 	rc.gateway_alarm 	8018 	>>> Gateway alarm: VTI0_VTIV4 (Addr:10.45.13.2 Alarm:1 RTT:0ms RTTsd:0ms Loss:100%)
Jul 6 16:47:27 	check_reload_status 	1155 	updating dyndns VTI0_VTIV4
Jul 6 16:47:27 	check_reload_status 	1155 	Restarting IPsec tunnels
Jul 6 16:47:27 	check_reload_status 	1155 	Restarting OpenVPN tunnels/interfaces
Jul 6 16:47:27 	check_reload_status 	1155 	Reloading filter
Jul 6 16:47:27 	kernel 		gre0: link state changed to DOWN
Jul 6 16:47:27 	kernel 		gre0: link state changed to UP
Jul 6 16:47:27 	php-cgi 	73825 	rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Jul 6 16:47:27 	check_reload_status 	1155 	Reloading filter
Jul 6 16:47:28 	check_reload_status 	1155 	Carp master event
Jul 6 16:47:28 	kernel 		carp: 1@ix3: BACKUP -> MASTER (master timed out)
Jul 6 16:47:28 	php-fpm 	27932 	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Jul 6 16:47:28 	php-fpm 	27932 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use VTI0_VTIV4.

Does it do it when you run it against a particular interface? Which is how rc.newwanip is usually run.

fireodo

@stephenw10 said in Strange issue in correlation of newwanip:

Does it do it when you run it against a particular interface? Which is how rc.newwanip is usually run.

It dont make any difference if it runs against a particular interface or not - but it does make a difference if it is running in the CLI on the GUI or in the CLI on the console ...

EDIT: I guess I found something - using the native english GUI the problem does not occur (I am using the german translation) Maybe launching newwanip from the GUI is generating a faulty time/date format (language specific) and launching it from console makes the correct time/date format ... guessing ...

stephenw10

Ah, that seems familiar.... hmmm

No errors logged?

This perhaps? https://redmine.pfsense.org/issues/13776

Though rc.newwanip should never normally be run from there.

fireodo

@stephenw10 said in Strange issue in correlation of newwanip:

No errors logged?

No errors logged ...

This perhaps? https://redmine.pfsense.org/issues/13776

Could be a approach ...

stephenw10

Ok so, to be clear, if you run rc.newwanip manually via Diag > Command Prompt and you have the system language set to soemthing other than the default (English) then the thermal sensors stop logging RRD data?

Any other method calling rc.newwanip does not?

fireodo

@stephenw10 said in Strange issue in correlation of newwanip:

Ok so, to be clear, if you run rc.newwanip manually via Diag > Command Prompt and you have the system language set to soemthing other than the default (English) then the thermal sensors stop logging RRD data?

Correct! That are my findings until now. (I <guess> its in the way that updaterrd.sh is rebuilded ... </guess>

Any other method calling rc.newwanip does not?

Yes that is correct too! (at the ssh console cli)

stephenw10

Ok did you test with any other language selected other than German? (or English)

fireodo

@stephenw10 said in Strange issue in correlation of newwanip:

Ok did you test with any other language selected other than German? (or English)

Only German and English