search

seeing-things / track

Automates tracking of targets with a telescope using ephemeris (TLE files) and/or optical tracking.
MIT License
8 stars 0 forks source link

Need to CTRL-C twice to end program with mount multiprocessing #199

Open bgottula opened 3 years ago

bgottula commented 3 years ago

Not sure if the problem is in this project or in point, but I frequently need to CTRL-C twice to end the program (but not always). When I need to do it twice I get the following:

(venv) rgottula@nix:~/dev/track$ track --meridian-side=east --fuse solarsystem Mars
NTP check failed: PPS is not the selected NTP system peer
Continue anyway? [Y/n]: 
In named solar system body mode: 'Mars'
Sensor fusion with camera enabled
Could not connect to laser pointer FTDI device.
Gamepad found and registered.
^CGot CTRL-C, shutting down...
Safing mount...Mount safed successfully!
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/popen_fork.py", line 28, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt

After the first CTRL-C, I see the messages "Got CTRL-C, shutting down..." and "Safing mount...Mount safed successfully!" and I'm fairly confident that the mount motion is indeed stopped, though I'm not certain since I usually stop the program when the mount is not moving at a rate that is noticeable. The console messages after that are emitted after the second time I press CTRL-C, which finally ends the program and brings me back to the terminal.

We've encountered numerous versions of this problem over the years, so check the issue history for some insights.

bgottula commented 3 years ago

Today I've been having this problem, but it's worse than usual because nearly every time I have to end the program with a second CTRL-C, the two forked processes continue running and I have to hunt them down and kill them manually. Not sure what is different because I don't think I have typically needed to do this extra step.

jgottula commented 3 years ago

I should be able to help with this.

I have lots of experience in the area of planning and executing the premeditated murder of CPU processes that have overstayed their welcome. 😉

Give me a call whenever, and I'll see what I can come up with.

bgottula commented 3 years ago

With lots of print statements sprinkled around:

^CGot CTRL-C, shutting down...
Safing mount...stop motion called
called slew() with rate 0 on both axes, waiting on events
RA axis event is set
DEC axis event is set
returning from stop_motion()
Mount safed successfully!
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/popen_fork.py", line 28, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
In Gemini2 destructor
In Gemini2 destructor: ra process is alive, sending None to pipe
In Gemini2 destructor: dec process is alive, sending None to pipe
Finished sending None to both axis processes
Joining process for ra axis
rate_target is None for ra, setting div_target to 0 and shutdown to True
rate_target is None for dec, setting div_target to 0 and shutdown to True
shutdown == True for ra
div_last_commanded == 0, returning from ra
shutdown == True for dec
div_last_commanded == 0, returning from dec
Join returned for ra
Joining process for dec axis
Join returned for dec
returning from Gemini2 destructor
bgottula commented 3 years ago

Had a call with @jgottula on 18 Jan 2021 where we discussed this in depth. Some of the main conclusions we came to are:

I think it would be best to pursue feasibility of ditching multiprocessing before investing much more effort into fixing this particular issue. In the event that we are stuck with it, @jgottula suggested a couple things: