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

exec user process caused "no such file or directory" #5

Closed
knopki opened this issue Apr 11, 2017 · 3 comments
Closed

exec user process caused "no such file or directory" #5

knopki opened this issue Apr 11, 2017 · 3 comments

Comments

@knopki
Copy link

knopki commented Apr 11, 2017

Always got crash with message in log

panic: standard_init_linux.go:178: exec user process caused "no such file or directory"

on :latest build from Docker Hub.

Also, got this on fresh local build:

 ~/d/restic-backup-docker  ./run.sh

Removing old container names 'backup-test' if exists
backup-test
Start backup-test container. Backup of ~/test-data/ to repository ~/test-repo/ every minute
panic: standard_init_linux.go:178: exec user process caused "no such file or directory" [recovered]
        panic: standard_init_linux.go:178: exec user process caused "no such file or directory"

goroutine 1 [running, locked to thread]:
panic(0x6f3080, 0xc4201b0150)
        /usr/lib/golang/src/runtime/panic.go:500 +0x1a1
github.com/urfave/cli.HandleAction.func1(0xc420089748)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x247
panic(0x6f3080, 0xc4201b0150)
        /usr/lib/golang/src/runtime/panic.go:458 +0x243
github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization.func1(0xc420089198, 0xc420026088, 0xc420089238)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:259 +0x18f
github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization(0xc420056780, 0xaac9c0, 0xc4201b0150)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:277 +0x353
main.glob..func8(0xc42008c780, 0x0, 0x0)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/main_unix.go:26 +0x66
reflect.Value.call(0x6dde00, 0x769e48, 0x13, 0x73c329, 0x4, 0xc420089708, 0x1, 0x1, 0x4d1818, 0x732160, ...)
        /usr/lib/golang/src/reflect/value.go:434 +0x5c8
reflect.Value.Call(0x6dde00, 0x769e48, 0x13, 0xc420089708, 0x1, 0x1, 0xac2720, 0xc4200896e8, 0x4da7f6)
        /usr/lib/golang/src/reflect/value.go:302 +0xa4
github.com/urfave/cli.HandleAction(0x6dde00, 0x769e48, 0xc42008c780, 0x0, 0x0)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/urfave/cli/app.go:487 +0x1e0
github.com/urfave/cli.Command.Run(0x73c4f5, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x74db36, 0x51, 0x0, ...)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/urfave/cli/command.go:191 +0xc3b
github.com/urfave/cli.(*App).Run(0xc4200ec000, 0xc42000c120, 0x2, 0x2, 0x0, 0x0)
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/Godeps/_workspace/src/github.com/urfave/cli/app.go:240 +0x611
main.main()
        /builddir/build/BUILD/docker-ae7d637fcad9be396e75af430405446f9e6ab099/runc-3819cd61f5263275788f7279fe9d2bc13f086aa6/main.go:137 +0xbd6
@niondir
Copy link
Member

niondir commented Apr 13, 2017

Thanks for reporting. I noticed that, but had no time to fix it yet. But using the :v1.0 is a valid fix.

I will take care about it soon. Or feel free to add a pull request.

The latest version will not be backwards compatible to v1.0 when using "prune" because prune can now be executed by adding --prune to RESTIC_FORGET_ARGS - the default behavior will change from "always prune" to "prune only when --prune is set".

@niondir
Copy link
Member

niondir commented Apr 13, 2017

I created #6 which I like to take care of to get the master more stable and updated the readme to make clear that :latest might not always be the most stable choice.

Especially for backup solutions we should care about backwards compatibility and clear versioning.

@niondir
Copy link
Member

niondir commented Apr 28, 2017

The Container will backup "~/test-data/ to repository ~/test-repo/" which you need to create in advance (at lest the folders)

@niondir niondir closed this as completed Apr 28, 2017
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