mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
Database error while starting server #1929
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#1929
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mistwyrm on GitHub (Jul 23, 2020).
Describe the bug
I pulled the new image for Jellyfin to update to 10.6.0 and encountered the error listed in the logs. Deleting the image or creating a new container does not seem to help. I'm assuming a database file may have become corrupted, but am not sure which one. I do have plenty of space on my drive.
System (please complete the following information):
Expected behavior
Server to start
Logs
@BaronGreenback commented on GitHub (Jul 23, 2020):
Possible cause:- database journal file (ending in -journal) is not writable
@mistwyrm commented on GitHub (Jul 24, 2020):
Did further testing, loading 10.5.5 fixes the problem, reloading 10.6.0 reintroduces the problem. Deleting all files in the config file and allowing Jellyfin to recreate them does not fix the problem.
@xyx208 commented on GitHub (Jul 27, 2020):
where is the config file in? thank you!
@BaronGreenback commented on GitHub (Jul 27, 2020):
/config/data
from the look of your setup it's found above.
@xyx208 commented on GitHub (Jul 29, 2020):
thanks!
@BaronGreenback commented on GitHub (Jul 29, 2020):
https://stackoverflow.com/questions/55812960/ioerr-10-message-system-data-sqlite-sqliteexception-0x800007ff-disk-i-o
hints it occurs during high IO operations - but doesn't give any solutions. It does point to multiple other references where this is occurring.
Has your disk got sufficient free space?
@joe-poff commented on GitHub (Aug 10, 2020):
I had the same issue with the same setup:
System:
OS: OMV
Virtualization: Docker
Jellyfin Version: 10.6.0-2
Installed Plugins: none
my /config was on a CIFS share, when I created a new container with the /config off of the CIFS share it worked. Having /config on a CIFS worked on jellyfin 10.5.5.
@mistwyrm commented on GitHub (Aug 10, 2020):
Interesting, mine was on a share too though I don't remember if it was a CIFS share.
I eventually solved the problem by manually creating the new database and then running Jellyfin. The database Jellyfin was creating seemed to be corrupted for some reason
@vtzompov commented on GitHub (Aug 30, 2020):
Getting same issue:
Directly running on Windows 7 64 bit.
Worked for 1 day OK. No changes, PC put to sleep, after wake up, got "jellyfin stopped working...." And since it will not start.
@BaronGreenback commented on GitHub (Aug 30, 2020):
Suspect there is a lock file left over in the database folder.
@vtzompov commented on GitHub (Aug 30, 2020):
what's the C:\ProgramData\Jellyfin\Server\data\jellyfin.db-shm file? After removing it now it's starting again.
@BaronGreenback commented on GitHub (Aug 30, 2020):
Taken from https://stackoverflow.com/questions/7778723/what-are-the-db-shm-and-db-wal-extensions-in-sqlite-databases
As per the SQLite docs, the DB-SHM file is a Shared Memory file, only present when SQLite it running in WAL (Write-Ahead Log) mode. This is because in WAL mode, db connections sharing the same db file must all update the same memory location used as index for the WAL file, to prevent conflicts.
As for WAL file, as hinted above, it is a write log/journal, useful for commits/rollback purposes. If the DB is not running, it is perfectly OK to delete this file, and in fact it would be automatically deleted when restarting the DB if one exists (since it's only useful when the DB is actively writing/committing data).
@stale[bot] commented on GitHub (Dec 28, 2020):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.
@meulop commented on GitHub (Jan 15, 2021):
I also had this issue, and the underlying cause was having /config stored on a mergerfs filesystem with cache.files=off (or direct_io set) in the mount options - having this set means the filesystem doesn't support mmap-ed files
@pciavald commented on GitHub (Jan 28, 2021):
i'm having this issue too now, data is stored on a LVM volume on ext4
EDIT: issue was that filesystem had gone to a read-only state
@Wastus commented on GitHub (Mar 24, 2021):
I was having the same issue as @meulop had. Seeing this thread, maybe it would be worthwhile to integrate this somehow into a troubleshooting section.
@Gopikrishna19 commented on GitHub (Jun 7, 2021):
tagging #6129 as the problem still exists. I also use OMV with NFS mounts, and getting the same Disk IO error
@Kotarou0 commented on GitHub (Aug 10, 2021):
I had the same problem for almost 2 weeks. I solved it by freeing some space in my disk.
Thanks @BaronGreenback.
@ceesios commented on GitHub (Jan 31, 2022):
I've worked around this by mounting the nfs share on the host and referring to the local path in docker.
Would be nice to see external database support.
@std4453 commented on GitHub (Feb 14, 2022):
Met this case all of a sudden with (seemingly) no obvious trigger event.
A restart did my case, all disks are functional and not full.
Logs directly before the first error:
@maxs98 commented on GitHub (Feb 17, 2022):
2022-02-17T14:24:34.008270234Z [22:24:34] [FTL] [1] Main: Error while starting server.
2022-02-17T14:24:34.008304089Z IOError: SQLitePCL.pretty.SQLiteException: disk I/O error
2022-02-17T14:24:34.008323518Z at SQLitePCL.pretty.SQLiteException.Throw(Int32 rc, Int32 extended, String msg)
2022-02-17T14:24:34.008338089Z at SQLitePCL.pretty.SQLiteException.CheckOk(sqlite3 db, Int32 rc)
2022-02-17T14:24:34.008342868Z at SQLitePCL.pretty.SQLiteException.CheckOk(sqlite3_stmt stmt, Int32 rc)
2022-02-17T14:24:34.008347406Z at SQLitePCL.pretty.StatementImpl.MoveNext()
2022-02-17T14:24:34.008351896Z at SQLitePCL.pretty.DatabaseConnection.Execute(IDatabaseConnection This, String sql)
2022-02-17T14:24:34.008356524Z at Emby.Server.Implementations.Data.BaseSqliteRepository.GetConnection(Boolean _)
2022-02-17T14:24:34.008361172Z at Emby.Server.Implementations.Data.SqliteItemRepository.Initialize(SqliteUserDataRepository userDataRepo, IUserManager userManager)
2022-02-17T14:24:34.008366044Z at Emby.Server.Implementations.ApplicationHost.InitializeServices()
2022-02-17T14:24:34.008385745Z at Jellyfin.Server.Program.StartApp(StartupOptions options)
2022-02-17T14:24:34.011730793Z [22:24:34] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing CoreAppHost
2022-02-17T14:24:34.011763778Z [22:24:34] [INF] [2] Main: Received a SIGTERM signal, shutting down
2022-02-17T14:24:34.371171993Z [22:24:34] [INF] [1] Main: Jellyfin version: 10.7.7
2022-02-17T14:24:34.377555050Z [22:24:34] [INF] [1] Main: Environment Variables: ["[JELLYFIN_CACHE_DIR, /config/cache]", "[JELLYFIN_DATA_DIR, /config/data]", "[JELLYFIN_CONFIG_DIR, /config]", "[JELLYFIN_PublishedServerUrl, 10.10.10.197]", "[JELLYFIN_LOG_DIR, /config/log]"]
2022-02-17T14:24:34.377637940Z [22:24:34] [INF] [1] Main: Arguments: ["/usr/lib/jellyfin/bin/jellyfin.dll", "--ffmpeg=/usr/lib/jellyfin-ffmpeg/ffmpeg", "--webdir=/usr/share/jellyfin/web"]
2022-02-17T14:24:34.378329037Z [22:24:34] [INF] [1] Main: Operating system: Linux
2022-02-17T14:24:34.379572648Z [22:24:34] [INF] [1] Main: Architecture: X64
2022-02-17T14:24:34.379597361Z [22:24:34] [INF] [1] Main: 64-Bit Process: True
2022-02-17T14:24:34.379603208Z [22:24:34] [INF] [1] Main: User Interactive: True
2022-02-17T14:24:34.379607647Z [22:24:34] [INF] [1] Main: Processor count: 4
2022-02-17T14:24:34.379611987Z [22:24:34] [INF] [1] Main: Program data path: /config/data
2022-02-17T14:24:34.379617758Z [22:24:34] [INF] [1] Main: Web resources path: /usr/share/jellyfin/web
2022-02-17T14:24:34.379622372Z [22:24:34] [INF] [1] Main: Application directory: /usr/lib/jellyfin/bin/
2022-02-17T14:24:34.513296639Z [22:24:34] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: /config/cache
2022-02-17T14:24:34.544942823Z [22:24:34] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN addresses : [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
2022-02-17T14:24:34.544971789Z [22:24:34] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions : []
2022-02-17T14:24:34.545563411Z [22:24:34] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using LAN addresses: [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
2022-02-17T14:24:34.551634873Z [22:24:34] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind addresses: []
2022-02-17T14:24:34.551661381Z [22:24:34] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind exclusions: []
2022-02-17T14:24:34.566762756Z [22:24:34] [INF] [1] Emby.Server.Implementations.ApplicationHost: Loading assemblies
@tyokyo320 commented on GitHub (Mar 18, 2022):
I had the same problem. I solved the problem by deleting the config file under
/library@RobioEpo commented on GitHub (Apr 17, 2022):
@tyokyo320 where is the library at and which config is it?
@insomniacdoll commented on GitHub (Jul 8, 2022):
it works!
mount options:
allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs@Y0ngg4n commented on GitHub (Aug 4, 2022):
I have the same issue on an NFS Share
@StoryHack commented on GitHub (Aug 10, 2022):
I get the same issue in my log. The media all sits on an nfs share, but the config data is on the same machine docker is running on, and has tons of free space.
@Y0ngg4n commented on GitHub (Aug 11, 2022):
@StoryHack exact same setup
@n8jadams commented on GitHub (Jun 20, 2023):
I was mounting
library.dbandlibrary.db-journalfrom a different path in my Dockerized Jellyfin server setup.I ran into this error and adjusting permissions fixed it for me.
chmod 644'ing thelibrary.dbandlibrary.db-journalfiles in my case.@ghost commented on GitHub (Jun 25, 2023):
I had this error on Windows and I fixed it by moving all of the DB files out, and moving each one (jellyfin.db, then library.db, then infuse-sync.db) and replacing the old ones and somehow that did the trick
@xinmans commented on GitHub (Aug 14, 2023):
i change cifs pvc to longhorn pvc to fix it.
@srcrist commented on GitHub (Oct 19, 2023):
Closing this issue as it does not reference a Jellyfin bug. This is a general I/O error thrown by the DB handler when it cannot access the DB on the storage correctly. The actual underlying causes are many. If anyone still experiences this, please visit our support communities on the forums or our Matrix/Discord server with help troubleshooting the underlying issue.