Some Java builds are stalling's Avatar

02 Feb, 2020 01:52 AM

We have an open source repo for a Java SDK which integrates with my company's REST APIs.

I'm the main author of the SDK, even though my Java skills are very weak. That may be problem, but the 3 AppVeyor builds have been working for a few years now.

The 3 YAML files in the root control 3 different builds. 2 of the 3 have stopped working recently, and I can't understand why.

Both builds stall after executing the install step, but before executing the build_script step

The builds eventually time out after an hour, with no obvious error message. I'm not sure what has changed or what the problem might be.

The failures started on Jan 18 2020.

  1. Support Staff 1 Posted by Feodor Fitsner on 02 Feb, 2020 04:33 AM

    Feodor Fitsner's Avatar

    Hi Doug,

    Looks like it hangs on gpg utility. There was an image update on January 18 which bumped Git version and by default gpg is getting from Git installation.

    Could you please trying gpg from MSYS districution by prepending PATH with C:\msys64\usr\bin:

    - set PATH=C:\msys64\usr\bin;%PATH%

    Let me know if that worked.

  2. 2 Posted by on 02 Feb, 2020 11:26 PM's Avatar

    Hmm, I added the path modification init: statement as you suggested, to all 3 YAML configurations. I also added logging of gpg --version.

    That didn't seem to help.

    set PATH=C:\msys64\usr\bin;%PATH%
    git clone -q --branch=master C:\projects\aquarius-sdk-java-p7vvi
    git checkout -qf a87c38cd068d0193ca4afd8ca9d13567d710277b
    Running Install scripts
    java -version
    java version "1.8.0_221"
    Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
    Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)
    mvn --version
    Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
    n home: C:\Program Files (x86)\Apache\Maven\bin\..
    rporation, runtime: C:\Program Files\Java\jdk1.8.0\jre
    Default locale: en_US, platform encoding: Cp1252
    OS name: "windows server 2019", version: "10.0", arch: "amd64", family: "windows"
    gpg --version
    gpg (GnuPG) 2.2.19-unknown
    libgcrypt 1.8.5
    Copyright (C) 2019 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Home: /home/appveyor/.gnupg
    Supported algorithms:
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2

    The builds are still stalling after the gpg command

    C:\secure-file\tools\secure-file -decrypt %PUB_KEY_FILE_ENC% -secret %secret% -out %PUB_KEY_FILE_GPG%
    C:\secure-file\tools\secure-file -decrypt %SEC_KEY_FILE_ENC% -secret %secret% -out %SEC_KEY_FILE_GPG%
    gpg --import %PUB_KEY_FILE_GPG%
    gpg: keybox '/home/appveyor/.gnupg/pubring.kbx' created
    gpg: /home/appveyor/.gnupg/trustdb.gpg: trustdb created
    gpg: key C2F577714ADE5425: public key "Open Source Aquatics (OpenSource-AI) <[email blocked]>" imported
    gpg: Total number processed: 1
    gpg:               imported: 1
    gpg --import %SEC_KEY_FILE_GPG%
    gpg: key C2F577714ADE5425: "Open Source Aquatics (OpenSource-AI) <[email blocked]>" not changed
  3. Support Staff 3 Posted by Feodor Fitsner on 03 Feb, 2020 01:36 AM

    Feodor Fitsner's Avatar

    Could you add where gpg before calls to gpg just to make sure it's running from an alternative location? Also, you can login to VM via RDP to see what's going on on/after those commands: I bet there is some child process (gpg-agent maybe?) preventing gpg from exiting.

  4. Feodor Fitsner closed this discussion on 04 Apr, 2020 09:02 PM.

  5. re-opened this discussion on 22 Jul, 2020 04:43 PM

  6. 4 Posted by on 22 Jul, 2020 04:43 PM's Avatar

    I just wanted to follow up on this closed discussion (it can be closed again).

    I had not gotten around to following your last suggestion of RDP-ing into the worker, but when I finally did, the RDP session made the problem obvious.

    The new version of GPG was prompting for a passphrase when importing a secret key. Apparently this was added in GPG 2.1 (the current version in the appveyor builds is GPG 2.2.20). There appear to be some command line options I can use to work around this, so I will try those. Apparently gpg --batch --import pathToKey instead of gpg --import pathToKey will do the trick, but I need to verify that.

    But in the worst case for now, I can RDP into the worker and manually enter the passphrase, since this deployment build needs to run only once every 3 months.

  7. Support Staff 5 Posted by Feodor Fitsner on 22 Jul, 2020 11:37 PM

    Feodor Fitsner's Avatar

    Thanks for sharing your findings!

  8. 6 Posted by on 23 Jul, 2020 12:04 AM's Avatar

    I did confirm that adding the --batch to the gpg --batch --import pathToKey blocked the first stall.

    There is however, and identical stall, again prompting for the passphrase, but I'm sure there is some XML voodoo that can make that prompt go away too.

  9. closed this discussion on 03 Sep, 2021 06:33 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac