This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
command killed after 10s of no activity #1087
Comments
|
yeah, i think we've just been too aggressive with these timeouts. i'm going to crank them up now. |
|
What's the point of these timeouts at all? Under what circumstances is it expected that commands hang unexpectedly? Overzealous use of timeouts is a pretty good way to ensure your software has unexpected bugs. |
|
@tamird i've been having the same thought this past week. we originally instituted these timeouts at gophercon, when a ton of people were seeing dep hang for just...ten, fifteen minutes while trying to clone down repositories. in that moment, with it happening to a bunch of people, it seemed important to have something in place to terminate early. with every passing day, that seems increasingly wrongheaded. it's important to note that they're not actually strictly timeouts - rather, they're "inactivity timeouts." we watch stdout/stderr, and if nothing emerges in the configured time period, then we kill the running command. however, most commands - especially when not attached to a tty - don't generate output, which means they end up behaving like plain timeouts. but, yes, i think they're doing more harm than good, and am inclined to remove them. |
|
I am seeing this in repos that have a lot of submodules. |
|
@colek42 what OS? |
|
@sdboyer we are seeing it on RHEL6/7 and WSL (Windows subsystem for linux). It looks like the number of objects in the repo is related to dep timing out. We have a large number of small assets in this repo.
how does Possible solutions:
The main use case for a timeout in dep, for us, would be in CI. There are plenty of ways to handle a timeout outside of dep. My vote would be to remove timeout and improve how we emit progress (if possible) |
|
Across our team we've had issues requiring us to run Inspection of the path provided with Here's an sample failure from jenkins, running RHEL 6: |
yeah, these are the exact set of possibilities we're considering. the third is the hardest, by far, but also probably the best in the long run. the first has a PR up at #1028, but my preference now is the second approach. there's a PR for that at #1110, but there are some issues with the approach there, as detailed in the issue. i'm not sure i can personally get to this this week or next, so help is very much welcome 😄 |
|
and...whew, @andrewmaach, that's quite a hefty bunch of submodules. i'd be curious what the output is from the commands it recommended you run: |
zknill
pushed a commit
to zknill/dep
that referenced
this issue
Oct 6, 2017
None of this is great, but this is the easiest immediate band-aid we have. Closes golang#1087.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of
depare you using (dep version)?153953d
What
depcommand did you run?What did you expect to see?
Dep should write the dependencies to the vendor tree correctly.
What did you see instead?
Dep fails because the command was killed. Maybe the default timeout should be higher as I am seeing this on my local machine and Gitlab CI.
The text was updated successfully, but these errors were encountered: