Libvips upgrade error

Product Support Self-hosting

AI-generated summary

Andrea_Fumi reported boot failures after upgrading their Docker-based Discourse installation (versions 2026.7.3 to 2026.11.0), citing libvips operation errors and subsequent process crashes. david noted that the discourse/discourse Docker image is experimental and not regularly tested, recommending the standard install for production. While pfaffman questioned the non-standard port configuration, Andrea clarified that HTTPS was handled via a reverse proxy and the issue persisted in newer builds with specific Landlock and seccomp syscall errors.

Further investigation revealed the instance was running on a Synology NAS with an outdated Linux kernel (4.4.302). david explained that the old kernel likely lacked necessary seccomp protections required by the new libvips sandboxing features, causing the fatal error. He strongly advised migrating to a more modern, secure environment because image processing is a common exploit vector, and disabling sandboxing would leave the forum vulnerable. Andrea_Fumi decided to move the forum to a mini PC with Proxmox. Ultimately, tgxworld confirmed that a bug related to this issue was fixed and backported.

1

I’ve a problem upgrading docker (discourse/discourse) from 2026.7.3 to 2026.7.4 (also the 2026.11.0-latest have the same problem):

#<Thread:0x00007f7bea3d8430 /var/www/discourse/lib/discourse.rb:1342 run> terminated with exception (report_on_exception is true):

/var/www/discourse/lib/discourse_vips/client.rb:50:in 'block in DiscourseVips::Client.call': libvips operation failed (DiscourseVips::Error)

	from /var/www/discourse/lib/image_processing/instrumentation.rb:6:in 'ImageProcessing::Instrumentation.instrument'

	from /var/www/discourse/lib/discourse_vips/client.rb:40:in 'DiscourseVips::Client.call'

	from /var/www/discourse/lib/discourse_vips.rb:14:in 'DiscourseVips.version'

	from /var/www/discourse/lib/letter_avatar.rb:140:in 'LetterAvatar.vips_version'

	from /var/www/discourse/lib/letter_avatar.rb:36:in 'LetterAvatar.version'

	from /var/www/discourse/lib/discourse.rb:1343:in 'block in Discourse.preload_rails!'

/var/www/discourse/lib/discourse_vips/client.rb:50:in 'block in DiscourseVips::Client.call': libvips operation failed (DiscourseVips::Error)

	from /var/www/discourse/lib/image_processing/instrumentation.rb:6:in 'ImageProcessing::Instrumentation.instrument'

	from /var/www/discourse/lib/discourse_vips/client.rb:40:in 'DiscourseVips::Client.call'

	from /var/www/discourse/lib/discourse_vips.rb:14:in 'DiscourseVips.version'

	from /var/www/discourse/lib/letter_avatar.rb:140:in 'LetterAvatar.vips_version'

	from /var/www/discourse/lib/letter_avatar.rb:36:in 'LetterAvatar.version'

	from /var/www/discourse/lib/discourse.rb:1343:in 'block in Discourse.preload_rails!'

E, [2026-11-09T11:44:20.275076 #11010] ERROR -- : mold gen=0 pid=11013 reaped (#<Process::Status: pid 11013 exit 1>)

I, [2026-11-09T11:44:20.275357 #11010]  INFO -- : reaped unknown subprocess #<Process::Status: pid 11063 SIGKILL (signal 9)>

/var/www/discourse/vendor/bundle/ruby/4.0.0/gems/pitchfork-0.18.2/lib/pitchfork/http_server.rb:179:in 'Pitchfork::HttpServer#start': The initial mold failed to boot (Pitchfork::BootFailure)

	from /var/www/discourse/vendor/bundle/ruby/4.0.0/gems/pitchfork-0.18.2/exe/pitchfork:110:in '<top (required)>'

	from /usr/local/lib/ruby/4.0.0/rubygems.rb:305:in 'Kernel#load'

	from /usr/local/lib/ruby/4.0.0/rubygems.rb:305:in 'Gem.activate_and_load_bin_path'

	from /var/www/discourse/vendor/bundle/ruby/4.0.0/bin/pitchfork:25:in '<main>'

./config/unicorn_launcher: line 93: kill: (11010) - No such process

./config/unicorn_launcher: line 13: kill: (11010) - No such process

(10949) exiting

Can you please check the builds?

2

Are you using a standard install?

3

Hello David,
I’m using version discourse/discourse on docker hub (discourse/discourse - Docker Image) with “redis:7-alpine” and “discourse/postgres:latest”.

Here my current configuration (as docker compose):

services:
  redis:
    image: redis:7-alpine
    container_name: redis
    volumes:
      - /volume1/docker/discourse/redis_data:/data:rw
    ports:
      - '6379:6379'
    command: "redis-server --appendonly yes"
    restart: unless-stopped
    labels:
      - 'wud.tag.include=^([0-9]\d*)\-alpine$$'
      - 'wud.watch.digest=true'
      - 'wud.display.name=DiscourseRedis'
      - 'wud.display.icon=mdi:map-search'

  discourse_db:
    image: discourse/postgres:latest
    container_name: discourse_db
    volumes:
      - /volume1/docker/discourse/discourse_postgres:/var/lib/postgresql:rw
      - /volume1/docker/discourse/discourse_postgres_data:/var/lib/postgresql/data:rw
    environment:
      POSTGRES_DB: discourse
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: "***"
      DB_USER: discourse_user
      DB_PASSWORD: "***"
    restart: unless-stopped
    labels:
      - 'wud.watch.digest=true'
      - 'wud.display.name=DiscoursePostgres'
      - 'wud.display.icon=mdi:map-search'

  discourse:
    image: discourse/discourse:2026.7.3
    container_name: discourse
    depends_on:
      - discourse_db
      - redis
    ports:
      - '8093:80'
    volumes:
      - /volume1/docker/discourse/discourse_data:/shared
    environment:
      DISCOURSE_HOSTNAME: my.host.name
      DISCOURSE_DEVELOPER_EMAILS: "my@email.eu"
      DISCOURSE_DB_HOST: discourse_db
      DISCOURSE_DB_PORT: 5432
      DISCOURSE_DB_NAME: discourse
      DISCOURSE_DB_USERNAME: discourse_user
      DISCOURSE_DB_PASSWORD: "***"
      DISCOURSE_REDIS_HOST: redis
      DISCOURSE_REDIS_PORT: 6379
      DISCOURSE_SMTP_ADDRESS: 10.10.x.x
      DISCOURSE_SMTP_PORT: 587
      DISCOURSE_SMTP_ENABLE_START_TLS: true
      DISCOURSE_SMTP_USER_NAME: my
      DISCOURSE_SMTP_PASSWORD: "****"
      #DISCOURSE_SMTP_FORCE_TLS: true
      DISCOURSE_SMTP_DOMAIN: my.domain
      DISCOURSE_SMTP_AUTHENTICATION: login
      DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
      DISCOURSE_NOTIFICATION_EMAIL: noreply@email.eu
      LANG: it_IT.UTF-8
    restart: unless-stopped
    labels:
      - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'
      - 'wud.watch.digest=true'
      - 'wud.display.name=Discourse'
      - 'wud.display.icon=mdi:map-search'
5

The discourse/discourse image is still experimental, and isn’t something that we regularly test. That said, I have mentioned it internally so we’ll see if someone can take a look.

For a production installation, we recommend the standard install procedure.

6

Discourse won’t run on a non standard port and requires https. It won’t work on port 8093

7

Sorry, but it always worked as it’s simply the port mapping of the docker container. Also the SSL encapsulation is provided by NGINX, and shouldn’t be a problem for discourse.

The error I receive with releases from end of October, is due to libvips changes as image processor, not socket-related :thinking:

8

Just tried the newly released 2026.7.5, but errors with libvips are still there:

#<Thread:0x00007f7ebef58d88 /var/www/discourse/lib/discourse.rb:1309 run> terminated with exception (report_on_exception is true):

/var/www/discourse/lib/discourse_vips/client.rb:50:in 'block in DiscourseVips::Client.call': libvips operation failed: Landlock child setup failed: Landlock::SyscallError: seccomp(SECCOMP_SET_MODE_FILTER) failed: Invalid argument (DiscourseVips::Error)

	from /var/www/discourse/lib/image_processing/instrumentation.rb:6:in 'ImageProcessing::Instrumentation.instrument'

	from /var/www/discourse/lib/discourse_vips/client.rb:40:in 'DiscourseVips::Client.call'

	from /var/www/discourse/lib/discourse_vips.rb:14:in 'DiscourseVips.version'

	from /var/www/discourse/lib/letter_avatar.rb:140:in 'LetterAvatar.vips_version'

	from /var/www/discourse/lib/letter_avatar.rb:36:in 'LetterAvatar.version'

	from /var/www/discourse/lib/discourse.rb:1310:in 'block in Discourse.preload_rails!'

/var/www/discourse/lib/discourse_vips/client.rb:50:in 'block in DiscourseVips::Client.call': libvips operation failed: Landlock child setup failed: Landlock::SyscallError: seccomp(SECCOMP_SET_MODE_FILTER) failed: Invalid argument (DiscourseVips::Error)

	from /var/www/discourse/lib/image_processing/instrumentation.rb:6:in 'ImageProcessing::Instrumentation.instrument'

	from /var/www/discourse/lib/discourse_vips/client.rb:40:in 'DiscourseVips::Client.call'

	from /var/www/discourse/lib/discourse_vips.rb:14:in 'DiscourseVips.version'

	from /var/www/discourse/lib/letter_avatar.rb:140:in 'LetterAvatar.vips_version'

	from /var/www/discourse/lib/letter_avatar.rb:36:in 'LetterAvatar.version'

	from /var/www/discourse/lib/discourse.rb:1310:in 'block in Discourse.preload_rails!'

E, [2026-11-11T09:08:04.096537 #1021] ERROR -- : mold gen=0 pid=1024 reaped (#<Process::Status: pid 1024 exit 1>)

I, [2026-11-11T09:08:04.096668 #1021]  INFO -- : reaped unknown subprocess #<Process::Status: pid 1085 SIGKILL (signal 9)>

/var/www/discourse/vendor/bundle/ruby/4.0.0/gems/pitchfork-0.18.2/lib/pitchfork/http_server.rb:179:in 'Pitchfork::HttpServer#start': The initial mold failed to boot (Pitchfork::BootFailure)

	from /var/www/discourse/vendor/bundle/ruby/4.0.0/gems/pitchfork-0.18.2/exe/pitchfork:110:in '<top (required)>'

	from /usr/local/lib/ruby/4.0.0/rubygems.rb:305:in 'Kernel#load'

	from /usr/local/lib/ruby/4.0.0/rubygems.rb:305:in 'Gem.activate_and_load_bin_path'

	from /var/www/discourse/vendor/bundle/ruby/4.0.0/bin/pitchfork:25:in '<main>'

./config/unicorn_launcher: line 93: kill: (1021) - No such process

./config/unicorn_launcher: line 13: kill: (1021) - No such process

(949) exiting
9 
Landlock::SyscallError: seccomp(SECCOMP_SET_MODE_FILTER) failed: Invalid argument (DiscourseVips::Error)

What kind of machine are you running Discourse on? Does it have an up-to-date linux Kernel? Any unusual virtualization going on?

10

It’s a Synology NAS, with fw DSM 7.4.1-90080 Update 1 (latest available), which runs on an old kernel version (4.4.302) as any Synology NAS.

Could this be the problem?

11

The old kernel version means you wouldn’t be able to run the ‘Landlock’ sandboxing. But that should degrade gracefully, and show a large warning in the admin panel.

The problem here seems to be the ‘seccomp’ protections, which we try to apply in all situations. If the synology kernel is missing seccomp (which sounds likely), then that explains the failure.

We might be able to make it fail more gracefully, but then your forum’s image processing would be running with absolutely no sandboxing.

So either way, I’d strongly recommend trying to find a more up-to-date/secure environment to run your forum, especially if it’s on the public internet. Image processing is becoming an increasingly common vector for exploits in recent months, which is why we’ve added the sandboxing.

12

Thank you for clarification, I’ll change the host of the forum, moving it on a minipc with Proxmox.

Thanks!

14

Just noting here that the bug has been fixed and backported: FIX: Allow startup when image sandboxing is unavailable - Pull Request #46025 - discourse/discourse - GitHub