Skip to content
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.

Snap framework panics when using auto_discover_path feature and REST API is down. #1582

Closed
ghost opened this issue Apr 3, 2017 · 1 comment

Comments

@ghost
Copy link

ghost commented Apr 3, 2017

Environment:

  • OS: Ubuntu 16.04
  • Kernel: 4.4.0-71-generic

Problem:
The situation occurs and is reproducible when using auto_discover_path feature and starting snapteld with incorrect REST API configuration (i.e. on port 8181 when it is taken by another application).

Snapteld reports panic:

user@hostname:/var/log/snap# /usr/bin/snapteld -l 1 -t 0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x57e67c]

goroutine 1 [running]:
panic(0xad9b80, 0xc420010090)
	/home/travis/.gimme/versions/go1.7.3.linux.amd64/src/runtime/panic.go:500 +0x1a1
github.com/intelsdi-x/snap/mgmt/rest.(*Server).run(0xc42014c2c0, 0xc4203fb090, 0x5)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/mgmt/rest/server.go:266 +0x52c
github.com/intelsdi-x/snap/mgmt/rest.(*Server).Start(0xc42014c2c0, 0xc4203072e0, 0x1)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/mgmt/rest/server.go:213 +0x9f
main.startModule(0xf1ca20, 0xc42014c2c0, 0x1, 0x1)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/snapteld.go:978 +0x49
main.action(0xc42024dcc0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/snapteld.go:380 +0xd8d
github.com/intelsdi-x/snap/vendor/github.com/urfave/cli.HandleAction(0xab2200, 0xc1aca0, 0xc42024dcc0, 0xc420189d40, 0x0)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/vendor/github.com/urfave/cli/app.go:485 +0xd4
github.com/intelsdi-x/snap/vendor/github.com/urfave/cli.(*App).Run(0xc42008b6c0, 0xc42000a0a0, 0x5, 0x5, 0x0, 0x0)
	/home/travis/gopath/src/github.com/intelsdi-x/snap/vendor/github.com/urfave/cli/app.go:259 +0x74f
main.main()
	/home/travis/gopath/src/github.com/intelsdi-x/snap/snapteld.go:220 +0x705

instead of the explaining the actual reason:

FATA[2017-04-03T12:09:59Z] listen tcp :8181: listen: address already in use 

The lack of message makes it impossible for the user to guess what was the actual cause of the panic.
The message about the already taken port reveals itself only after disabling autoload feature.

@ghost ghost added the type/bug label Apr 3, 2017
@snapbot snapbot added the tracked label Apr 3, 2017
@IzabellaRaulin
Copy link
Contributor

In order to complement the previous comment

Steps to reproduce

  1. Run some application which blocks port 8181 which is used by Snap RESTAPI by default. Of course, you can run snapteld - remember about setting different RPC control port to avoid conflict in two running instance(*):
    snapteld -l 1 -t 0 --control-listen-port 8084

  2. In another terminal run snapteld without autodiscovery
    snapteld -l 1 -t 0
    You should receive the following error:

    FATA[2017-04-18T19:02:17+02:00] listen tcp :8181: bind: address already in use
    

    so IT WORKS CORRECTLY (as expected)

  3. Let's try to do the same with autodiscovery option:
    snapteld -l 1 -t 0 -a /my/path
    This causes a panic:

    INFO[2017-04-18T19:05:06+02:00] Starting REST API on :8181  _module=_mgmt-rest
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x57ea6c]
    

    As I user I expect to get an error with appropriate message that port 8181 is already in use, not panic.


[*] FYI: in case when provided RPC port is already in use, handling an error is made properly

rashmigottipati added a commit to rashmigottipati/snap that referenced this issue Apr 18, 2017
IzabellaRaulin added a commit that referenced this issue Apr 19, 2017
Fixes #1582: Snap framework panics when using autoload feature and REST API is down
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants