Plex Media Server crashes multiple times a day, every day due to "Sqlite3: Sleeping for 200ms to retry busy DB" flooding

Server Version#: 1.25.7.5604

Ever since the 1.25.xxx builds, I’ve been experiencing server crashing daily and multiple times a day. I’m getting really tired of family members complaining that the Plex is down… again. Rebooting the docker brings everything back up, but this is getting ridiculous.

Looking at the docker image logs for Plex, I’m seeing a ton of: Sqlite3: Sleeping for 200ms to retry busy DB spam until the connection to the server is closed out.

I’m running out of ideas on how to resolve this issue.

Database is on an NVMe SSD drive with plenty of room available on the drive.
The system RAM (32GB) is good as well.
Clients range from web browsers, Roku, game consoles, and smart TV apps.
The only new element to the server has been drive upgrades one at a one, and those drives have tested good after 72 hours of zeroing.

I’m attaching my logs and hope someone can help as Plex has worked like a champ for many years!

I appreciate any help you can provide.

Thank You!

Plex Media Server Logs_2022-03-06_22-07-08.zip (3.6 MB)

My server has crashed twice in 24 hours.

This is getting REALLY out of hand and frustrating at this point.

Any help would be great.

Crashed again for a third time in the middle of movie.

And now my server can’t stay online!

When attempting to optimize the database, it hangs Plex and crashes it.

Even restarting Plex does not restore functionality! I am nearly done with this platform if I can’t get a stable working server!

HELP!

In the logs you posted before, I see shutdowns at these times:

Plex Media Server.1.log:Mar 06, 2022 22:06:37.450 [0x14c80e949b38] DEBUG - Shutting down with signal 15 (Terminated)
Plex Media Server.4.log:Mar 06, 2022 15:04:17.606 [0x153fbe247b38] DEBUG - Shutting down with signal 15 (Terminated)

Signal 15 is a normal “System asked me to stop” message, implying that something else on the system requested Plex stop.

Does Docker (or Unraid) provide any logging about these events?

I also see a few of these:

Plex Media Server.5.log:Mar 06, 2022 02:38:26.333 [0x153fb7e97b38] ERROR - Thread: Uncaught exception running async task which was spawned by thread 0x153fbe2c9b38: sqlite3_statement_backend::loadOne: database is locked

What storage is this on? And what version of Unraid? Unraid has a history of filesystem damage where the FUSE-based filesystem was unsafe for databases.

One workaround was to move the Plex data directory to a cache disk, bypassing the FUSE/mergerfs problems.

often a sign the DB is corrupt.

https://support.plex.tv/articles/repair-a-corrupted-database/

Thanks for the response Volts!

Some additional details:

Unraid 6.9.2
The Plex data directory is on an NVMe 256GB cache drive.

The Docker logs are pretty vanilla unfortunately:

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 40-chown-files: executing...
[cont-init.d] 40-chown-files: exited 0.
[cont-init.d] 45-plex-claim: executing...
[cont-init.d] 45-plex-claim: exited 0.
[cont-init.d] 50-gid-video: executing...
[cont-init.d] 50-gid-video: exited 0.
[cont-init.d] 60-plex-update: executing...
No update required
[cont-init.d] 60-plex-update: exited 0.
[cont-init.d] 90-custom-folders: executing...
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
Starting Plex Media Server.
[services.d] done.
Sqlite3: Sleeping for 200ms to retry busy DB.
Connection to 184.105.148.81 closed by remote host.
Connection to 184.105.148.88 closed by remote host.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Sqlite3: Sleeping for 200ms to retry busy DB.
Connection to 184.105.148.89 closed by remote host.
Connection to 184.105.148.88 closed by remote host.
Sqlite3: Sleeping for 200ms to retry Dolby, Dolby Digital, Dolby Digital Plus, Dolby TrueHD and the double D symbol are trademarks of Dolby Laboratories.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing...
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 01-migrations: executing...
[migrations] started
[migrations] no migrations found
[cont-init.d] 01-migrations: exited 0.
[cont-init.d] 02-tamper-check: executing...
[cont-init.d] 02-tamper-check: exited 0.
[cont-init.d] 10-adduser: executing...
usermod: no changes

appdata: /mnt/user/ mapping to Plex Container or /mnt/cache/ ? Try /mnt/cache/

@HTPC_Lover

Looking at the Docker advanced settings:

Appdata: /mnt/user/appdata/plex

You’re recommending switching it to /mnt/cache ??

Should I move the existing /plex folder in /appdata over to the newly created appdata folder on the cache drive? Or should I use another method to retain the database?

To few details - need to know if this is split on your site:

Do you use a physical cache/pool (SSD, M.2 NVMe) for system data like appdata? What’s the host path? /mnt/user/appdata/plex?

Do you use the Unraid array for your content? What’s the host path? E.g. /mnt/user/Music?

What are your Plex container path mappings? I doubt that Appdata:/mnt/user/appdata/plex is the only path mapping. What are the mappings for your content (music)?

Usually there is no need to move things around. Path mappings are there to avoid just that.

So, what are the path details?

I do use a physical cache drive ((SSD, M.2 NVMe) for Plex (appdata) and the other 4 Dockers I have running. I do my transcodes in the system memory, which there is plenty of (32GB)

Nothing has changed for years as far as my software configuration. Just the hardware has changed with hard drive size bumps and the growing size my very large library.

Here is my pathing as requested.

I am leaning towards the issue being with Plex and the use of SQLite.

Docker Paths (Using the LinuxServer.io distro)

Transcoder Path:

Does anyone from the Plex Development Team know if there is plans or any testing going on with using a different database other than SQLite? I’d love to test if there build available outside of the public beta channel.

Cheers,
David

I assume cache is really on cache and not on a pool and /mnt/cache/appdata will work:

Please change the /mnt/user/appdata/… value to /mnt/cache/appdata/… then and hit Apply. Thats all. No need to move things around. As you are using Media:/mnt for your content this won’t hurt. It’s a test that may help. It does avoid FUSE for the SQLite DB. This combination showed some problems in the past.

Your container config is nearly identical to mine. I’m using 6.9.2 and Linuxservers Plex container. My DB is over 2 GB in size and rock solid. There might be a difference: I stop all containers every night, take backups and restart them. I use my own scripts in the User Scripts plugin for that.

If this does not help your DB might be corrupted.

1 Like

Ok! I’ll give this a shot with the change and so some reading on this FUSE vs SQLite DB situation you’re mentioning.

I just checked the database and apparently it’s “OK”

Fingers crossed and thank you for the assistance. Much appreciated.

Cheers,
David

Ahhhh! Thank you HTPC_Lover for mentioning the FUSE issue.

I found some reading here that goes into it a bit more and I suspect this will help others:

So far, no Sqlite3: Sleeping for 200ms to retry busy DB entries popping up in my docker logs.

Fingers crossed this resolves it, but I’m curious as to why this has become an issue over the last few months versus not becoming an issue sooner.

In fact I use Unraid completely without User Shares - just Disk Shares.

It has some nice effects when using more than a handful of disks. Just change within Plex Libraries from e.g. /mnt/user/Movies to /mnt/disk1/Movies, /mnt/disk2/Movies and so on.

Plex can handle that - no problem at all. But the effect is: Plex addresses an individual disk and not the FUSE layer. Depending on your memory and cached directories other disks may spun up just to find out where the requested content is. This does not happen when using Disk Shares.

Very interesting and thanks for the tip HTPC_Lover!

This seriously should be a huge notice or important note flagged for all the Plex Docker images in my opinion. All the research into this crashing and I totally did not come across this FUSE
layer clash information.

Seriously! Thank you for all your help with this!

Cheers,
David

It’s not a Docker problem. It’s an Unraid-ism, because it uses the FUSE-based filesystem to do some of its tricks.

I was looking, and the Unraid folks posted that they fixed their bug that was impacting SQLite a while ago. That’s interesting.

Hmm I wonder if it was addressed in the upcoming 6.10 UnRAID release that’s currently in Release Candidate status?

We’ll see as it clearly was not fixed in 6.9.2 from what experienced.

No, a while ago.

Unraid | Unraid 6.8 Now Available!

But I still think it’s a good idea to use the simplest filesystem stack possible for SQLite.

It’s fixed already.

What I wrote is based on my own experience. I’m using server-grade hardware and RAM size. Not the latest motherboard, CPU, iGPU, …

My guess is: Many problems show up on the latest hardware, low RAM, desktop-grade hardware (Laptop?) to drive server-grade features (KVM?). And not to forget: BTRFS - I avoid it whereever possible …

Glad I could help.