Status: Closed (View Workflow)
We are seeing hung git processes which seem to be left over from when Jenkins is using Git to poll for changes. This is likely because there was some IO problem (disk or network) when the polling was attempted. Instead of hanging forever, the fetch should eventually timeout.
- is related to
JENKINS-20445 Git plugin timeout is too small
JENKINS-22547 Git timeout setting does not work for checkout
True enough Mark Waite. However, see JENKINS-47616, wherein I request making this parameterizable, since with Git-LFS the initial checkout is much slower than subsequent ones.
Parameterization is key, since otherwise you must keep messing around with configurations otherwise.
in which file I can find this option? `org.jenkinsci.plugins.gitclient.Git.timeOut`
I searched in all administrative areas and not find it.
-> YES on each project I can add this as additional configuration.
But I want this global on all projects without that people must set it up every time.
(On Windows, I checked config.xml, settings.xml, plugins-settings.xml and everything)
patrick_i if your users need to increase the timeout generally, then I think you may have missed an opportunity to help your users with faster clones. Refer to the Jenkins World 2017 15 minute talk on "git in the large" (slides).
For example, cloning a large git repository can be significantly reduced with a reference repository. Cloning a large git repository can be significantly reduced by using a narrow refspec. Cloning a large git repository can be significantly reduced with shallow clone.
Even with the best of techniques, there still may be times when you choose to attempt to adjust the global git client plugin timeout value. That requires a change of the command line parameters used to start Jenkins. There is no user interface support for global adjustment of the git client plugin timeout value.
In general, the Java process which starts Jenkins needs the argument -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=12345
Refer to my docker_run.py script as one example of a way to pass that argument to the java command which starts Jenkins. If your Jenkins starts from an init script on Ubuntu or Debian, you may be able to adjust command line arguments from /etc/defaults/jenkins. If your Jenkins starts from an init script on Red Hat, CentOS, OpenSUSE, or SUSE, you may be able to adjust command line arguments in /etc/sysconfig/jenkins. If your Jenkins is a service on Windows, I believe there is a configuration file that can be changed to add arguments to the Java command line which starts Jenkins.
@markewaite: Thank you very much.
I understand that it is more professional if we fix the problem in general instead using larger timeouts.
So I will check your slides in the next weeks but for the moment I added this command.
For everybody Windows users else:
C:\Program Files (x86)\Jenkins\jenkins.xml
There you scroll down to service and arguments. There you can add this:
And then your log file shows # timeout=60 and everything is fine
sc1478 there is no value which means "don't time out".
I don't see much difference for your use case between a very large number and no timeout. If you set the timeout to 1000000 minutes, it seems unlikely that you'll reach the timeout before either interrupting the job, restarting Jenkins, or rebooting the computer.