Package Details: sentry 9.1.2-1

Git Clone URL: (read-only, click to copy)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL:
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 13
Popularity: 0.114609
First Submitted: 2012-11-04 17:15
Last Updated: 2019-08-31 02:03

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

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

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
- 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: and
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)

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>
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/", line 160, in main
cli(prog_name=get_prog(), obj={}, max_content_width=100)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 722, in __call__
return self.main(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 697, in main
rv = self.invoke(ctx)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/opt/sentry/lib/python2.7/site-packages/click/", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 535, in invoke
return callback(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/", line 36, in inner
return ctx.invoke(f, *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 535, in invoke
return callback(*args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/click/", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/", line 60, in upgrade
_upgrade(not noinput, traceback, verbosity, not no_repair)
File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/", line 29, in _upgrade
File "/opt/sentry/lib/python2.7/site-packages/django/core/management/", line 159, in call_command
return klass.execute(*args, **defaults)
File "/opt/sentry/lib/python2.7/site-packages/django/core/management/", line 285, in execute
output = self.handle(*args, **options)
File "/opt/sentry/lib/python2.7/site-packages/south/management/commands/", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 220, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 256, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 331, in migrate_many
result = self.migrate(migration, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 133, in migrate
result =, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 114, in run
return self.run_migration(migration, database)
File "/opt/sentry/lib/python2.7/site-packages/south/migration/", line 91, in run_migration
File "/opt/sentry/lib/python2.7/site-packages/south/db/", line 1000, in rollback_transaction
File "/opt/sentry/lib/python2.7/site-packages/django/db/", line 78, in leave_transaction_management
File "/opt/sentry/lib/python2.7/site-packages/django/db/backends/", 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 (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.


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.


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 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.:

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

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

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

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

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

zancarius commented on 2017-05-05 00:57

I'm wondering if there's something wrong with your linker or yaourt is interfering. Upon rebuilding Sentry or reinstalling uWSGI, ldd shows the following:

[corona:sentry]$ ldd /opt/sentry/bin/uwsgi
[snip] => /usr/lib/ (0x00007f8f91c4b000)

I'd imagine yours is still showing I'd suggest trying at least one of the following:

- Don't use yaourt. Build the package with makepkg. You can use yaourt to collect the package, e.g.:

$ yaourt -G sentry
$ cd sentry && makepkg

- If the above doesn't work, try installing uwsgi by hand and see whether ldd shows any changes:

$ cd /opt/sentry
$ sudo -u sentry ./bin/pip uninstall uwsgi
$ sudo -u sentry ./bin pip install --prefix=/opt/sentry uwsgi

zancarius commented on 2017-05-05 00:37

For the time being, it looks like you may need to install the package extra/openssl-1.0. I may update this PKGBUILD to include that in the dependencies, but I'd much rather find a more permanent solution.

mitchhentges commented on 2017-05-04 22:55

I rebuilt Sentry (yaourt -S sentry). That didn't do the trick, but I'm not too worried. Thanks for investigating into this, let me know if you need more details!

zancarius commented on 2017-05-04 22:29

Ah, looks like there's been a bump in the OpenSSL version recently (within the last 1-2 weeks).

I'd suggest rebuilding Sentry if you haven't already and see if that works. If you're using makepkg by hand, try removing the `pkg` and `src` dirs completely first. If you've updated Arch, it might be impossible to downgrade OpenSSL otherwise due to dependencies and such.

I can't pick this back up until later this evening, but if that doesn't work for you, I'll take a look in about 2-3 hours or so.