callattendant after so long crashes but logs not really showing

[comet424]

so ive noticed a few crashes of callattendant... i did set it to debug mode ... but i didnt get much more in the log...

this is what i got when i noticed it down

pi@callerid:~ $ sudo systemctl status callattendant.service
× callattendant.service - Call Attendant
     Loaded: loaded (/lib/systemd/system/callattendant.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2024-06-04 20:26:59 EDT; 14h ago
   Duration: 1w 1d 11h 21min 21.806s
    Process: 17691 ExecStart=/home/pi/venv/bin/callattendant --config app.cfg (code=exited, status=1/FAILURE)
   Main PID: 17691 (code=exited, status=1/FAILURE)
        CPU: 18min 12.872s

Jun 04 20:26:59 callerid callattendant[17691]: Modem thread exiting
Jun 04 20:26:59 callerid callattendant[17691]: -> Closing modem serial port
Jun 04 20:26:59 callerid callattendant[17691]: -> Stopping voice mail
Jun 04 20:26:59 callerid callattendant[17691]: Message Event triggered
Jun 04 20:26:59 callerid callattendant[17691]: -> Releasing resources
Jun 04 20:26:59 callerid callattendant[17691]: -> Stopping MQTT client
Jun 04 20:26:59 callerid callattendant[17691]: Shutdown finished
Jun 04 20:26:59 callerid systemd[1]: callattendant.service: Main process exited, code=exited, status=1/FAILURE
Jun 04 20:26:59 callerid systemd[1]: callattendant.service: Failed with result 'exit-code'.
Jun 04 20:26:59 callerid systemd[1]: callattendant.service: Consumed 18min 12.872s CPU time.

is there somewhere else to get more log i wont reboot callattendant incase i can retrieve more log info

or where is the debug log file save located?

and is there a way to see if Auto Updates is what affects Callattendant to crash

[thess]

The log is still there - systemctl status only shows you the tail of the log. Use journal -b -u callattendant and you will get all CA related message since the last boot of the system. man journalctl for other options to specify a time span. The systemd service log is not a text file - you need to use journalctl to view it.

Until I see the actual crash data, anything I say is speculation.

[comet424]

ok here is the log file
log.txt

[comet424]

if there is anything else i need to do let me know before i do a reboot or restart the service... as i havent restarted the service incase it over writes any important log info

[thess]

You can go ahead an restart anytime. There will be no data loss - the logs are accumulated for quite a long period and managed by the system and logrotate processes.

It looks like all your problems are happening while contacting the nomorobo service. DNS lookup failures and read timeouts. The best I can do is make to code a bit more resilient when errors occur communicating with NOMOROBO. If I were you, I'd want to know why you are seeing frequent communication failures to the external service.

[comet424]

i have a 5megabit internet with a 500k upload if that... and we doing stuff it gets maxed out as i live out in rural country area i cant get fast internet like people that live in town.. so im limited to like i had in 80s 90s early 2000s dial up connection so poor phone lline maxed out internet... as you cant even stream alot unless you reduce video quality...
so what exactly is the nomorobo i seen when i used it on bruces it was for usa.. and i remember i set it to blank since it was usa only but here i set it default.... as i never noticed a difference here in canada a difference between the 2 unless it does something special for spam callers...

but ya i have poor internet and i pay 120 bucks a month for 5megabit internet but if i live in town you can get cheaper... and cell tower internet where i live is poor reception too.. so its not better unless i go Starlink sat internet but thats crazy price

[comet424]

at least its not the auto update of the raspbarry pi... and maybe you can add in your documents how to read the logs using that journalctl that be good to add
it be good if it could output to a log file as long as you dont reboot it... like a in the Config.. save to a config .. or if the program quit... it does like windows does... it does a crash dump ... maybe you could add a crash dump too like journal >>logtimedate.log then if you happen to reboot or restart or whatever the dump log file isnt lost.. and you have to wait till another crash...
but thats just some suggestions maybe for future

[thess]

Nomorobo is a free service which rates phone #'s reported as spam, solicitations, political calls, etc. You don't have to use it - Just set:

BLOCK_SERVICE = ""

In your app.cfg and you won't have these issues as it looks like you network is occasionally degraded enough to not complete a simple http/get transaction to this service. I will update the interfaces to the block services to be more resilient to network failures.

[comet424]

so i rebooted had phone call but the mqtt didnt work i noticed... i checked the logs. and some error.. i not sure if it has anything to do wit that last crash... i havent changed the app.cfg yet all i done so far was just a reboot so raspberry pi loaded up cleanly

log2.txt

[comet424]

and i dont use my mqtt so my code no longer in your code... if you were wondering if mine might have crashed it... as i use mosquitto client after a call happen so thats no longer in there anymore back to factory code

[thess]

MQTT connection failure (timeout) -- Once again, your system is struggling with the network.

[comet424]

ah figured you ment the first one be internet network struggling

this 2nd one with the mqtt reconnect well i dunno mqtt seems to be working all over but ill give everything a re reboot... switchs Mqtt server the callattendant.. and see what happens and ill re boot my router... and see if that changes anything in the next calls that happen..
and go from there i guess..

fingers crossed (:

[thess]

Issue resolved by 02cb916 . Callattendant should continue operations if errors occur communicating with either BLOCK_SERVICE or MQTT due to network failures or timeout.

[comet424]

ah ok.. i run into another issue.. MQTT decided not to work now... there is no timeout it just doesnt run i guess?

my mqtt server is the 192.168.0.12 and i guess in the logs the GET and 200 is my poling i do from Home assistant i found a way to acknowlege the webpage is up... but when a call comes in MQTT isnt running it looks like...
is it still a timeout issue? i did reboot everything
log3.txt

[comet424]

and when the auto update runs does it update your callattendant too then? or if not how do i run update on the callattendant

and the nomobro is that the same like on my cell phone sometimes i get a phone call and it says under the number Reported Fraud or possibly Scammer... is that the nomboro?

[comet424]

im sure ull say its my network issue... so i gonna reboot everything again switchs server router everything.... as im sure youll say its fine..
so i going to do a clean boot of everything now start fresh again.. and go from there

[thess]

Auto update via whatever OS based package updater you are using does nothing with Callattendant. Updates to CA are up to you when/how to do it. I suggest you only install released versions unless you want to try out recently moded development stuff. Personally, I would not recommend using an auto-updater for anything unless you are willing to have random mis-configurations or worse. Do your updates manually when you can verify everything is still working.

Yes, the NoMoRobo service CA is querying is the same one used by your service provider however, thru a different interface - web page scrape vs. subscriber API.

Now - as far as network and mosquitto service issues go,,, If they are not causing any problems in CA, they are your problems. The log you posted (log3.txt) shows no errors at all. If your mosquitto server is not handling the data they way you expected, you can verify its behavior better with mosquitto_sub than thru the publishing client showing no errors.

[comet424]

ah ok... i figured auto update updated all programs good to know i figured anything thats installed... and i using raspbian desktop...

and ok so least i know the NoMoRobo is basiclly that.. as my cell phone has been doing that the first time in the last month Possible Spammer.. Fraud etc

so MQTT seems to be broken in Callattendant and not my side. Mosquitto Client can MQTT but the Callattendant isnt Sending MQTT

as for the mosquittp_sub i ran the program you told me to run before... and i getting an error... is it saying it cant connect to 192.168.0.12:1883 ? as mqtt isnt working for Callattendant ,, mqtt works for everything else... is there a test i can do?

Jun 07 15:56:44 callerid callattendant[1417]: RING
Jun 07 15:56:44 callerid callattendant[1417]: RING LED blinking: 10 times
Jun 07 15:56:44 callerid callattendant[1417]:  > > > Ring count: 3
Jun 07 15:56:48 callerid callattendant[1417]: 192.168.0.12 - - [07/Jun/2024 15:56:48] "GET / HTTP/1.1" 200 -
Jun 07 15:56:50 callerid callattendant[1417]: RING
Jun 07 15:56:50 callerid callattendant[1417]: RING LED blinking: 10 times
Jun 07 15:56:50 callerid callattendant[1417]:  > > > Ring count: 4
Jun 07 15:56:51 callerid callattendant[1417]: RING LED turned off
Jun 07 15:56:59 callerid callattendant[1417]:  > > > Ringing stopped: Caller hung up or callee answered
Jun 07 15:56:59 callerid callattendant[1417]: Waiting for next call...
pi@callerid:~ $ mosquitto_sub -h -v -t callattendant/#
Unable to connect (Lookup error.).
pi@callerid:~ $ mosquitto_sub -h -v -t callattendant/#
Unable to connect (Lookup error.).
pi@callerid:~ $ ping 192.168.0.12
PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=0.253 ms
64 bytes from 192.168.0.12: icmp_seq=2 ttl=64 time=0.215 ms
64 bytes from 192.168.0.12: icmp_seq=3 ttl=64 time=0.256 ms
64 bytes from 192.168.0.12: icmp_seq=4 ttl=64 time=0.261 ms
64 bytes from 192.168.0.12: icmp_seq=5 ttl=64 time=0.217 ms
64 bytes from 192.168.0.12: icmp_seq=6 ttl=64 time=0.292 ms
64 bytes from 192.168.0.12: icmp_seq=7 ttl=64 time=0.292 ms
64 bytes from 192.168.0.12: icmp_seq=8 ttl=64 time=0.330 ms
^X^C
--- 192.168.0.12 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7165ms
rtt min/avg/max/mdev = 0.215/0.264/0.330/0.036 ms
pi@callerid:~ $ mosquitto_sub -h -v -t callattendant/#
Unable to connect (Lookup error.).
pi@callerid:~ $ mosquitto_pub -t "callerid/caller" -m "this is a test" -h 192.168.0.12 -d --will-qos 1 -u "mqtt-user" -P
 "*******"
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'callerid/caller', ... (14 bytes))
Client (null) sending DISCONNECT
pi@callerid:~ $ mosquitto_sub -h -v -t callerid/#
Unable to connect (Lookup error.).

so the way i do it works no issue but im not getting no callattendant mqtts anymore and i getting lookup error but when i mosquitto_pub to the mqtt server the messages get there... but right now the calls comming in for callattendant isnt working but if if mosquitto_pub -t "callattendant/caller" that works too for me. its getting the message.. its not seeming to get it out of the callattendant program

is there more tests i can do???

this image shows the Mosquitto_sub sending the this is a test message from the command line works fine connecting but its not working in CA

[comet424]

do i need to re install something the mqtt paho or something?

[comet424]

are there any other tests i can do? that can give you more info?

[thess]

The -h option in mosquitto_sub requires an argument - namely the host name or address.

$ mosquitto_sub -h 192.168.0.12 -v -t callattendant/#

will probably yield better results ;)

[comet424]

in the other chat you had me type that and it returned values didnt need to return values on the local callattendant

but i got this error now

pi@callerid:~ $ mosquitto_sub -h 192.168.0.12 -v -t callerid/#
Connection error: Connection Refused: not authorised.
pi@callerid:~ $ mosquitto_sub -h 192.168.0.12 -v -t callattendant/#
Connection error: Connection Refused: not authorised.
pi@callerid:~ $ mosquitto_sub -h 192.168.0.20 -v -t callattendant/#
Error: Connection refused

and here i thought -h stood for history to show you the history of callattendants last mqtts it last sent out

mqtt server and home assistant are on 192.168.0.12
callerid PI aka Callattendant is on 192.168.0.20

i got like 20+ devices that talk to mqtt server including wheere i showed i can use the mosquito_pub and it can send no issues
i dont know what else to trouble shoot..

too bad your logs dont show it sending MQTT to send "Sending MQTT Name" etc least u know its running or something

wish i knew this stuff like i know windows lol

i tried to
pi@callerid:~ $ mosquitto_sub -h 192.168.0.20 -v -t callattendant/#
Error: Connection refused

on the callattendant pi but connection refused just to see if its least getting trying to send

[thess]

Note also you have MQTT_INDICATOR_TYPE = EVENT so if no-one is listening/subscribed you won't see it if you poll after the event has occurred. You can't have it both ways (retained or not).

[comet424]

ok so what does each mean i read that and didnt understand that what i read
so what does each do... and what should i have?

[comet424]

i think i changed it cuz i was having issues and i thought event ment only work when a call happened
but ill change it back

[thess]

Good grief -- RTFM man. Or, at least man mosquitto_sub or else STFW.

$ mosquitto_sub -h 192.168.0.12 -v -t callerid/#
Connection error: Connection Refused: not authorised.

So, in your case, supply the credentials as you did to publish with mosquitto_pub. I'm not responsible for your environment.

[thess]

too bad your logs dont show it sending MQTT to send "Sending MQTT Name" etc least u know its running or something

Ah, but it does. The LED on/off, blink messages etc. in the log show the MQTT messages being queued to the server. If there is no other output wrt MQTT, there were no errors. So, from your logs, the messages were sent OK to the server as you configured.

[comet424]

ah ok... i set that subscribe up to monitor see if i can see anything... first couple calls worked i letting it sit

and ah ok.. ya i noticed in the logs.txt it sent mqtt client null it sent mqtt info but by log 3 it sends ring and led on off

so for now i set the nomboro ""
and set the mqtt type to "STATE"

and running the subscribe through a terminal window so i can monitor as i never used anything of this mqtt all devices have built in mqtt fill in name and password and server ip and off u go basiclly... so i dont know these sub etc

i only knew the mosquitto pub a few years ago and set and forget it kinda thing...

but always learning... i recently switched over to 10gig networking so not sure that is conflicting out of my scope... but i appreciate the help so far... with my learning disabilities it takes me along time to under stand things and re read things 10 20 times before i understand things too... so i appreciate your time and patience

so hoping me going back to state and "" will solve the issues fingers crossed