Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More than one event hook command appear to not to be run in order #733

Closed
jneilliii opened this issue Jan 20, 2015 · 8 comments

Comments

Projects
None yet
2 participants
@jneilliii
Copy link

commented Jan 20, 2015

I have started using event hooks to turn on/off mjpg_streamer and was curious to know if the command list for an event is run asynchronously or not? It seems that it may be since after adding the command to my printdone event subscription my email me command line has broken. I think this is because the stream has ended before curl can grab the snapshot.

    events:
      enabled: true
      subscriptions:
      - command:
        - curl -o /tmp/printDone.jpg "http://localhost:8080/?action=snapshot" && mpack -s "Print of {file} finished" /tmp/printDone.jpg <email address removed>
        - sudo service livestream.sh stop
        event: PrintDone
        type: system
@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 21, 2015

They are run asynchronously within OctoPrint, but all commands from an event hook are executed in the order they are specified in. So your mail command not working anymore must have some other reason. Anything in the log?

@jneilliii

This comment has been minimized.

Copy link
Author

commented Jan 21, 2015

Running through a test now to see if anything is put in the log. I also modified the mpack command to write it's output to a file by adding "> /tmp/mail.log" to the end of the command.

The work around for me was to append it to the email command using && similar to the way the recipe is showing curl and mpack running on the same command line. This basically makes it synchronous via linux if I'm not mistaken and I did receive the email and mjpg_streamer daemon did stop as expected.

Will update after my test run.

@jneilliii

This comment has been minimized.

Copy link
Author

commented Jan 21, 2015

So the only thing that shows in the log is the following.

2015-01-21 19:32:42,038 - octoprint.events - INFO - Executing system command: sudo service livestream.sh start
2015-01-21 19:56:07,646 - octoprint.events - INFO - Executing system command: curl -o /tmp/printDone.jpg "http://localhost:8080/?action=snapshot" && mpack -s "Print of /home/pi/.octoprint/uploads/Cube.gco finished" /tmp/printDone.jpg jneilliii@gmail.com > /tmp/mail.log
2015-01-21 19:56:07,687 - octoprint.events - INFO - Executing system command: sudo service livestream.sh stop

and nothing seemed to be piped into the mail.log file and the image was not captured, so not really sure why it's breaking.

I obviously have a workaround for now, so no big rush, but something to consider if other people start working with event hooks and also have issues. The below event hook works.

    events:
      enabled: true
      subscriptions:
      - command:
        - curl -o /tmp/printDone.jpg "http://localhost:8080/?action=snapshot" && mpack -s "Print of {file} finished" /tmp/printDone.jpg <email address removed> && sudo service livestream.sh stop
        event: PrintDone
        type: system
@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 22, 2015

That stuff being present in the log indicates that OctoPrint handed it off to the underlying OS in the exact order as specified, and that there also were no errors while doing that. The sub process is created synchronously, so there should be no way that the "livestream stop" command could take over the mail command. I don't understand this.

@foosel foosel changed the title [QUESTION] Are eventhook commands run asynchronously? More than one event hook command appear to not to be run in order Jan 23, 2015

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 23, 2015

Marked this as unreproduced bug

@foosel foosel closed this Jan 23, 2015

@foosel foosel reopened this Jan 23, 2015

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 23, 2015

Wrong button, sorry

foosel added a commit that referenced this issue Feb 23, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented Feb 23, 2017

I couldn't believe it myself, but I finally found out why that was happening and I feel a bit stupid now. Turned out that while I was in fact executing the commands in the correct order, I was not waiting for them to finish before the next was triggered (thanks to misunderstanding how Python's subprocess.Popen works). And that of course allowed one command to overtake the next and by that produce problems like those you encountered, making it seem like commands were executed in the wrong order, when in fact they weren't but also didn't wait for each other.

This is now finally solved on maintenance via the above commit, will soon be merged to devel and will also be part of the 1.3.2 release.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

1.3.2 was just released.

@foosel foosel closed this Mar 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.