Es sieht so aus, als ob es hier einen Speicherüberlauf bei der mariadb gibt:
pr 23 13:51:57 fhempi3 kernel: [1300236.372612] Out of memory: Killed process 20666 (mariadbd) total-vm:540068kB, anon-rss:229984kB, file-rss:0kB, shmem-rss:0kB, UID:109 pgtables:318kB oom_score_adj:0
Apr 23 13:52:01 fhempi3 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr 23 13:52:01 fhempi3 epgd: SQL-Error in 'execute(stmt_execute)' - Lost connection to MySQL server during query (2013) 'Lost connection to MySQL server during query' [select actor_id, episode_id, inssp, lfn, media_content, media_height, media_rating, media_type, media_url, media_width, season_number, series_id, updsp from series_media where actor_id = ? and episode_id = ? and lfn = ? and media_type = ? and season_number = ? and series_id = ?;]
Apr 23 13:52:01 fhempi3 systemd[1]: mariadb.service: Failed with result 'signal'.
Apr 23 13:52:01 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions
Apr 23 13:52:02 fhempi3 systemd[1]: mariadb.service: Consumed 12min 38.694s CPU time.
Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'find()' - Lost connection to MySQL server during query (2013)
Apr 23 13:52:02 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions
Apr 23 13:52:02 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(15839)
Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'store()'
Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'store()'
Display More
Die Folge ist, dass der Server abgeschossen wird und dann neu gestartet wird.
Das ganze scheint nach dem Aufruf von "mergeepg" zu passieren.
pr 23 13:57:12 fhempi3 epgd: Calling sd_notify(STATUS=Ready)
Apr 23 13:57:12 fhempi3 epgd: Starting 'update' episode download ...
Apr 23 13:57:13 fhempi3 epgd: Connected to eplist server at 'www.eplists.de'
Apr 23 13:57:13 fhempi3 epgd: Requesting episode changes of last 121 minutes
Apr 23 13:57:33 fhempi3 epgd: Error: SVDRPCL: Timeout waiting server reply 'www.eplists.de'
Apr 23 13:57:33 fhempi3 epgd: Received 0 episode files
Apr 23 13:57:33 fhempi3 epgd: Update episodes.combinedcomp
Apr 23 13:57:33 fhempi3 epgd: Starting episode lookup ...
Apr 23 13:57:41 fhempi3 epghttpd: SQL-Error in 'SELECT SYSDATE();' - MySQL server has gone away (2006)
Apr 23 13:57:41 fhempi3 epghttpd: Fatal, lost connection to mysql server, aborting pending actions
Das mysql error.log zeigt Folgendes:
2023-04-23 14:00:20 0 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=20885, page number=0], should be [page id: space=20885, page number=262144]
2023-04-23 14:00:20 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-04-23 14:00:20 0 [Note] InnoDB: Rolled back recovered transaction 90867803
2023-04-23 14:00:20 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2023-04-23 14:00:20 0 [Note] Server socket created on IP: '192.168.178.28'.
2023-04-23 14:00:20 0 [Note] Reading of all Master_info entries succeeded
2023-04-23 14:00:20 0 [Note] Added new Master_info '' to hash table
2023-04-23 14:00:20 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.5.15-MariaDB-0+deb11u1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Raspbian 11
2023-04-23 14:00:24 0 [Note] InnoDB: Buffer pool(s) load completed at 230423 14:00:24
2023-04-23 14:01:53 6 [Note] InnoDB: Resetting invalid page [page id: space=20885, page number=262144] type 8 to 9 when flushing.
2023-04-23 14:01:55 6 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=20885, page number=0], should be [page id: space=20885, page number=262144]
2023-04-23 14:01:55 0x607cdf80 InnoDB: Assertion failure in file ./storage/innobase/btr/btr0cur.cc line 7391
InnoDB: Failing assertion: block != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
230423 14:01:55 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.5.15-MariaDB-0+deb11u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=3
max_threads=153
thread_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 351836 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x377c470
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x607cd90c thread_stack 0x4ac00
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x3bc2ed0): insert into series_media set actor_id = ?, episode_id = ?, inssp = ?, lfn = ?, media_content = ?, media_height = ?, media_rating = ?, media_type = ?, media_url = ?, media_width = ?, season_number = ?, series_id = ?, updsp = ?
Connection ID (thread ID): 6
Status: NOT_KILLED
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 6858 6858 processes
Max open files 32768 32768 files
Max locked memory 8388608 8388608 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 6858 6858 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core
Display More
Ich meine, dass ich InnoDB für den Betrieb von Netxcloud benötige, welches auch auf die mariadb zugreift, in die auch die epg-Daten geschrieben werden.
. In den vdr-Einstellungen stand DiSEqC auf 0 und nicht auf 1. Jetzt kommt auch wieder was an.
