Journalctl being flooded

wqwd · 4 January 2024 13:46

Hello
I am trying to find more info on how to clean up some errors i am seeing in journalctl. As the below entries repeated flood the log. Any help would be appreciated as I am not sure where to start. google suggest they cloud be related to retroarch but I did not install it.
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 04 08:18:39 osmc mediacenter[689]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)

sam_nazarko · 4 January 2024 15:15

It would help to see some logs and know what device you are running OSMC on.

wqwd · 4 January 2024 16:26

Hello @sam_nazarko
I am running on a RPi4. what log files should I pull? looking at the kodi.log i am not seeing much from around the same time frame as the snip i posted above.
2024-01-04 07:43:33.413 T:689 info : Loading skin file: /home/osmc/.kodi/addons/screensaver.picture.slideshow/resources/skins/default/1080i/script-python-slideshow.xml, load type: LOAD_ON_GUI_INIT
2024-01-04 08:10:54.263 T:978 info : WEATHER: Downloading weather
2024-01-04 08:40:56.465 T:978 info : WEATHER: Downloading weather
2024-01-04 09:10:58.580 T:977 info : WEATHER: Downloading weather
2024-01-04 09:41:00.796 T:978 info : WEATHER: Downloading weather
2024-01-04 09:50:37.645 T:715 info : CActiveAESink::OpenSink - initialize sink
2024-01-04 09:50:37.645 T:715 info : CAESinkALSA::Initialize - Attempting to open device “@”
2024-01-04 09:50:37.650 T:715 info : CAESinkALSA::Initialize - Opened device “sysdefault”
2024-01-04 09:50:37.650 T:715 info : CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
2024-01-04 09:50:37.651 T:715 info : CAESinkALSA::InitializeHW - Using data format AE_FMT_S24NE3
2024-01-04 09:51:08.339 T:689 info : Loading skin file: MyPVRGuide.xml, load type: KEEP_IN_MEMORY
2024-01-04 09:51:12.356 T:689 info : Loading skin file: DialogPVRInfo.xml, load type: LOAD_EVERY_TIME
2024-01-04 09:51:13.809 T:689 info : VideoPlayer::OpenFile: pvr://channels/tv/All%20channels/1@pvr.nextpvr_7200.pvr
2024-01-04 09:51:13.811 T:1421 info : Creating InputStream
2024-01-04 09:51:13.812 T:1421 error : AddOnLog: pvr.nextpvr: Unknown live streaming state 0 0 1
2024-01-04 09:51:13.812 T:1421 info : AddOnLog: pvr.nextpvr: Calling Open(http://10.10.10.16:8866/live?channeloid=7200&client=fb4e1e6fb7d2441bb3f7d9c0e3186a85&sid=fb4e1e6fb7d2441bb3f7d9c0e3186a85) on tsb!

Tom_Doyle · 4 January 2024 17:52

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

enable debug logging at settings->system->logging
reboot the OSMC device twice(!)
reproduce the issue
upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

wqwd · 7 January 2024 15:46

This is the URL that the tool posted.
https://paste.osmc.tv/upipipojox

the last time stamp was would be around here.
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: 1 similar GL_INVALID_VALUE errors
Jan 07 10:43:56 osmc mediacenter[764]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)

sam_nazarko · 12 January 2024 10:18

Sorry for the delay in getting back to you

This one surprised me. Usually when we see errors like this, it’s because of a user installing an incompatible version of MESA (usually brought in from an X11 dependency).

That was addressed by using ‘Provides’ in our Debian packages recently however.

Not sure exactly where those errors come from but it will likely be a binary add-on that uses graphics. I’m assuming it does not occur on a fresh install.

olwaldi · 6 February 2024 16:55

I do encounter the same problem - flooded journalctl with

Feb 06 15:22:47 imurr9 mediacenter[27498]: ExifParse - Nonfatal Error : Illegal exif or interop ofset directory link 0 0 ....
ExifParse - NonfMesa: error: GL_INVALID_VALUE in glVertexAttribPointerARB(idx)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glVertexAttribPointerARB(idx)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glDisableVertexAttribArray(index)
Feb 06 15:22:47 imurr9 mediacenter[27498]: Mesa: error: GL_INVALID_VALUE in glVertexAttribPointerARB(idx)

To me it appears as if watching jpeg pictures seems to trigger those tremendous amount of errors. I’m using OSMC/kodi on a raspi 4 / 4GB with 4k GUI resolution to get high resolution jpegs.

I do see similar errors from ExifParse when using kodi 20.3 on a linux tumbleweed laptop.

But despite those ExifParse errors the exif data itself looks fine. I’ve verified this using exiftool (OK, it reports one minor flaw “[minor] Fixed incorrect URI for xmlns:MicrosoftPhoto”). But that should not trigger thousands of Mesa errors.

And it doesn’t. I’ve just started some video from the ARDundZDF plugin. And it raised some of those errors. Thus those Mesa errors seem to occur during playback of (any?) video, and it becomes more and more the longer the video runs.

Regarding fresh install: I’ve setup my new raspi 4 some months ago from scratch (OSMC image OSMC_TGT_rbp4_20230831.img.gz). But I’ve re-used my .kodi subfolder from my old raspi 3B.

As far as I know OSMC uses a 64bit environment - from uname -a

Linux imurr9 5.15.92-1-osmc #1 SMP PREEMPT Tue Jul 25 00:03:42 UTC 2023 aarch64 GNU/Linux

But kodi.log says

2024-02-06 17:42:04.319 T:30497    info <general>: Kodi compiled 2023-08-15 by GCC 10.2.1 for Linux ARM (Thumb) 32-bit version 5.15.92 (331612)

I will ask the same question to the plugin developer of ARDundZDF.

Regards, Michael

olwaldi · 7 February 2024 06:48

I could identify the root cause of the tremendous amount of Mesa errors!

It is related with kodi’s picture environment used to view jpeg pictures. When a high resolution jpeg is displayed, one can zoom by pressing the number keys 0…9. And exactly during the zoom process the Mesa errors occur. The zoom processs is visualized till the requested zoom level is reached. And then the Mesa errors stop.

[Side note: The used movie plugins (e.g. ARDundZDF) do not trigger those Mesa errors (OK, sometimes a very small amount of them). Just for completeness, if I start a movie I see always this error

Feb 07 07:33:05 imurr9 kernel: bcm2835-codec bcm2835-codec: Failed setting ctrl 00990a67, ret 3

]

It would be great if that Mesa problem can be fixed.

Regards, Michael

sam_nazarko · 7 February 2024 07:18

Doesn’t look like a MESA issue but actually a kernel bug
So hopefully next kernel solves this issue

Cheers

Sam

olwaldi · 7 February 2024 07:36

Thanks for your fast reply. But that’s a second (minor) issue. I try very hard to avoid mixing different issues - but it’s not that easy:-)

My main problem within this thread is the tremendous amount of Mesa error messages being triggered during jpeg zooming.

Regards, Michael

sam_nazarko · 7 February 2024 07:39

I think that is the same problem…

olwaldi · 14 March 2025 16:50

My problem seems to be solved, but without a new kernel. Some weeks ago I tweaked /etc/systemd/journald.conf to contain
‘’’
Storage=volatile
…
MaxLevelStore=notice
MaxLevelSyslog=notice
‘’’
Just today I‘ve by accident zoomed on jpegs using current osmc - and no flooding of journal any more. My main interest of my change was to avoid storing journal data on SD card, but that sideeffect is highly welcome.

Maybe helpful for others, Michael

sam_nazarko · 16 March 2025 03:28

We have not had a persistent journal for a long time, so the setting should not need to be adjusted to avoid unnecessary writes.

olwaldi · 16 March 2025 07:00

But I had to modify /etc/systemd/journald.conf. The one delivered by osmc had all entries commented, i.e. with a leading hash. Originally I did believe that comments within journald.conf might be double hash since some entries had ## in front. Maybe that’s a sideeffect from apt updates? Anyhow I had to set

Storage=volatile

replacing

#Storage=auto

i.e. the auto setting was originally commented out. Additionall I enforced notice

MaxLevelStore=notice
MaxLevelSyslog=notice

Also here both entries originally were

#MaxLevelStore=debug
#MaxLevelSyslog=debug

i.e. commented out (and uncommenting would even increase the amount of messages).

sam_nazarko · 16 March 2025 10:15

When did you install your system?

For a long time persistent journaling has to be explicitly enabled

Sam

olwaldi · 16 March 2025 10:32

Around November 2023. Regularly I update to the current osmc version. But I have installed other tools, too, e.g. weewx. Of course I can’t tell if those installations might have tweaked journald.conf.

sam_nazarko · 22 March 2025 18:38

See

If /var/log/journal exists, you will have persistence.
You can delete this directory to disable it as per the commit above. There should not be a need to touch systemd.

Cheers

Sam

olwaldi · 23 March 2025 07:33

Thanks for your info.

I’ve checked my notes - I did a fresh install on my new raspi 4 using OSMC_TGT_rbp4_20230831.img.gz But additionally I did an automatic update of all configuration files (including journald.conf) changed on my old pi3. For that purpose I’ve created a big shell script (~1500 lines) to modify a vanilla osmc installation into one with all my changes (e.g. automatic setup of NFS or account creation). Exactly this installation was my first “real world” use of my script. Maybe as a side effect journald.conf was affected (I did modifiy it on my pi3 in 2021).

Anyhow now my journal protocols all things as intended. W.r.t. osmc most important was to set the MaxLevel* items to “notice” to avoid error messages during zooming of jpegs.

sam_nazarko · 23 March 2025 12:02

I would recommend using newer images if possible.

olwaldi · 23 March 2025 13:57

I do regular updates when announced, i.e. now I’m using the most current osmc release 2025-02. Is there any (big) difference between using a fresh install or regular updates? Of course I can imagine that maybe some config files might differ, but Debian’s apt mechanism ensures correct dependencies/versions. And my raspi is working fine:-)