Getting Mycroft to autostart with systemctl propertly... what is my "working directory"?

Archive - Mycroft Project This category is being retired - Support
1

When I start mycroft with systemctl, either the permissions are wrong, or it can’t access pulse/alsa correctly.

I installed mycroft under my linux (ubuntu) user home directory:
/home/username/mycroft-core

I run it successfully from the mycroft-core directory with: sudo ./start-mycroft.sh all

Then I run the same command with the cli to access the command interface.

However, when I (after stopping mycroft) try to run it with as a daemon via systemctl, I can’t get it to work correctly.

Depending on the various settings I’ve had all sorts of issues, but I think now I’ve narrowed them all down to either something with permissions and/or the working directory.

In my /home/username/ directory I have .mycroft with skills and config and all.

It seems like perhaps this shouldbe the working directory in my .service - but if I run with my username it fails permissions. If I run as root, it doesn’t recognize my home.mycroft.ai pairing.

What gives?

.service config:

[Unit]
Description=Mycroft personal AI
After=pulseaudio.service

[Service]
User=root
WorkingDirectory=/home/username/.mycroft
ExecStart=/home/username/mycroft-core/start-mycroft.sh all
ExecStop=/home/username/mycroft-core/stop-mycroft.sh
Type=forking
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

2

I’m wondering if it has to do with the python virtual environment or something… but it’s a bit beyond me…

Maybe something along these lines?

3

Don’t know if it will be useful, as I’m speaking of the arch linux package which is done with love and works out of the box, but here, the daemon is launched by the user, and it makes sense, as the configuration files are owned by the user and involving root just would add complexity, incongruence, and file permission issues on the short and mid-term.

Systemd user init files are placed on /usr/lib/systemd/user/ if you want any user can manage those daemons, or inside ~/.config/systemd/user for the user who wants to start anything as a service. Then, you should be able to start them with
systemctl --user start|stop|restart|enable name-of-the.service

My /usr/lib/systemd/user/mycroft.service unit file is this:

[Unit]
Description=Mycroft main service
After=network.target local-fs.target remote-fs.target

[Service]
Type=forking
RemainAfterExit=no
ExecStart=/usr/share/mycroft-core/start-mycroft.sh all
ExecStop=/usr/share/mycroft-core/stop-mycroft.sh all

[Install]
WantedBy=multi-user.target

So, you can start and enable at boot the mycroft daemon, just for your user, with

systemctl --user start mycroft.service
systemctl --user enable mycroft.service

More information about systemd user units can be found, as you almost always can, on the arch linux wiki: https://wiki.archlinux.org/index.php/Systemd/User#Writing_user_units

For the sound permissions, I would bet your user is not a member of the mycroft-core group, please, run the command:

$ getent group | grep mycroft

To see see the exact mycroft group name and to see if your username belong to that group

$ getent group | grep mycroft
mycroft-core:x:965:malevolent

If your user is not a member of that group, you can add it with the usermod command

sudo usermod -aG <MYCROFT_GROUP> <USERNAME>

Then close and start the terminal|session and run the following command to make sure your user is member of the mycroft group

$ id
uid=1000(malevolent) gid=1000(malevolent) groups=1000(malevolent),3(sys),90(network),98(power),965(mycroft-core),991(lp),998(wheel)

As you can see, besides sudo (wheel) membership, my username has no other special “sound” membership like “audio” or whatsoever, just mycroft-core.

1 Like
4

I did feel a bit silly after realizing that there was already an ubuntu package…

However, I installed the ubuntu package and ran into a few problems.

  1. either i was impatient, and the downloading of various skills, voices and setup takes a real long time, or doesn’t work. I also read skill installation is buggy.
  2. the cli interface doesn’t seem accessible, all I can get is a debug by running mycroft all cli
  3. I was having problems with accidentally getting multiple instances and starting and stopping it.

Do you have any sights on this? I’d be psyched to use that version if I can get it working :slight_smile: I did manage to pair it with home.mycroft.ai it at least.

5

If you did manage to pair the device, you can see the cli by running start-mycroft.sh cli you need to know where is placed (by taking a look on the StartExec path on the unit file or by querying apt with dpkg -L <MYCROFT_PACKAGE> |grep start-mycroft.sh). For illustrative purposes, let’s say it is on /usr/share/mycroft-core/start-mycroft.sh
So:
/usr/share/mycroft-core/start-mycroft.sh cli
should open the familiar cli.

You should find the logs under /var/log/mycroft (root|sudo access will be needed if the daemon isn’t running as your current user), take a look to them with less <LOGNAME>.log (exiting with the “q” key) or if you want to see them in “real time”, with tail -f <LOGNAME>.log (exiting with Ctrl+C)

PS: You would find us on https://chat.mycroft.ai now you have the daemon up un running, now it seems mycroft starts properly at boot :wink:

6

I tried getting autostart to work in the lniux package too - did you mean the snap based one? - but wasn’t able to.

I think I’ll just resort to manually starting it :slight_smile:

7

As I said, I’m not using ubuntu, so I don’t know what are you installing… I assumed you where installing a normal package through apt, not a snap… at this point, I’m a little lost about the versions you have and how you’ve installed them, actually.

If you’ve managed to make it work manually, I suggest you play a little with it, and then we’ll see how you can configure it to start automatically. It should be as easy as create a unit file with the content I post on my earlier post

8

indeed… Trying way too many things at once.

I did a manual install first
then I installed via the ubuntu package manager, which happens to install the snap version. There was no other install available through the default respositories
Then I installed another using the gnome extension in a different location

ultimately I removed the snap version because it didn’t work right
The other two installs happen to use the same user files, so it’s just two different core directories. I should probably remove one :stuck_out_tongue:

Ironically, I haven’t been able to get either to actaully work with the gnome extension either… Doesn’t seem worth all the trouble right now so I’ll just go with manually starting it for now.

Thank you for your suggestion - perhaps another time this mystery will be resolved :stuck_out_tongue:

9

Well, that makes a bit clear you scenario xD

You should stick with the manual source-code installation, as is well documented and you won’t depend on any packager. All mycroft instances (source code, snap, plasmoid, widget, venv or whatever) uses your configuration on ~/.mycroft/mycroft.conf. and the skills placed on /opt/mycroft/skills, so in principle, there is no problem which one do you use.

You only need to execute the working start-mycroft.sh all at boot or user logon, so you can accomplish it by creating a unit file, creating a logon task under ubuntu’s desktop, a cron job or manually starting as do you do now… but for the moment, just play with it and its skills, and we’ll see later how to automate it :wink:

PS: I’ve readed somewhere GNOME extension is just experimental at the moment, and the QT interface is even worse, is just a proof of concept or pre-alpha for the Mark II interface. What works perfect is the Plasmoid for the Plasma Desktop. As you are using gnome, you need to stick with the CLI, which is also nice.

10

I was thinking it’d be that simple - a cron job or something - but I also thought it should work via the systemctl function…

I’ll look into those other options. I guess maybe ubuntu does have a logon task manager in the GUI eh? Anyhow, I can figure that bit out :slight_smile:

11

Easiest way perhaps is create a logon application through the startup applications
Desperate times call for desperate measures :wink: