[DSF Extension] Exec On MCode (was: Shutdown SBC)

Greg_the_maker

@wilriker Ahh ok. was just a thought. would be a nice feature to have though

wilriker

@Greg_the_maker I have to correct myself. In case of an error it will indeed return the output of stdout and stderr combined as an error message. But since we are in short-lived world things can be changed quickly and thus:

Release v5.1.2

This release adds a new flag -returnOutput to be able to send the collected output of a successful run back to DCS. Prior this was only the case if the execution of the command failed.
Note that this cannot be combined with -execAsync.

Download

As usual get it from GitHub Releases page.

Greg_the_maker

@wilriker Fantastic! Works exactly as desired. Have my upvote!

oozeBot

@wilriker Could you please provide a simple example of using the -returnOutput flag? Thanks

wilriker

@oozeBot said in [DSF Extension] Exec On MCode (was: Shutdown SBC):

@wilriker Could you please provide a simple example of using the -returnOutput flag? Thanks

Simple example:

execonmode -mCode 7777 -command "whoami" -returnOutput

will not just confirm successful completion of the command but as part of this return the output of whoami (that returns the user execonmcode is started as, so probably root) so you can see it e.g. in DWC.

oozeBot

@wilriker Thanks. So the return is echo'ed in DWC, correct? Could the return value be evaluated within conditional gCode?

garethky

@oozeBot said in [DSF Extension] Exec On MCode (was: Shutdown SBC):

@wilriker Thanks. So the return is echo'ed in DWC, correct? Could the return value be evaluated within conditional gCode?

I was thinking about this today. Currently there are no variables so there is nothing to write the result back to. (there is a result int from the last code but it can't contain other data types) I think we might have to wait for variables and then we could write the value back to a global.

When that happens... it should be possible to set up an MCode that stores and retrieves values from a file on the SD card. So we could do what M500 does but with key/value semantics of M409:

M7500 K"some.key" V"The value"
M7500 K"some.other.key" V0.05

and then get them back in a global with:

M7500 K"some.key"
echo {global.M7500_value}    ; or whatever you want to name it!

and stored on disk as JSON:

"some": {
    "key": "The Value"
    "other": {
        "key": 0.05
    }
}

EMRosa

Great work! This is incredibly useful and appreciated!

Is there a way to pass quotes through the -command argument?
For example:

execonmcode --command "sudo pkill -fx "blah, blah, blah"" -mCode 7720 -execAsync

I've tried single quotes, escape characters, and changing it to an argument passed through the m-code command;

execonmcode --command "sudo pkill -fx %F" -mCode 7720 -execAsync

and then tried from DWC:

M7720 F"python3 script.py"

but the full argument gets lost. I foolishly tried double quotes and DSF crashed. haha.

Please, forgive my inexperience. There is probably a simple answer to this, but it seems to escape my googling ability.

wilriker

@EMRosa Quick answer is: this is currently not implemented.
I'll think about adding it, though.

ukwebb

followed your video and got it installed and working in 5 minutes - superb work - thanks

EMRosa

@wilriker thanks for the quick reply! No worries; at least it wasn’t something related to my Linux-literacy (or lack thereof). Haha. Your work and efforts on this implementation are inspirational.

wilriker

@EMRosa said in [DSF Extension] Exec On MCode (was: Shutdown SBC):

I've tried single quotes, escape characters, and changing it to an argument passed through the m-code command;
execonmcode --command "sudo pkill -fx %F" -mCode 7720 -execAsync

I thought about this some more and actually the above should work. Though probably as you use -fx on pkill this has to match the full commandline, i.e. you also have to specify the path to python3, so you will probably need use the following command:

M7720 F"/usr/bin/python3 script.py"

EDIT: to find the full commandline while your script.py is running use

$ pgrep -fa "python3 script.py"

This should give you the PID as well as the full command-line of your process.

EMRosa

Thanks so much for the assist! I’ll try that, but I was using the exact process as listed from

ps -aux | grep python3

This lists the process as “python3 location/to/script/script.py”.

In my case, I was able to put the command line call in another python script and just call it that way. I just wasn’t sure if it would be helpful (or necessary) for execonmcode to be able to send quoted arguments. (Or more likely, if I was doing it wrong. Haha)

I’ll let you know if adding the path to python helps.

wilriker

@EMRosa Since you are using pkill you need to use pgrep to find the required command line (it's the same binary that acts different based on which name it is called with but shares common features otherwise). ps is a different tool that uses (and prints) a different format usually dropping the path to the executable. I think there is a flag to ps to add it but I don't know that off-hand.

Also quotes are not necessary for execonmcode. Quotes are a concept of shells (sh, bash, zsh, fish, etc.) to provide means to human users to provide command arguments containing spaces. If an application runs another application they usually can provide arguments containing spaces without the need for quotes.

wilriker

Release 5.2.0

I am pleased to announce release of execonmcode 5.2.0.

This release uses the latest version of godsfapi and makes use of the filters option in InterceptConnection, i.e. it will only receive those codes the user is interested in. This will significantly lower the the required resources e.g. while running a job.

As usual the binaries can be found at GitHub Releases page.

oozeBot

@wilriker at what point in the bootup cycle is execonmcode ready? I created a custom mCode that I'd like to call at the beginning of config.g, but it says it's unsupported. If I call it separately, or at the very end of config.g, it works correctly.

Any thoughts?

wilriker

@oozebot I think that primarily this depends on when execonmcode is started relative to startup of DCS. Or maybe DCS will even delay accepting API clients until a certain amount of startup tasks have been processed. @chrishamm should be able to give more insights on that.

chrishamm

@wilriker If ExecOnMCode is installed as a DSF plugin (will be officially supported in 3.3), it's started by DuetPluginService which is started by multi-user.target. Note that v3.3 will introduce /sys/dsf-config.g as well which is executed as soon as all the enabled plugins have been started.

Previously plugins were started by DCS, so by basic.target AFAIR.

@oozeBot Either move your custom codes to dsf-config.g if you're on pre-3.3 and/or add a delay to the end of your config file to make sure ExecOnMCode has been fully started before they're executed.

oozeBot

@chrishamm @wilriker - thank you both. We are just about to begin testing the 3.3 betas. This may need to be postponed until after it is released.

wilriker

@chrishamm As of right now ExecOnMCode is a simple API client just connecting to the socket. It is not yet converted to an official plugin. It will be started by a user-provided systemd unit (or arbitrary other means) completely independent of DCS.