I have the latest 2.5-pre on a docker NAS as a server and a pi zero with respeaker running as a venv (also latest 2.5 pre), both speaking through MQTT.
Everything works quite fine when I manually start rhasspy on the pi zero, hotword is recognised, intents are passed as hass events, etc.
BUT I can’t make it run as a service.
run the following commands
systemctl --user daemon-reload
systemctl --user start rhasspy
systemctl --user enable --now rhasspy
I have the following issues :
it doesnt start at boot. I tried to replace WantedBy=multi-user.target by WantedBy=default.target as found in google and that seems to do the job
I can get the web UI on the pi zero,
manual recognition of text works (so both server and satellite seems to communicate) but intent is not passed to hass (which works when manually started)
hotword detection works but the asr/nlu/toggleOff is broken, basically it starts listening and that’s it, the pi zero doesn’t get back to iddle state
try after=dhcpcd as that is always really late in the boot order also I always get that wrong but that service spelt correct.
The wants=graphical.target is later and doesn’t have to occur so try that with dhcpd
prob need systemctl status rhasspy and journalctl -b of what it fails on
Prob a lot happening at start and get things to start later?
ExecStartPre=/bin/sleep 10
TimeoutStartSec=0 Or maybe set bigger than default?
Thanks for the suggestions @rolyan_trauts but still no luck.
journalctl gives me these erros, errors I dont have when manually running rhasspy-satellite/bin/rhasspy-satellite --profile fr
avril 29 17:22:00 respeaker rhasspy[483]: Starting services...
avril 29 17:22:09 respeaker rhasspy[483]: 2020-04-29 17:22:09,545 INFO supervisord started with pid 700
avril 29 17:22:10 respeaker rhasspy[483]: 2020-04-29 17:22:10,619 INFO spawnerr: unknown error making dispatchers for 'microphone': ENXIO
avril 29 17:22:10 respeaker rhasspy[483]: 2020-04-29 17:22:10,663 INFO spawnerr: unknown error making dispatchers for 'intent_handling': ENXIO
avril 29 17:22:10 respeaker rhasspy[483]: 2020-04-29 17:22:10,678 INFO spawnerr: unknown error making dispatchers for 'wake_word': ENXIO
avril 29 17:22:11 respeaker rhasspy[483]: 2020-04-29 17:22:11,761 INFO spawnerr: unknown error making dispatchers for 'microphone': ENXIO
avril 29 17:22:11 respeaker rhasspy[483]: 2020-04-29 17:22:11,833 INFO spawnerr: unknown error making dispatchers for 'intent_handling': ENXIO
avril 29 17:22:11 respeaker rhasspy[483]: 2020-04-29 17:22:11,880 INFO spawnerr: unknown error making dispatchers for 'wake_word': ENXIO
avril 29 17:22:13 respeaker rhasspy[483]: 2020-04-29 17:22:13,943 INFO spawnerr: unknown error making dispatchers for 'microphone': ENXIO
avril 29 17:22:14 respeaker rhasspy[483]: 2020-04-29 17:22:14,002 INFO spawnerr: unknown error making dispatchers for 'intent_handling': ENXIO
avril 29 17:22:14 respeaker rhasspy[483]: 2020-04-29 17:22:14,018 INFO spawnerr: unknown error making dispatchers for 'wake_word': ENXIO
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,087 INFO spawnerr: unknown error making dispatchers for 'microphone': ENXIO
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,099 INFO gave up: microphone entered FATAL state, too many start retries too quickly
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,135 INFO spawnerr: unknown error making dispatchers for 'intent_handling': ENXIO
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,159 INFO gave up: intent_handling entered FATAL state, too many start retries too quickly
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,203 INFO spawnerr: unknown error making dispatchers for 'wake_word': ENXIO
avril 29 17:22:17 respeaker rhasspy[483]: 2020-04-29 17:22:17,206 INFO gave up: wake_word entered FATAL state, too many start retries too quickly
avril 29 17:22:26 respeaker rhasspy[483]: [DEBUG:2020-04-29 17:22:26,237] rhasspyserver_hermes: Namespace(certfile=None, host='0.0.0.0', keyfile=None, local_mqtt_port=12183, log_fo
avril 29 17:22:28 respeaker rhasspy[483]: [DEBUG:2020-04-29 17:22:28,299] rhasspyprofile.profile: Loading /home/pi/rhasspy-satellite/rhasspy-profile/rhasspyprofile/profiles/fr/prof
avril 29 17:22:28 respeaker rhasspy[483]: [DEBUG:2020-04-29 17:22:28,315] rhasspyprofile.profile: Loading /home/pi/.config/rhasspy/profiles/fr/profile.json
At a guess there is prob just far too much happening at one time for a Pi Zero is capable of.
Guess you will have to have a look at systemd-analyze -h and see what is happening, but I think there is so much load things are taking such a long time they are restarting, retaining load until they fail.
In the scripts to start you prob need to add some delays.
Its prob a pointless exercise though as it is a Pi Zero.
Think you might be the only one trying to run the full 2.5 venv on a pi zero.
But maybe others will comment have you done a Top or Htop and had a look at your load?
What is the load through boot and for the first couple of minutes?
I found a workaround solution few days ago but as it’s not clean, i did not share it, thinking i’ll have time to analyze what. But not
So here is quick and dirty solution.
As I understand it, systemd takes control of standard output and error because it redirects them to the journal. However supervisord uses those to control the processes AFAICU. Anyway this needs further study. Maybe I’ll open an issue on GitHub.
Describing same problem in 2.5, venv, run with systemd impossible on raspberry pi 3, I assume this makes running rhasspy 2.5 impossible in venv on any systemd linux system (basically all of them).
Can’t find the github issue - is there any new development here?
I applied the suggested patch here in a copy of rhasspy-voltron start script (copied to rhasspy-voltron-systemd). It seems to survive restarts - I still see lots of messages in journalctl.
Does it make sense to play with just setting StandardOutput=null in the unit file?