Stack trace when aborting fetching of artifact list
When launching a command which has no justification whatsoever for downloading the remote artifact list, it is highly likely for the user to hit ^C
a few times while BuildStream is taking an eternity to do a useless thing.
In this case, a really ugly thing happens.
The first ^C
prints "Aborted!", but buildstream does not return control to the calling shell:
$ bst track base/base-system.bst
Loading: 001
Resolving: 001/001
Fetching artifact list from https://gnome7.codethink.co.uk/artifacts
^C
Aborted!
The second ^C
does this ugly stack trace:
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 29, in poll
pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
At this point, you might think you are rid of this... but a child process has been orphaned, it's still trying to talk to the artifact server, how stubborn !
$ ps axf
[...]
7262 pts/2 Sl 0:00 /usr/bin/python3 /home/tristan/.local/bin/bst track base/base-system.bst
You wont notice the above if you're not looking for it... but it will come and surprise you seconds later, possibly while you are doing something else in your shell:
$ Process Process-1:
Traceback (most recent call last):
File "/usr/lib/python3.5/multiprocessing/process.py", line 249, in _bootstrap
self.run()
File "/usr/lib/python3.5/multiprocessing/process.py", line 93, in run
self._target(*self._args, **self._kwargs)
File "/codethink/GNOME/buildstream/buildstream/_artifactcache/ostreecache.py", line 286, in child_action
q.put((True, _ostree.list_remote_refs(self.repo, remote=remote)))
File "/codethink/GNOME/buildstream/buildstream/_ostree.py", line 354, in list_remote_refs
_, refs = repo.remote_list_refs(remote)
KeyboardInterrupt
Edited by Tristan Van Berkom