Closed marksev1 closed 2 months ago
We already use systemd in the apt-packages. These rely on bdists created from setup.py entry points, instead of trying to run a script to enter a virtualenv, set the PYTHONPATH var, etc. maybe you would have better luck that way.
You should just be able to make three units - one for ./start.sh voice, one for ./start.sh skills, and one for ./start.sh service. I've tried that before, and it worked for me.
My previous comment was incorrect, we don't use systemd units in the apt packages. Regardless this is something more appropriate for the packaging repo (we will make it public soon.)
I actually think shipping it as part of the core is completely relevant
Cool! Opening again.
Here are units: https://gitlab.com/rafamanzo/aur-mycroft-core/tree/master
I tested it, it did start mycroft but it wanted to register it as new device, can someone explain to me why if I point to the folder of the already configured mycroft? Is it possible to circumvent it since i don't want to go again through the setup procedure :).
I can say that the restart is not working properly yet: https://gitlab.com/rafamanzo/aur-mycroft-core/issues/2
I think that the problem here is that once the start.sh script launches a process, the PID is no longer tracked. This would be solved by creating standalone bdists from the mycroft-base-setup.py and running them directly.
This is how we are packaging for Debian https://gist.github.com/aatchison/6356a9773e3bbd0c426eebabf34de1c1#file-gistfile1-txt-L29
Also, while I'm thinking about it... The start.sh script basically just enters the virtualenv and the runs a python script. What if you did similar and bypass the start.sh script? Then you might be able to control the python process directly instead of spawning one from the bash script? https://github.com/MycroftAI/mycroft-core/blob/dev/start.sh#L6
The user malevont 's systemd config seems to work for me. I think the Type=forking
and RemainAfterExit=no
options solve the issue of tracking the spawned proccesses and not creating a failure state when the bash process stops.
For ease of access I am going to post his file contents here.
[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
I am a Manjaro user, built from git clone.
Thanks for this @FruityWelsh We've been using similar setup for our installs on the Mark-2 test devices. (We've been using multiple services and used the simple Type)
Since this is a system integration script it's not really a mycroft-core issue. It would be cool if you could add it to the mycroft-documentation
@j1nx has setup a repo with a couple of examples for systemd files for running mycroft. https://github.com/j1nx/mycroft-systemd
My opinion is that the mycroft-core repo should be implementation agnostic but be able to handle the things a systemd implementation allows such as watchdog and ready notifications.
I started on adding hooks so a simple wrapper can be used to launch a core process. Ex
import sdnotify
from mycroft.client.speech.__main__ import main
n = sdnotify.SystemdNotifier()
def my_ready():
n.notify('READY=1')
print('SPEECH IS READY')
def pet_watchdog():
print('Who\'s a good doggie')
main(ready_hook=my_ready, watchdog=pet_watchdog)
Closing Issue since we're archiving the repo
Guys, please make support systemd or make it easier for me to write the unit. Since for now it doesn't work the easy way (like just invoking ./mycroft.sh start - I think its because of the use of screen but I might be wrong) :).
Any feedback is greatly appreaciated.