minimserver 2.2 update 247 crashed

[simoncn]

(15-04-2024 18:55)tarnkappe Wrote:  btw. the the first letter of the values for the property in the manual https://minimserver.com/ug-running.html#...%20logging are written in upper case. The web frontend only seems to accept a lower case "debug".

These instructions are for setting the logging level using the drop-down selection in the log window. In this context, Debug is correct.

If you read on a bit, you will see instructions for setting the .logLevel property using the console interface. I will update this to explain that this also applies to setting the .logLevel property using the configuration web page.

Running for a long time with 'debug' enabled will cause the minimserver.log file to get very large. The log window (if you use it) shows only the last 500 KB of log data. You can truncate the minimserver.log file at any time by using Synology File Station to open the MinimServer/appdata folder and delete the minimserver.log file.

[simoncn]

(15-04-2024 18:52)tarnkappe Wrote:  Do you know a command to list all opened files on synology similar to the linux command "lsof"?

The problem is unlikely to be caused by open files. It is more likely to be caused by the LUMIN app opening a large number of socket connections to MinimServer to read resource information from your MinimServer library. To list all open sockets, you can use this command:

netstat -a

[tarnkappe]

Hello Simon,

minimserver did stop again some days ago. I have the minimserver.log (debug mode) with 170 MB. I think there is not much to read from it regarding this issue.

If you are interested in the log file: How many MB from it do you need and how should I send it to you?

Unfortunately I did forget to run the netstat command. In the meanwhile the NAS has been restarted when updating the DSM.

[simoncn]

Please compress the log using zip or gzip and upload it to my FTP server. I will send you a PM with the server details.

[tarnkappe]

Hello Simon, I have uploaded the logs to the ftp server right now.

[simoncn]

Thanks for uploading these logs. They show that at 22:03:46 some other software started to download a very large number of artwork images using a very large number of concurrent HTTP network connections. At 22:04:15 MinimServer crashed because the Linux limit for the maximum number of concurrent open network connections had been exceeded.

I suspect that the other software that caused this was the LUMIN app. Can you confirm this?

[tarnkappe]

I do not really have an idea which other software this could be. I have to check the log file tomorrow if there is an IP address logged.

If the access came from the same tablet that is running the lumin app, it only can be Bubble UPnP app that I am using sometimes, I think.

[simoncn]

The requests that caused the crash came from the device with IP address 192.168.178.53.

I have seen this situation with the LUMIN app previously. If you had the LUMIN app running at the time the crash happened, I am almost certain that the LUMIN app caused the crash by opening too many network connections.

[tarnkappe]

.53 is the IP from the tablet that is running the lumin app. Besides lumin I have installed BubbleUPnP, Linn, Linn/Kazoo and Hifi-Cast. But I am only using lumin and sometimes BubbleUPnP.

I tried several times to reproduce the crash by freshly opening lumin and browsing the biggest upnp folders with many entries. But that did work always. After the first browsing the album art was cached locally anyway. Maybe the many connections are triggered in the background when lumin starts a rescanning of its index? Do you have a contact at lumin to analyse this in more detail? Or should I ask lumin about this issue?

Or might one of the other apps do something in the background automatically?

[stefano_mbp]

As I can read in your nas specs it has 2GB ram, couldn’t the issue be caused by a lack of ram?
I’m running Minimserver on a Intel Nuc8i3/16GB ram with Ubuntu 22.04 and the use of ram is stable around 4.9GB ram and my library is quite big, around 8TB