Webapp Setup problem?

[jplee3]

Hey guys,

So I was dumb and initiated the Webapp setup without having my AD2USB plugged in at all and it seemed okay until I got to the last test page. It obviously didn't detect anything but after that I am completely unable to access the webapp normally. All I get when I try to browse is "Services might still be starting - please wait and try again. If this continues, please let us know on GitHub. You can also email us at Support." and a "502 Bad Gateway" status.

Is there any way to reset the webapp and get it back to the state it was originally in pre-setup?

[Scott]

Easiest way is going to be just to blow away database and start over.

This should do the trick:

• rm /opt/alarmdecoder-webapp/db.sqlite
• cd /opt/alarmdecoder-webapp/ && python manage.py initdb (You'll get an error here, but its nothing to worry about)
• sudo service gunicorn restart

Could you take a look at /var/log/gunicorn/alarmdecoder.log and see if you can find the errors that it was throwing? Also, could you give me a basic rundown on what options you chose when you set up the first time? I'd like to see if I can replicate this.

Thanks,
Scott

[jplee3]

Easiest way is going to be just to blow away database and start over.

This should do the trick:

• rm /opt/alarmdecoder-webapp/db.sqlite
• cd /opt/alarmdecoder-webapp/ && python manage.py initdb (You'll get an error here, but its nothing to worry about)
• sudo service gunicorn restart

Could you take a look at /var/log/gunicorn/alarmdecoder.log and see if you can find the errors that it was throwing? Also, could you give me a basic rundown on what options you chose when you set up the first time? I'd like to see if I can replicate this.

Thanks,
Scott

Thanks! I'll try it out when I get home. And will also try to get the details from the log file. On a related note, I tried doing an apt-get upgrade and it said a bunch of stuff failed because the "--configure" flag didn't work or something. I'll have to get the exact logs when I get home.

As far as the rundown of options, I don't quite recall. I remember setting the device path to ttyUSB0 but not much after. Maybe I'll remember when I get the webapp back to the original state and run through the setup with the AD2USB plugged in this time.

I'll keep you posted.

[jplee3]

nm please see the next post

[jplee3]

So I found the db.sqlite, I think. It was in the instances sub-folder so /opt/alarmdecoder-webapp/instances/db.sqlite

I moved that to /tmp and then ran python manage.py initdb but that resulted in various errors.

I restarted gunicorn again and still no difference with the website.

I wonder if running apt-get update/upgrade and upgrading a certain package may have messed. I noticed after doing an upgrade, my openssl version got upgraded and openssh didn't like it and refused to let me login again. I had to uninstall openssh and openssl and reinstall before things were working again. Something similar happened with Python as well.

I don't know but my OS is in a pretty strange state it seems... well, at least the Alarmdecoder Webapp is getting affected. This is the last snippet from running manage.py:

Code: Select all

root@alarmdecoder:/opt/alarmdecoder-webapp# python manage.py initdb

--------------------------------------------------------------------------------
ERROR in app [/opt/alarmdecoder-webapp/ad2web/app.py:89]:
Error
--------------------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/alarmdecoder-webapp/ad2web/app.py", line 86, in create_app
    decoder.init()
  File "/opt/alarmdecoder-webapp/ad2web/decoder.py", line 127, in init
    device_type = Setting.get_by_name('device_type').value
  File "/opt/alarmdecoder-webapp/ad2web/settings/models.py", line 18, in get_by_name
    setting = cls.query.filter_by(name=name).first()
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2327, in first
    ret = list(self[0:1])
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2194, in __getitem__
    return list(res)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2398, in __iter__
    return self._execute_and_instances(context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2413, in _execute_and_instances
    result = conn.execute(querycontext.statement, self._params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 717, in execute
    return meth(self, multiparams, params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py", line 317, in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 814, in _execute_clauseelement
    compiled_sql, distilled_params
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 927, in _execute_context
    context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1076, in _handle_dbapi_exception
    exc_info
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 185, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 920, in _execute_context
    context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 425, in do_execute
    cursor.execute(statement, parameters)
OperationalError: (OperationalError) no such table: settings u'SELECT settings.id AS settings_id, settings.name AS settings_name, settings.int_value AS settings_int_value, settings.string_value AS settings_string_value \nFROM settings \nWHERE settings.name = ?\n LIMIT ? OFFSET ?' ('device_type', 1, 0)

Currently if I run manage.py initdb, I don't get any errors printed to the screen. But I do notice this in the alarmdecoder.log:

Code: Select all

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gunicorn/arbiter.py", line 502, in spawn_worker
    worker.init_process()
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/ggevent.py", line 193, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/base.py", line 120, in init_process
    self.run()
  File "/usr/local/lib/python2.7/dist-packages/socketio/sgunicorn.py", line 80, in run
    **ssl_args
  File "/usr/local/lib/python2.7/dist-packages/socketio/server.py", line 72, in __init__
    address = args[0].cfg_addr[0]
AttributeError: 'socket' object has no attribute 'cfg_addr'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gunicorn/arbiter.py", line 502, in spawn_worker
    worker.init_process()
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/ggevent.py", line 193, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/base.py", line 120, in init_process
    self.run()
  File "/usr/local/lib/python2.7/dist-packages/socketio/sgunicorn.py", line 80, in run
    **ssl_args
  File "/usr/local/lib/python2.7/dist-packages/socketio/server.py", line 72, in __init__
    address = args[0].cfg_addr[0]
AttributeError: 'socket' object has no attribute 'cfg_addr'

[Scott]

Oops, yea. The db is in the instance directory. The error about the settings table is normal (until I figure out a good fix for it) and shouldn't affect anything. Normally I'm the only one who sees it.

The cfg_addr bit is an interesting one. I've never tried an update/upgrade on the image, but I could easily see something like that happening. Side note, we have an unstable repo set up in order to support the newer version of nginx that supports websockets, so that may have something to do with it. Trying a fresh copy of the image to eliminate the upgrade might be a good idea.

One question, though, as it seems to be related to addresses/naming.. did you rename the device in /etc/hostname or anything?

Thanks,
Scott

[jplee3]

Oops, yea. The db is in the instance directory. The error about the settings table is normal (until I figure out a good fix for it) and shouldn't affect anything. Normally I'm the only one who sees it.

The cfg_addr bit is an interesting one. I've never tried an update/upgrade on the image, but I could easily see something like that happening. Side note, we have an unstable repo set up in order to support the newer version of nginx that supports websockets, so that may have something to do with it. Trying a fresh copy of the image to eliminate the upgrade might be a good idea.

One question, though, as it seems to be related to addresses/naming.. did you rename the device in /etc/hostname or anything?

Thanks,
Scott

Thanks for the info. Yea I was thinking I should just re-image everything and start from scratch. What you said makes sense since this is in Beta It seems like the newer version of gunicorn I installed may have issues. I'm running on 0.19 I believe. What was the version of gunicorn that this was originally running on? 0.17? I suppose I could try reverting back since I'm pretty sure it got upgraded.

I have not renamed the device - it's still "alarmdecoder"