I have a few scripts which uses the Jfrog CLI to download files from artifactory. These scripts are on RHEL7. There are few download commands (jfrog rt dl) which download software packages from Artifactory.
Randomly one of these package will fail with following error messages:
04:12:24 [Info] [Thread 2] [1]: 206 Partial Content...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x9d2bfb]
goroutine 86 [running]:
github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).doDownloadFileRange.func2()
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:659 +0x1b
github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).doDownloadFileRange(0x64, {{0xc00003aa80, 0x25}, {0xc000354c40, 0x68}, {0xc000436320, 0x47}, {0x7ffecb4afe1c, 0x25}, {0xc000036168, ...}, ...}, ...)
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:685 +0x619
github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).downloadFileRange.func1()
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:614 +0x16b
github.com/jfrog/jfrog-client-go/utils.(*RetryExecutor).Execute(0xc000521d60)
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/utils/retryexecutor.go:33 +0x57
github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).downloadFileRange(0xc00036e900, {{0xc00003aa80, 0x25}, {0xc000354c40, 0x68}, {0xc000436320, 0x47}, {0x7ffecb4afe1c, 0x25}, {0xc000036168, ...}, ...}, ...)
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:632 +0x48d
github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).downloadChunksConcurrently.func1(0x0, 0x0, 0x1)
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:544 +0x229
created by github.com/jfrog/jfrog-client-go/http/httpclient.(*HttpClient).downloadChunksConcurrently
/root/go/pkg/mod/github.com/jfrog/jfrog-client-go#v1.8.0/http/httpclient/client.go:543 +0x151
The commands i use are like these(from different scripts):
TMPDIR="/app/install/temp" jfrog rt dl artifactory-project/Backup_file.rep.gz $REPO_FILE
jfrog rt dl artifactory-project/second_file.tar.gz /app/software/second_file.tar.gz
I am using Jfrog CLI jf version 2.12.0
Initially when it failed with segmentation error messages i added TMPDIR, but that did not sort out the issue.
I took a look at a similar post Artifactory Crash due to Segmentation Violation
but it does not seem to the exact error as i get.
Anyone faced similar issues? Any ideas to fix this issue?
Also I did not face this issue on CentOS. Is there some incompatibility with RHEL7?
This commit of jfrog-client-go fixes the issue.
jfrog-client-go v1.8.1 was released with this fix.
JFrog CLI 2.12.1 was also released and includes this fix.
It appears that the scenario which exposed this bug is a nil response or a response without a body. If this is caused by some instability in your network, there's a chance that jfrog-client-go's HTTP retry mechanism will mitigate and resolve the issue, now that it no longer crashes beicase of it.
It is worth upgrading JFrog CLI to version 2.12.1 (which is currently the latest) and seeing if the issue is completely resolved, or there are other issues, which may or may not be related to the code of JFrog CLI, which still need to be handled.
Related
I am trying to deploy my application built in ASP.Net 4.6.1. So I am using HWC Buildpack.
Below is my manifest.yml
---
applications:
- name: DRSN
random-route: true
memory: 128M
buildpack:
https://github.com/cloudfoundry/hwc-buildpack.git
env:
DOTNET_CLI_TELEMETRY_OPTOUT: 1
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
The error that I am receiving is below.
Waiting for API to complete processing files...
Staging app and tracing logs...
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 creating container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 successfully created container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Downloading app package...
Downloading build artifacts cache...
Downloaded build artifacts cache (231B)
Downloaded app package (19.5M)
Failed to compile droplet: Failed to compile droplet: fork/exec /tmp/buildpackdownloads/6c6dca8d638ac0d145d6581f9eb9a96a/bin/compile: permission denied
Exit status 223
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 stopping instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 destroying container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Error staging application: App staging failed in the buildpack compile phase
Can anyone help me resolve this issue? Am I not correct in my manifest.yml? Or is it something else?
I believe that the problem is that you're telling the system to use the HWC buildpack, but at the same time you're not setting the Windows stack (at least based on what info I can see). That means it's going to default to the Linux stack, which I believe is why you're seeing the fork/exec /tmp/buildpackdownloads/... error.
Try adding stack: windows to your manifest.yml or -s windows to your cf push command (for future reference, when you need help always include the full cf push command you're running).
PS: you shouldn't use https://github.com/cloudfoundry/hwc-buildpack.git that is telling the system to grab the master branch in whatever state it's currently in. That's a.) not reproducible and b.) not guaranteed to be in a working state. You should either use the platform provided buildpack names (from cf buildpacks) or append #<branch_or_tag> to the end of the URL so it picks a specific branch. All CF Buildpacks have tags for each release. It's strongly recommended you use a tagged release.
I've upgraded two instances of Artifactory to 6.9.0 version. One of them works without issue(OpenJDK 1.8.131 on centos 7.4), but I see error in the artifactory.log on another instance(OpenJDK version "1.8.0_151" on OEL 6.9):
2019-04-11 08:10:49,379 [art-exec-15] [ERROR] (o.a.s.a.ArchiveIndexerImpl:162) - Failed to index 'repository-name:com/service/service/0.14.2.1154/service-0.14.2.1154.jar': Unexpected record signature: 0X622F2123
I've tried to switch artifactory to Oracle JDK 1.8.0_121 and OpenJDK 11.0.2 - it didn't help.
p.s.
REST API and Artifactory GUI return artifacts without any issue.
The issue isn't reproduced on small jars without dependencies.
I am setting up a phabricator server and i am observing the below issue, both from my diffusion repository Status window and the daemons.log file
Error updating working copy: Command failed with error #128!
COMMAND
git log --format='%H%x01%P%x01%ct' --all --
STDOUT
(empty)
STDRR
fatal: bad default revision 'HEAD'
After reading on this issue, i figured out that this is a common issue with bare repositories without first commits. So i tried committing from my local system through repository http URI, but it is returning a 500 exception.
below is the error message i pulled out from phabricator database:
$ select * from phabricator_repository.repository_pullevent;
500 | {"response.message":"Error 1: sudo: a password is required\n"}
Can any one help me out to understand the issues from repository_pullevents and daemons.log file.
thanks in advance!
i resolved the problem with sudo, by changing the user running apache and adding the symlink created for git-http-backened in sudoers for the apache user.
and the problem with repository bad HEAD revision was resolved by making the first commit from a client machine.
When I try to install error messages, it fails to download. I get error messages like this:
[error] Server access Error: java.security.cert.CertificateException: No subject alternative DNS name matching repo.scala-sbt.org found. url=https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-pgp/scala_2.10/sbt_0.13/0.8.3/ivys/ivy.xml
I can confirm, when accessing via my browser, that the certificate installed for the domain repo.scala-sbt.org is actually the certificate for repo.typesafe.com, and this seems to be the source of the error. It doesn't appear to be a DNS issue as http://repo.scala-sbt.org/ (insecure) works.
Please see https://github.com/sbt/sbt/issues/2125 for the workarounds. Specifically "http" should not be used.
resolvers += Resolver.url("fix-sbt-plugin-releases", url("https://dl.bintray.com/sbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)
Edit: This issue is now resolved. No workarounds should be required.
As a temporary workaround, add the file ~/.sbt/0.13/plugins/temp.sbt with the following contents:
resolvers += Resolver.url("fix-sbt-plugin-releases", url("https://dl.bintray.com/sbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)
You'll still see the error, but sbt will be able to find the dependency for which it is searching when accessing https://dl.bintray.com/sbt/sbt-plugin-releases directly (the place to which repo.scala-sbt.org presently redirects).
Upgrading nss package on CentOS worked for me.
sudo yum upgrade nss
I am using the sbt-release plugin.
The process seems to work, however, sbt logs the final release step, pushChanges as error. Ideally, only actual errors are logged to error output as it can confuse the automation.
Sample output here:
Push changes to the remote repository (y/n)? [y] y
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] 67277ef..a1b959f my_branch -> my_branch
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] * [new tag] v0.1.8 -> v0.1.8
my_branch in this case is not the master branch (as I'm testing this process on my own branch before it goes to master), could that be the issue?
I don't know if something's changed in the latest version, but before sbt-release was warning you before this push step, that git sends it's info on stderr and so it will be shown with error messages in sbt although the process goes perfectly fine. So it's ok, don't worry.