Package Details: sentry 8.20.0-1

Git Clone URL: https://aur.archlinux.org/sentry.git (read-only)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL: http://pypi.python.org/pypi/sentry
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 8
Popularity: 0.162773
First Submitted: 2012-11-04 17:15
Last Updated: 2017-09-12 00:12

Pinned Comments

mitchhentges commented on 2017-06-13 04:10

If anyone's curious for the source of the issue, I've linked to the actual Sentry GitHub issue (https://github.com/getsentry/sentry/issues/5502), which can explain it better than I can :)

Thanks zancarius

mitchhentges commented on 2017-06-13 03:54

Resolved the migration issue by following https://github.com/getsentry/sentry/issues/5502.

1. Ensure Sentry is stopped
2. Enter the sentry shell: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry shell"
3. Copy and paste the script from https://github.com/getsentry/sentry/issues/5502#issuecomment-305902686
- Note: I had some issues with the python interpreter not liking the paste, but if you copy and paste my edited contents in two separate chunks, it should work:https://pastebin.com/1sya7XET and https://pastebin.com/xn7cdJYu
4. Check that you don't have duplicates anymore by running the following script on the shell, which should give you "[]".

from sentry.models import *
dupe_envs = Environment.objects.values('name', 'organization_id').annotate(ecount=Count('id')).filter(ecount__gt=1)
print(dupe_envs)

5. Try migrating again: sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry upgrade
6. If migrating again didn't work due to |"sentry_environment_organization_id_6c9098a3d53d6a9a" already exists|, then skip the partially-applied migration: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry django migrate --fake sentry 0321_auto__add_unique_environment_organization_id_name", then migrate again

-----

I'm not sure that there's a way to make this easier within the "sentry" package, or if it's even within the role of the AUR package to handle this issue. Either way, the technical solution is ^

zancarius commented on 2017-05-06 22:42

If you're having trouble launching Sentry due to a missing libssl.so (probably 1.0.0), it's likely a consequence of OpenSSL 1.0.x's recent move into the extra/openssl-1.0 package. OpenSSL 1.1 is now the version installed with the core/openssl package, and building Sentry on a system that previously had OpenSSL 1.0.0 installed may cause problems immediately following an update. At this time, there are three possible workarounds. In order of increasing difficulty they are:

1) Update your system. Rebuild Sentry and install. Do not rebuild Sentry with an AUR helper. Use makepkg directly; you can use yaourt -G to download the package to a build directory, however. AUR helpers add an extra layer of complexity and may make troubleshooting difficult.

If you've already updated your system, update it again using pacman (not yaourt or another wrapper). Rebuild Sentry and reinstall. Again.

2) Install extra/openssl-1.0. This workaround should be adequate for the foreseeable future but doesn't address the underlying problem of uWSGI not building against the latest version of OpenSSL.

3) Uninstall/reinstall uWSGI from Sentry's directory if it refuses to pick up the correct OpenSSL version:

$ /opt/sentry/bin/pip uninstall uwsgi
$ /opt/sentry/bin/pip install --prefix=/opt/sentry uwsgi

(Only do this if you absolutely have to get Sentry running and have no other alternatives.)

=========

This issue has nothing to do with Sentry or with uWSGI's build process (nor is there any reason it should). I've been unable to replicate the problem on any of my machines thusfar, including ones with both core/openssl and extra/openssl-1.0 installed. Therefore, I believe it's possible that the problem may be caused or aggravated by automated tools or scripts (particularly yaourt, if used to update the system + AUR packages) that attempt to update the system (again, including AUR packages) in a single pass or by an ld cache that hasn't yet picked up the new version of OpenSSL. If you're having trouble with OpenSSL versions, you may need to run ldconfig manually to update the appropriate caches (-p may be helpful to see what ldconfig is seeing before updating the cache; see below for reporting difficulties).

Given the nature of OpenSSL and the depth to which it is often intertwined with userland applications, you SHOULD reboot your machine following any update has changed/updated it unless you're comfortable with restarting *all* services by hand. Rebooting is probably faster/easier/less error prone.

REPORTING DIFFICULTIES

If you continue to have trouble, be absolutely certain you've updated your system, rebooted, rebuilt and reinstalled Sentry, and then provide the output of the following:

$ ldconfig -p | grep libssl
$ ldd /opt/sentry/bin/uwsgi | grep libssl

This post may be edited for clarity or to provide further information.

Thanks!

Latest Comments

zancarius commented on 2017-09-12 03:40

Strange. My instance already had `citext` installed, but I a) don't remember installing it and b) my Sentry user isn't a superuser and doesn't have any attributes other than login. I must've installed it some time ago, but that seems unlikely. It explains why I didn't catch this issue.

One thing I might recommend instead is to use the PostgreSQL super user so you don't have to modify the Sentry user (potentially forgetting it has superuser):

$ sudo -u postgres psql "dbname=sentry"
sentry=# create extension if not exists citext;

Obviously, substituting "sentry" for the actual database name of your Sentry install.

If anyone else runs into this issue, I might update the postupgrade/postinstall with some notes but the cause should be self-explanatory even if the solution is not immediately obvious.

Thanks, Mitch! Good catch as always.

mitchhentges commented on 2017-09-12 02:24

Hmm, getting an error when upgrading from 8.19.0 to 8.20.0:

django.db.utils.ProgrammingError: ProgrammingError('permission denied to create extension "citext"\nHINT: Must be superuser to create this extension.\n',)
SQL: CREATE EXTENSION IF NOT EXISTS citext

I'm guessing because the "sentry" user for my postgresql database isn't a superuser, so I made it one:
ALTER USER sentry WITH SUPERUSER;

After performing migrations, I changed the user back:
ALTER USER sentry WITH NOSUPERUSER;

mitchhentges commented on 2017-06-13 04:10

If anyone's curious for the source of the issue, I've linked to the actual Sentry GitHub issue (https://github.com/getsentry/sentry/issues/5502), which can explain it better than I can :)

Thanks zancarius

zancarius commented on 2017-06-13 04:00

Also, note that for smoothly copying and pasting from the issue resolution into the iPython interpreter, you'll need to remove empty lines that are at the same indentation level.

Edit: Since I forgot the AUR comments don't retain indentation level, I went ahead and fixed the formatting for the fix @mitchhentges linked below[1]. This should copy and paste just fine.

[1] https://gist.github.com/zancarius/33cd0ae7425198a16a63a0024ebf9644

zancarius commented on 2017-06-13 03:57

Removed my previous comment.

@mitchhentges I've pinned your resolution. I don't know if you want to add a little extra commentary to it to indicate the source of the problem or not, but feel free if so.

mitchhentges commented on 2017-06-13 03:54

Resolved the migration issue by following https://github.com/getsentry/sentry/issues/5502.

1. Ensure Sentry is stopped
2. Enter the sentry shell: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry shell"
3. Copy and paste the script from https://github.com/getsentry/sentry/issues/5502#issuecomment-305902686
- Note: I had some issues with the python interpreter not liking the paste, but if you copy and paste my edited contents in two separate chunks, it should work:https://pastebin.com/1sya7XET and https://pastebin.com/xn7cdJYu
4. Check that you don't have duplicates anymore by running the following script on the shell, which should give you "[]".

from sentry.models import *
dupe_envs = Environment.objects.values('name', 'organization_id').annotate(ecount=Count('id')).filter(ecount__gt=1)
print(dupe_envs)

5. Try migrating again: sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry upgrade
6. If migrating again didn't work due to |"sentry_environment_organization_id_6c9098a3d53d6a9a" already exists|, then skip the partially-applied migration: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry django migrate --fake sentry 0321_auto__add_unique_environment_organization_id_name", then migrate again

-----

I'm not sure that there's a way to make this easier within the "sentry" package, or if it's even within the role of the AUR package to handle this issue. Either way, the technical solution is ^

mitchhentges commented on 2017-06-13 03:35

Hmm, I got an error while migrating, I'll see if anything exists in the Sentry issue tracker.

---------------------------------------

$ sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry upgrade
// snip
Running migrations for sentry:
- Migrating forwards to 0326_auto__add_field_groupsnooze_count__add_field_groupsnooze_window__add_f.
> sentry:0321_auto__add_unique_environment_organization_id_name
FATAL ERROR - The following SQL query failed: CREATE UNIQUE INDEX CONCURRENTLY sentry_environment_organization_id_6c9098a3d53d6a9a ON sentry_environment (organization_id, name)
The error was: ProgrammingError('relation "sentry_environment_organization_id_6c9098a3d53d6a9a" already exists\n',)
SQL: CREATE UNIQUE INDEX CONCURRENTLY sentry_environment_organization_id_6c9098a3d53d6a9a ON sentry_environment (organization_id, name)
Traceback (most recent call last):
File "/opt/sentry/bin/sentry", line 14, in <module>
sys.exit(main())
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/__init__.py", line 160, in main
cli(prog_name=get_prog(), obj={}, max_content_width=100)
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/decorators.py", line 36, in inner
return ctx.invoke(f, *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/upgrade.py", line 60, in upgrade
_upgrade(not noinput, traceback, verbosity, not no_repair)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/upgrade.py", line 29, in _upgrade
verbosity=verbosity,
File "/opt/sentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 159, in call_command
return klass.execute(*args, **defaults)
File "/opt/sentry/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/opt/sentry/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/opt/sentry/lib/python2.7/site-packages/south/migration/__init__.py", line 220, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 256, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 331, in migrate_many
result = self.migrate(migration, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 133, in migrate
result = self.run(migration, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 114, in run
return self.run_migration(migration, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 91, in run_migration
south.db.db.rollback_transaction()
File "/opt/sentry/lib/python2.7/site-packages/south/db/generic.py", line 1000, in rollback_transaction
transaction.leave_transaction_management(using=self.db_alias)
File "/opt/sentry/lib/python2.7/site-packages/django/db/transaction.py", line 78, in leave_transaction_management
get_connection(using).leave_transaction_management()
File "/opt/sentry/lib/python2.7/site-packages/django/db/backends/__init__.py", line 310, in leave_transaction_management
"This code isn't under transaction management")
django.db.transaction.TransactionManagementError: This code isn't under transaction management

zancarius commented on 2017-05-06 22:42

If you're having trouble launching Sentry due to a missing libssl.so (probably 1.0.0), it's likely a consequence of OpenSSL 1.0.x's recent move into the extra/openssl-1.0 package. OpenSSL 1.1 is now the version installed with the core/openssl package, and building Sentry on a system that previously had OpenSSL 1.0.0 installed may cause problems immediately following an update. At this time, there are three possible workarounds. In order of increasing difficulty they are:

1) Update your system. Rebuild Sentry and install. Do not rebuild Sentry with an AUR helper. Use makepkg directly; you can use yaourt -G to download the package to a build directory, however. AUR helpers add an extra layer of complexity and may make troubleshooting difficult.

If you've already updated your system, update it again using pacman (not yaourt or another wrapper). Rebuild Sentry and reinstall. Again.

2) Install extra/openssl-1.0. This workaround should be adequate for the foreseeable future but doesn't address the underlying problem of uWSGI not building against the latest version of OpenSSL.

3) Uninstall/reinstall uWSGI from Sentry's directory if it refuses to pick up the correct OpenSSL version:

$ /opt/sentry/bin/pip uninstall uwsgi
$ /opt/sentry/bin/pip install --prefix=/opt/sentry uwsgi

(Only do this if you absolutely have to get Sentry running and have no other alternatives.)

=========

This issue has nothing to do with Sentry or with uWSGI's build process (nor is there any reason it should). I've been unable to replicate the problem on any of my machines thusfar, including ones with both core/openssl and extra/openssl-1.0 installed. Therefore, I believe it's possible that the problem may be caused or aggravated by automated tools or scripts (particularly yaourt, if used to update the system + AUR packages) that attempt to update the system (again, including AUR packages) in a single pass or by an ld cache that hasn't yet picked up the new version of OpenSSL. If you're having trouble with OpenSSL versions, you may need to run ldconfig manually to update the appropriate caches (-p may be helpful to see what ldconfig is seeing before updating the cache; see below for reporting difficulties).

Given the nature of OpenSSL and the depth to which it is often intertwined with userland applications, you SHOULD reboot your machine following any update has changed/updated it unless you're comfortable with restarting *all* services by hand. Rebooting is probably faster/easier/less error prone.

REPORTING DIFFICULTIES

If you continue to have trouble, be absolutely certain you've updated your system, rebooted, rebuilt and reinstalled Sentry, and then provide the output of the following:

$ ldconfig -p | grep libssl
$ ldd /opt/sentry/bin/uwsgi | grep libssl

This post may be edited for clarity or to provide further information.

Thanks!

zancarius commented on 2017-05-05 02:38

I'm not sure I can explain this given that I can't replicate the problem. It *should* be linking against whatever OpenSSL version is on the build host.

I suppose you could grep through ldconfig -v to see what it thinks it sees, but I'm not optimistic that will yield any clues. Outside something like ld.so.cache not updating properly (which should've meant uWSGI would fail to build), I'm out of ideas.

I doubt it'll happen again but being as this PKGBUILD simply calls `pip` to install Sentry there's no reason it shouldn't have worked any differently from installing uWSGI into the Sentry directory manually.

Possibly interesting discussion thread begins here suggesting some packages may not have been fully built against OpenSSL 1.1.x.:

https://bugs.archlinux.org/task/53776

Honestly, I'm not sure this is an issue that can be resolved with this PKGBUILD or even Sentry for that matter.

mitchhentges commented on 2017-05-05 02:11

I didn't install extra/openssl-1.0, but here's what I found:

Re-building with yaourt (after clearing /tmp/yaourt-tmp-mitch), |ldd /opt/sentry/bin/uwsgi| showed "not found" for libssl.so.1.0

After manually running makepkg, then extracting the package, |ldd uwsgi| showed "not found" for libssl.so.1.0.0

Interestingly, if I sftp'd /the same/ uwsgi file from ^ to my desktop (from my server, where sentry was being built), I successfully got: "libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fbeb4e6b000)"

Finally, installing uwsgi through pip solved my problem, |ldd /opt/sentry/bin/uwsgi| on my server shows: "libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007fcaf9357000)

It's running now, but I'm nervous about the next update
"

All comments