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: 14
Popularity: 0.000098
First Submitted: 2012-11-04 17:15
Last Updated: 2019-08-31 02:03

Pinned Comments

zancarius commented on 2020-01-23 21:38

I have spent some time exploring options for upgrading this PKGBUILD to the latest version of Sentry and have encountered blocking changes that do not appear to have a clear resolution.

Currently, there were two PKGBUILDs that provide our required Clickhouse dependency but neither of these build successfully. Near as I can tell, some of Clickhouse's upstream dependencies have known issues that as yet have no resolution outside attempting to patch either Clickhouse or wait for the upstream developers to address these deficiencies. This is not something either myself or the maintainer(s) of the Clickhouse PKGBUILD(s) can address (not easily, anyway).

Consequently, I will be updating this PKGBUILD, bumping the pkgrel in effort to increase the visibility of this issue. We will be holding Sentry at its current state until we have a clear path forward.

If you need Sentry 10.x.x in your environment, consider installing their official Docker packages. This is the currently recommended method for installing Sentry.

zancarius commented on 2020-01-17 06:45

Sentry v10.0.0 is out, but I will not be upgrading this package for some time. In fact, I'm not sure when an upgrade will be available because the number of additional service dependencies has since exploded.

To illustrate, Sentry v10.x now depends on:

  • Zookeeper
  • Kafka
  • Clickhouse
  • Snuba

I don't believe Snuba can be disabled in Sentry post-v9.1.2. If this is true, then this means that Sentry now has an implicit dependency on the JRE which may be prohibitive for those users who are running Sentry on lower end hardware or memory-constrained environments.

The official installation guide recommends installing the on-premise edition of Sentry via Docker and advises against source installation, which is what we're doing here.

This leaves us with a couple of options (plus a third thrown in as an either/or):

1) Upgrade anyway and add a host of other dependencies to the PKGBUILD that may surprise some users. Given that Sentry is a complex piece of software to install, this will only add to the complexity and will require additional packages, configuration, etc., that will need to be completed before Sentry can even be upgraded. (The migration process moves events from the database into Snuba, for example.)

2) Cheat and take the easy way out; deprecate this PKGBUILD and point users to the official Docker images. There's no point trying to wrap the Docker images in a PKGBUILD.

3) Rename this package to something like sentry9.1, freezing it at this version, and then pick options #1 or #2.

When I have some time this weekend, I may ask around for advice. There's no easy solution in this case, and I know from past experience with this package that there are some users who may be uninterested in running Sentry v10 if it requires configuring at least 3 other services. I will leave this package flagged for the time being in the hopes users of this package check here.

Latest Comments

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

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',)

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

After performing migrations, I changed the user back:

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 (, 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.


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