Autostart of plugins?

resam

I've written two plugins for my printer and installed them successfully.
But every time I power off my printer and SBC, the plugins need to be manually started via DWC -> Settings -> Machine-specific plugins.

Is there a way to make them autostart? from the DSF wiki it sounded like it should... but it doesn't.

Here is one of my plugin.json files:

{
    "id": "FilamentLoadCell",
    "name": "Filament-Load-Cell",
    "author": "Thomas Kriechbaumer",
    "version": "1.0.0",
    "license": "MIT",
    "homepage": "https://github.com/Kriechi",
    "sbcRequired": true,
    "sbcDsfVersion": "3.3",
    "sbcExecutable": "filament_load_cell.py",
    "sbcExecutableArguments": null,
    "sbcOutputRedirected":  true,
    "sbcPermissions": ["registerHttpEndpoints"]
}

chrishamm

@resam DSF saves the plugin execution state only when DCS shuts down and/or installs updates. So by pressing E-STOP you should be able to save the execution state for the next reboot. I'll improve that in the next version.

resam

@chrishamm I enabled my plugins, waited for their startup message notification, then pressed "Emergency Stop" in DWC, and they plugins were auto-started.

However, after a proper SBC shutdown + power cycle, they again did not start automatically.

Where should the execution state be saved to on the SBC?

chrishamm

@resam The plugins that are supposed to be auto-started are stored in /opt/dsf/conf/plugins.txt. It's a simple text file where each line is a plugin ID.

resam

@chrishamm said in Autostart of plugins?:

/opt/dsf/conf/plugins.txt

yep - after pressing E-Stop the file gets correctly written with my plugin IDs.
I verified that the files looks good - and rebooted the SBC.
... and the file is empty after I logged into the SBC again.

I manually stopped all DSF systemd services one by one, and the plugins.txt file was still good. I rebooted - and it worked! And then did a simple full reboot (without manually stopping the services one by one), and it didn't work again.

Feels like DCS is truncating/resetting the file during shut down of one of the processes - some kind of race condition between duetcontrolserver and duetpluginservice?

I also realized that I had duetpluginservice and duetpluginservice-root enabled and running at the same time... probably not recommended? However, if I disable the -root.service, then E-Stop does not persist my plugins.txt any more...

chrishamm

@resam I may have found something in DSF which I'll address in the next version. I believe the plugin services could receive a shutdown request before DCS which would cause the plugin states to be reset before that file is correctly written.

Both services are required for plugins; the regular duetpluginservice executes normal (non-root) plugins and and the duetpluginservice-root executes elevated plugins (like DuetPi Management Plugin) and it maintains AppArmor profiles for each plugin. So they're both needed.

resam

@chrishamm thanks! I'll keep both services enabled then.

For now I simply hacked in a cronjob to curl the endpoint to start my plugins. If anyone else needs this hotfix, it goes something like this:

$ crontab -e
<an editor opens: at the bottom insert this line for each of your plugin>
/usr/bin/bash "sleep 30 && curl 'http://localhost/machine/startPlugin' --data-raw 'MyPluginID'"

Save, and exit, and reboot -- and you plugins should start after 30 seconds or so.

chrishamm

@resam Interestingly enough my plugins seem to restart properly if I reboot the Pi with M999 B-1 (requires DuetPiManagementPlugin). But anyway, I'll improve the underlying code in the next version.

resam

@chrishamm At this point I probably should admit that I am not using the DuetPi image - but installed everything from the Duet apt repos into my existing Pi... but the systemd service files are the same - so their Before/After dependencies should be correct as you wrote them.