I Ctrl-C out of the debug mode and start mycroft with ‘service mycroft start’. I wait a minute and speak ‘Hey Mycroft’. I look at /var/log/mycroft/voice.log and I see:
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
2021-01-23 16:08:07.901 | INFO | 4696 | __main__:handle_record_begin:37 | Begin Recording...
2021-01-23 16:08:14.178 | INFO | 4696 | __main__:handle_record_end:45 | End Recording...
2021-01-23 16:08:15.598 | ERROR | 4696 | mycroft.client.speech.listener:transcribe:239 | list index out of range
2021-01-23 16:08:15.601 | ERROR | 4696 | mycroft.client.speech.listener:transcribe:240 | Speech Recognition could not understand audio
So why the ‘Connection refused’? Hmm, maybe it’s running as root and not as pi?
Following up on my own reply. No, both in interactive mode and ‘systemctl mode’, all processes are running as pi.
Another thought - might the registration code not be getting sent in systemctl mode? So the mycroft.ai server is not recognizing my device as being being registered?
I searched the web and saw a similar issue by ‘marko’ in 2019.
I hate to sound like a broken record, but, what’s actually running when you start with the systemd start up vs debug? What all is in the logs of note from the systemd start up? What’s different for those on the debug startup?
Secondly; can you post the content of your pulseaudio.service file?
Thirdly; if the pulseaudio service is not running as the pi user, but a dedicated user instead. Did you add the pi user to the pulse and pulse-acces group?
It sounds to me, you do not start pulseaudio as system wide deamon utilizing pulseaudio.service.
If you start mycroft manually by CLI, it starts a session of pulseaudio for that program.
If you start mycroft via systemd, you state that it should start only after the pulseaudio service, but of course you need to make sure you also enable it at boot and that the pulseaudio service indeed is started and running for mycroft to connect to.
So what is the content of your pulseaudio.service file?
What does “sudo systemctl status pulseaudio” say?
I added an /etc/systemd/system/pulseaudio script, and that shows it is running after a reboot.
But mycroft still fails
After digging some, I see this:
journalctl -xe | grep mycroft
...
raspberrypi mycroft-start[785]: fatal: unable to access 'https://github.com/MycroftAI/mycroft-core.git/': Could not resolve host: github.com
...
So is mycroft trying to start too early and can’t get out to the internet?
I tried adding various 'after=network’s , all to no avail.
I also tried an old-fashioned /etc/init.d/mycroft script. This also failed where I see:
Jan 27 19:56:23 raspberrypi polkitd(authority=local)[485]: Operator of unix-process:1389:31208 successfully authenticated as unix-user:pi to gain ONE-SHOT authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.48 [/bin/systemctl --no-pager start mycroft.service] (owned by unix-user:pi)
There are so many bits and pieces that need to be aligned properly that it is just a lot easier for me if you just post your files instead of snippets. I still believe your issues lies in mycroft not being allowed to talk properly with pulse audio.
I added a line for mycroft to wait 30 seconds to the systemd file:
ExecStartPre=/bin/sleep 30
Then I rebooted and got an SSH session while mycroft was sleeping:
$ service mycroft status
● mycroft.service - Mycroft AI
Loaded: loaded (/etc/systemd/system/mycroft.service; enabled; vendor preset: enabled)
Active: activating (start-pre) since Sat 2021-01-30 06:50:34 EST; 16s ago
Cntrl PID: 788 (sleep)
Tasks: 1 (limit: 2063)
CGroup: /system.slice/mycroft.service
└─788 /bin/sleep 30
The service failed again, but differently:
$ journalctl -xe | grep mycroft
-- Subject: A start job for unit mycroft.service has begun execution
-- A start job for unit mycroft.service has begun execution.
-- Subject: A start job for unit mycroft.service has finished successfully
-- A start job for unit mycroft.service has finished successfully.
Jan 30 06:51:17 raspberrypi mycroft-start[1192]: error: insufficient permission for adding an object to repository database .git/objects
...
What would cause this error message?
I can still start mycroft interactively with either ‘all’ or ‘debug’.
I finally got back to mycroft (wow, 4 months went by), and am still trying to start mycroft as a systemd service. I go to /var/log/mycroft and look at log files:
$ grep tmp /var/log/mycroft/bus.log
PermissionError: [Errno 13] Permission denied: '/tmp/mycroft/service.pid'
... many dups of above ...
So I set the ownership of /tmp/mycroft to pi, then reboot.
$ sudo chown pi.pi /tmp/mycroft
$ sudo reboot
When the pi is back up, the mycroft service is still not running. I see the ownership of /tmp/mycroft is back to root:
$ ls -ld /tmp/mycroft
drwxr-xr-x 4 root root 4096 May 30 15:12 /tmp/mycroft
So this begs the question, “Is some code in the mycroft start process changing the ownership of that directory?”
