Mycroft on Raspberry Pi OS only works in debug mode

General Discussion
1

Hi Mycroft community,

I’m hoping to be back - was active with Mycroft but then COVID changed everything. :((

I was using Pycroft because it’s just so turnkey. But I want to utilize the power of a RasPi 4 as a general purpose computer. So I switched to the 12/2/2020 version of what used to be called Raspbian. I was able to record and playback using arecord and aplay so I know the mic and speakers are working.

I installed Mycroft (and Jellyfin) and created the service file in /etc/systemd/system. I started the service and Mycroft was purported to be running. But I say “Hey Mycroft” and nothing happened. So I stopped the service and started it interactively with debug on. Now Mycroft is answering me. :))

I did see an error in the logs about down level Python or something. I followed the URL to the website and it was recommended to do this:

$ sudo apt-get install libatlas-base-dev

That made the error messages go away, but Mycroft will still not answer in background mode.

So a question and a proposal:

  1. Why does Mycroft work only in debug mode?
  2. Should that apt install step be added to the documentation on installing in the Linux doc page? (https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/get-mycroft/linux)

Thanks.

-Mike MacIsaac

P.S. was just about to post when I thought to do a ‘tail -f /var/log/mycroft/voice.log’ When I say ‘Hey Mycroft’ I see this added to the log file:

2021-01-17 08:37:12.328 | INFO     | 22833 | __main__:handle_wakeword:67 | Wakeword Detected: hey mycroft
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
2021-01-17 08:37:12.382 | INFO     | 22833 | __main__:handle_record_begin:37 | Begin Recording...
2021-01-17 08:37:20.459 | INFO     | 22833 | __main__:handle_record_end:45 | End Recording...
2021-01-17 08:37:24.070 | ERROR    | 22833 | mycroft.client.speech.listener:transcribe:239 | list index out of range
2021-01-17 08:37:24.072 | ERROR    | 22833 | mycroft.client.speech.listener:transcribe:240 | Speech Recognition could not understand audio
2

The latest picroft images work on pi4’s now. You can load whatever else you want on top of that, as well.

3

Baconator, thanks for the reply, but as I mentioned I’m running Raspberry Pi OS, not Pycroft.

Why would I get a “Connection failure: Connection refused” in normal mode, but not in debug mode. Anybody know?

Thanks.

-Mike Mac
4

Yes, I accounted for that.

What’s “normal” mode for you? What’s debug? What’s actually running when you start either of those modes? What’s in the logs (voice, messagebus, etc)?

5

Hey Baconator, wow, thanks for the quick reply!

  • I created the file /etc/systemd/system/mycroft.service as is described in the docs.
  • I issued the command ‘systemctl enable mycroft’ so that mycroft is started at boot time.
  • I reboot and issue the command ‘service mycroft status’, and the reply is that it is running.
  • I speak ‘Hey Mycroft’ and … nothing.
  • I then stop the service with ‘service mycroft stop’.
  • I start mycroft interactively with ‘mycroft-start debug’.
  • I speak ‘Hey Mycroft’ and hear a bleep.
  • I speak ‘What’s the weather?’ and get a nice answer.

So, starting mycroft at boot time as a service does not appear to be working, but starting it interactively in debug mode does.

Any help will be appreciated.

-Mike M
6

What’s actually running when you start with the systemd start up? What’s in the logs (voice, messagebus, etc) for that?

How do both of those compare to when you run it in debug?

7

Thanks again B.

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?

-Mike M
8

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.

Thanks.

-Mike
9

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?

10

When started with ‘mycroft-start debug’ I see these mycroft processes:

pi@raspberrypi:~$ ps -ef | grep mycroft | grep -v grep
pi        8498  4742  0 06:54 pts/1    00:00:00 bash /home/pi/mycroft-core/bin/mycroft-start debug
pi        8522  8498 12 06:54 pts/1    00:00:19 python3 -m mycroft.messagebus.service
pi        8525  8498 28 06:54 pts/1    00:00:43 python3 -m mycroft.skills
pi        8528  8498  7 06:54 pts/1    00:00:12 python3 -m mycroft.audio
pi        8531  8498 15 06:54 pts/1    00:00:23 python3 -m mycroft.client.speech
pi        8534  8498  9 06:54 pts/1    00:00:13 python3 -m mycroft.client.enclosure
pi        8536  8498 39 06:54 pts/1    00:01:00 python3 -m mycroft.client.text
pi        8747  8531  0 06:55 pts/1    00:00:00 /home/pi/.mycroft/precise/precise-engine/precise-engine /home/pi/.mycroft/precise/hey-mycroft.pb 2048
pi        8749  8747 54 06:55 pts/1    00:01:17 /home/pi/.mycroft/precise/precise-engine/precise-engine /home/pi/.mycroft/precise/hey-mycroft.pb 2048

When started with systemctl:

# ps -ef | grep mycroft | grep -v grep
pi        9412     1 23 06:58 ?        00:00:14 python3 -m mycroft.messagebus.service
pi        9415     1 39 06:58 ?        00:00:23 python3 -m mycroft.skills
pi        9418     1 17 06:58 ?        00:00:10 python3 -m mycroft.audio
pi        9421     1 14 06:58 ?        00:00:08 python3 -m mycroft.client.speech
pi        9424     1 15 06:58 ?        00:00:09 python3 -m mycroft.client.enclosure
pi        9463  9421  0 06:58 ?        00:00:00 /home/pi/.mycroft/precise/precise-engine/precise-engine /home/pi/.mycroft/precise/hey-mycroft.pb 2048
pi        9465  9463 71 06:58 ?        00:00:36 /home/pi/.mycroft/precise/precise-engine/precise-engine /home/pi/.mycroft/precise/hey-mycroft.pb 2048

So the mycroft.client.text process is missing when started with systemctl. Odd.

What might cause that?

-Mike M
11

That is actually the mycroft-cli-client and should be missing.

Can you post the content of your systemd file?

12

Sure, here it is - copied from the documentation:

pi@raspberrypi:/etc/systemd/system$ cat mycroft.service
[Unit]
Description=Mycroft AI
After=pulseaudio.service

[Service]
User=pi
WorkingDirectory=/home/pi/
ExecStart=/home/pi/mycroft-core/bin/mycroft-start all
ExecStop=/home/pi/mycroft-core/bin/mycroft-stop
Type=forking
Restart=no

[Install]
WantedBy=multi-user.target

-Mike M
13

Could you give it a go with;

“Type=simple”

instead of Forking

Don’t forget to; sudo systemctl daemon-reload.

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?

14

Yes, I will try it later today - thanks for the suggestion.

-Mike M
15

j1nx,

I tried changing to “Type=simple”, and … same results :((

This is not that big of a deal because I can start it manually. Still it would be nice to resolve.

A question is: Are others getting mycroft to start using systemd with the config file from the documentation?

Thanks.

-Mike M
16

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?

17

j1nx,

I added an /etc/systemd/system/pulseaudio script, and that shows it is running after a reboot.

But mycroft still fails :frowning:

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)

Is it trying to run as root and not pi?

sigh …

Thanks for your help.

-Mike M
18

Can you post the content of your;

pulseaudio.service
/etc/pulse/system.pa
/etc/pulse/daemon.conf

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.

19

j1nx,

Thanks for sticking with this one. Here’s the info:

# cat /etc/systemd/system/pulseaudio.service
[Unit]
Description=PulseAudio system server

[Service]
ExecStart=/usr/bin/pulseaudio --daemonize=no --system --realtime --log-target=journal
ExecStop=/usr/bin/pulseaudio --kill
Type=notify

[Install]
WantedBy=multi-user.target

# egrep -v '^#|^$' /etc/pulse/system.pa
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-suspend-on-idle
load-module module-position-event-sounds

# egrep -v '^;|^$|^#' /etc/pulse/daemon.conf
default-fragment-size-msec = 15

# cat /etc/systemd/system/mycroft.service
[Unit]
Description=Mycroft AI
After=pulseaudio.service network-online.target
Wants=network-online.target

[Service]
User=pi
WorkingDirectory=/home/pi/
ExecStart=/home/pi/mycroft-core/bin/mycroft-start all
ExecStop=/home/pi/mycroft-core/bin/mycroft-stop
Type=simple
Restart=no

[Install]
WantedBy=multi-user.target

I moved the SYSV script out of /etc/init.d and went back to systemd. I rebooted and pulseaudio was running but mycroft was not. To debug I did this:

# journalctl | grep mycroft
Jan 28 14:02:21 raspberrypi mycroft-start[784]: fatal: unable to access 'https://github.com/MycroftAI/mycroft-core.git/': Could not resolve host: github.com
...

“Could not resolve host” sure looks like a smoking gun. I could not even do an nslookup. I searched the web and installed dnsutils:

# nslookup github.com
-bash: nslookup: command not found
# apt-get install dnsutils
...
# reboot

I could now nslookup github. I rebooted many times trying different requriments in the mycroft systemd config file.

Still no joy :((

-Mike M
20

The start up scripts check for updates. Removing that and manually updating might be worthwhile.