High rate of 419's in a specific setup #5115

New Issue

OVERLORD · 2026-02-05T09:41:25+03:00

OVERLORD commented

2026-02-05 09:41:25 +03:00

Originally created by @iwesselk on GitHub (Jan 13, 2025).

Describe the Bug

I am using fly.io for hosting. In this setup, the mysql server is 24/7, but I am letting the web server piece (book stacks larval setup) go to sleep by pausing, which sometimes results in a shutdown.

When the server "unpauses", it typically loses enough state that edit and login pages result in 419's at a higher rate. The page will continue to fail with 419's until the refresh button is used.

Steps to Reproduce

Run the bookstack server
Go to edit a page
Restart the bookstack server before hitting submit/save
The page is likely to fail with a 419

Expected Behaviour

I am guessing this might not be exactly a supported use case. However, I don't see any documentation for this behavior (I might have missed it), and I don't know where to start looking in the code to see if I can identify the cause, or patch it with a hack or actual PR.

I could switch the server to never shut down, but that adds cost that I was hoping to avoid.

Screenshots or Additional Context

Logins, and page edits are the main culprits. Page edit is the most painful one, as that very frequently goes across the "server pause" timeout.

Browser Details

Firefox 133.0.3 on Ubuntu 24.04

Exact BookStack Version

v24.12.1

Originally created by @iwesselk on GitHub (Jan 13, 2025). ### Describe the Bug I am using fly.io for hosting. In this setup, the mysql server is 24/7, but I am letting the web server piece (book stacks larval setup) go to sleep by pausing, which sometimes results in a shutdown. When the server "unpauses", it typically loses enough state that edit and login pages result in 419's at a higher rate. The page will continue to fail with 419's until the refresh button is used. ### Steps to Reproduce 1. Run the bookstack server 2. Go to edit a page 3. Restart the bookstack server before hitting submit/save 4. The page is likely to fail with a 419 ### Expected Behaviour I am guessing this might not be exactly a supported use case. However, I don't see any documentation for this behavior (I might have missed it), and I don't know where to start looking in the code to see if I can identify the cause, or patch it with a hack or actual PR. I could switch the server to never shut down, but that adds cost that I was hoping to avoid. ### Screenshots or Additional Context Logins, and page edits are the main culprits. Page edit is the most painful one, as that very frequently goes across the "server pause" timeout. ### Browser Details Firefox 133.0.3 on Ubuntu 24.04 ### Exact BookStack Version v24.12.1

OVERLORD added the 🐛 Bug label 2026-02-05 09:41:25 +03:00

OVERLORD closed this issue

2026-02-05 09:41:27 +03:00

OVERLORD commented

2026-02-05 09:41:30 +03:00

@ssddanbrown commented on GitHub (Jan 13, 2025):

Hi @iwesselk,

Is this docker based?
Is there full filesystem persistence in this environment?

It sounds like the default filesystem-based session storage is being destroyed when your environment is going into shutdown, which could occur if it's effectively a container style setup that's destroyed and re-created, with only certain folders retained.

If that's the case, you can configure the session (and cache) to use the database instead of the filesystem as detailed here:
https://www.bookstackapp.com/docs/admin/cache-session-config/#database

@ssddanbrown commented on GitHub (Jan 13, 2025): Hi @iwesselk, - Is this docker based? - Is there full filesystem persistence in this environment? It sounds like the default filesystem-based session storage is being destroyed when your environment is going into shutdown, which could occur if it's effectively a container style setup that's destroyed and re-created, with only certain folders retained. If that's the case, you can configure the session (and cache) to use the database instead of the filesystem as detailed here: https://www.bookstackapp.com/docs/admin/cache-session-config/#database

OVERLORD commented

2026-02-05 09:41:34 +03:00

@iwesselk commented on GitHub (Jan 13, 2025):

Now that I think about it, I saw the cache at some point when setting up, but didn't think about it for this use case...

I am using the docker image. And there is database persistence, but I only have mapped /var/bookstack/storage/uploads

I am setting up the configs now and seeing if that fixes the issues.

@iwesselk commented on GitHub (Jan 13, 2025): Now that I think about it, I saw the cache at some point when setting up, but didn't think about it for this use case... I am using the docker image. And there is database persistence, but I only have mapped `/var/bookstack/storage/uploads` I am setting up the configs now and seeing if that fixes the issues.

OVERLORD commented

2026-02-05 09:41:35 +03:00

@ssddanbrown commented on GitHub (Jan 13, 2025):

I am using the docker image.

Okay, good chance the session files were being destroyed in the stop/start process then.

And there is database persistence, but I only have mapped /var/bookstack/storage/uploads

Might want to double check that, if that's the actual path you've mapped.
That's not a path used by any of the common container images I've seen.
Which paths you map depends on the image used.

@ssddanbrown commented on GitHub (Jan 13, 2025): > I am using the docker image. Okay, good chance the session files were being destroyed in the stop/start process then. > And there is database persistence, but I only have mapped /var/bookstack/storage/uploads Might want to double check that, if that's the actual path you've mapped. That's not a path used by any of the common container images I've seen. Which paths you map depends on the image used.

OVERLORD commented

2026-02-05 09:41:37 +03:00

@iwesselk commented on GitHub (Jan 13, 2025):

I'm using the solidnerd image, instead of the docker-bookstack image. It uses the usual /var/www layout unlike the docker-bookstack container. I just tried the docker-bookstack image, since it uses /config as a single mount location, and that would have been better, but it refused to come back up.

Anyway, I just tested the force shut down and let the http endpoint wake the server back up, and there were not any issues, so it looks like the CACHE_DRIVER and SESSION_DRIVER configs were my issue.

@iwesselk commented on GitHub (Jan 13, 2025): I'm using the solidnerd image, instead of the docker-bookstack image. It uses the usual /var/www layout unlike the docker-bookstack container. I just tried the docker-bookstack image, since it uses /config as a single mount location, and that would have been better, but it refused to come back up. Anyway, I just tested the force shut down and let the http endpoint wake the server back up, and there were not any issues, so it looks like the `CACHE_DRIVER` and `SESSION_DRIVER` configs were my issue.

OVERLORD referenced this issue

2026-02-05 10:32:33 +03:00

[PR #5115] [CLOSED] show-or-create for pages #6448

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5115