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

When port occupied, fail gracefully #3048

Closed
benjaoming opened this issue Jan 9, 2018 · 2 comments
Closed

When port occupied, fail gracefully #3048

benjaoming opened this issue Jan 9, 2018 · 2 comments
Labels
changelog Important user-facing changes P2 - normal Priority: Nice to have TAG: ux update Improved user-facing feature
Milestone

Comments

@benjaoming
Copy link
Contributor

Observed behavior

  1. Kolibri runs migrations etc., it does not halt in time, despite another instance is active
  2. Kolibri stops when the port is occupied, but it does so in an unnecessarily verbose way :)

Expected behavior

$kolibri start
ERROR:Port 8080 is occupied

Please check that you do not have other instances of kolibri running and try again.

User-facing consequences

  1. Possible to have database errors and inconsistencies - instance A is active, instance B migrates. These may be both kolibri instances but different applications (versions)!

  2. Confusion of long error, just looks like things are broken, when in fact user should feel fine that an instance is already running!

Errors and logs

ERROR:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Error in 'start' listener <bound method Server.start of <cherrypy._cpserver.Server object at 0x7ffba52dffd0>>
Traceback (most recent call last):
  File "/kolibri/dist/cherrypy/process/wspbus.py", line 203, in publish
    output.append(listener(*args, **kwargs))
  File "/kolibri/dist/cherrypy/_cpserver.py", line 168, in start
    ServerAdapter.start(self)
  File "/kolibri/dist/cherrypy/process/servers.py", line 170, in start
    wait_for_free_port(*self.bind_addr)
  File "/kolibri/dist/cherrypy/process/servers.py", line 438, in wait_for_free_port
    raise IOError("Port %r not free on %r" % (port, host))
IOError: Port 8080 not free on '0.0.0.0'

ERROR:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Shutting down due to error in start listener:
Traceback (most recent call last):
  File "/kolibri/dist/cherrypy/process/wspbus.py", line 241, in start
    self.publish('start')
  File "/kolibri/dist/cherrypy/process/wspbus.py", line 221, in publish
    raise exc
ChannelFailures: IOError("Port 8080 not free on '0.0.0.0'",)

INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Bus STOPPING
INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE HTTP Server cherrypy._cpwsgi_server.CPWSGIServer(('0.0.0.0', 8080)) already shut down
INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Stopped thread '_TimeoutMonitor'.
INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Bus STOPPED
INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Bus EXITING
INFO:cherrypy.error:[09/Jan/2018:09:15:12] ENGINE Bus EXITED

Steps to reproduce

  1. Start kolibri
  2. Stop kolibri

This happens regardless of running kolibri on the same or different user accounts.

Context

This will be normal on a setup where kolibri runs as a system service and the user tries to run kolibri with their own system credentials.

@benjaoming benjaoming added TODO: needs gherkin update Add to our manual integration tests P0 - critical Priority: Release blocker or regression labels Jan 9, 2018
@benjaoming benjaoming added this to the 0.8.0 milestone Jan 9, 2018
@indirectlylit indirectlylit added P2 - normal Priority: Nice to have and removed P0 - critical Priority: Release blocker or regression labels Jan 12, 2018
@indirectlylit
Copy link
Contributor

reducing priority a bit until we observe that this is causing rampant problems for our users

@benjaoming
Copy link
Contributor Author

benjaoming commented Jan 12, 2018

@indirectlylit it's not only a user problem, Kolibri will proceed with initialization, e.g. database migrations, despite another process being active (as evident from the occupied port). I don't know the consequences of this. Worst-case is that you get database migrations run for 0.8 while a 0.7 is running and corrupting the db (or I hope that SQLite will fail before that).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog Important user-facing changes P2 - normal Priority: Nice to have TAG: ux update Improved user-facing feature
Projects
None yet
Development

No branches or pull requests

3 participants