Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wkdev-create ignores and hides any "podman start" errors #35

Open
vivienne-w opened this issue Aug 8, 2024 · 1 comment
Open

wkdev-create ignores and hides any "podman start" errors #35

vivienne-w opened this issue Aug 8, 2024 · 1 comment

Comments

@vivienne-w
Copy link

On my system, new containers created with wkdev-create fail to start, neither using wkdev-enter, nor podman start. Looking into the scripts, I noticed that in my case throws the following error, that is not indicated even with --verbose:

Error: unable to start container "90aed7b862359f4c7dbaa708ea9ee77e2db312f09ebf59a0c2cd4db1f9a474c1": configuring timezone for container 90aed7b862359f4c7dbaa708ea9ee77e2db312f09ebf59a0c2cd4db1f9a474c1: setting timezone for container 90aed7b862359f4c7dbaa708ea9ee77e2db312f09ebf59a0c2cd4db1f9a474c1: stat /etc/zoneinfo/local: no such file or directory

This kind of error should be visible to the user in some way.


In my case, I found the root cause in podman already, and workaround it by hardcoding my timezone here:

try_process_timezone() {
local podman_argument=("--tz" "local")
try_process ${1} "Share host timezone settings with container" 1 ${podman_argument[@]}
}

@nikolaszimmermann
Copy link
Member

Checked the code again:

    echo ""
    echo "-> Creating container '${container_name}'..."
    if argsparse_is_option_set "verbose"; then
        echo ""
        echo "     $ podman ${podman_arguments[@]} create ${podman_create_arguments[@]}"
    fi

    container_id=$(run_podman ${podman_arguments[@]} create ${podman_create_arguments[@]})
    [ -z "${container_id}" ] && _abort_ "Container creation failed - please check the logs and report any issue"

Am I right, that in case of an error 'container_id' actually contains the error message?
We only test if container_id is unset, maybe we can examine/check if it's a container sha ID, or not?
If not, we could just dump the content of the variable and exit.

Or is there a more elegant way?

@TingPing wdyt?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants