Mirror.sh script fails but container has exitcode 0

Open Beginner friendly
#412 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker, java, shell

Research direction

Start by locating and reading mirror.sh, then run it in the container with a Java failure such as the reported OutOfMemoryError. Check how command failures are handled and verify that mirror problems produce a nonzero container exit status, while successful mirrors still exit with status 0.

Written by the indexing model from the issue text.

Description

I also have the vulnz error now on my local NVD mirror:

Jun 24 15:05:56 v220240133360251736 vulnz[265688]: Caused by: java.lang.OutOfMemoryError: Java heap space

Since the NVD update on 17.06:
https://www.nist.gov/itl/nvd#news-updates

I understand that you have nothing to do with it, but it took me one week to notice the error because the mirror.sh script running inside the Podman container did not report the error back to the container, and it exited with status code 0 (success).

CONTAINER ID  IMAGE                                                     COMMAND     CREATED         STATUS                     PORTS       NAMES
d44d2b0dd744  ghcr.io/jeremylong/open-vulnerability-data-mirror:latest  /mirror.sh  37 minutes ago  Exited (0) 36 minutes ago              vulnz

Would it be possible to report all mirror.sh problems, including Java errors, back to the container so that I can react to the container exit code?

Or do you have another suggestion for how to handle errors from mirror.sh running inside the container?

Dominant language
Java
Stars
176
Forks
53
Avg merge
4d 3h
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from jeremylong/open-vulnerability-cli

All issues in jeremylong/open-vulnerability-cli

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.