Minimserver 0.72 crashes nightly on ReadyNas Ultra+

[rweten]

Simon

Just a further update on this. I did decide to do another clean reinstall. Since then, I've had no issues and Minimserver has now been up for several days without falling over.

I did also raise an issue on the ReadyNAS forum but have not had any joy in terms of any feedback that might help identify a service that's knocking over Minimserver.

I have reviewed the services running on the ReadyNAS and took down FTP and NFS as they aren't really needed.

I will post again if the problem recurs.

R

[Skywatcher]

I installed minimserver about half a year ago on my ReadyNas Ultra2 and had this same problem and ended up uninstalling it.
I decided to try it again now since it's really the server that has everything done in the way I like it. I installed the latest version of the add-on via frontview and sure enough, when I got up in the morning minimserver would be down.
I decided to try uninstalling the add-on and installing the linux x86 version manually via shell. Did it a few days ago, minimserver has been rock stable ever since.

I also had this precise same problem with subsonic (a streamer software) that I also have installed in the NAS. The plugin installed via frontview would crash nightly and the manually installed version has been running for months without problems.

I think there is some kind of plug-in process cleaning operation running in the ReadyNas that's been killing the wrong processes or some other plugin (I saw the references to ReadyNas Vault) that interferes with other plugins.

Unfortunately the solutions that people have been finding to this problem all appear to be different, even if they all seem to exempt minimserver itself from any blame.

I, for one, am happy that I got it working, so donation has gone through. Well done Simon, do keep up the excellent work.

Cheers,

[simoncn]

(12-01-2014 15:38)Skywatcher Wrote:  I installed minimserver about half a year ago on my ReadyNas Ultra2 and had this same problem and ended up uninstalling it.
I decided to try it again now since it's really the server that has everything done in the way I like it. I installed the latest version of the add-on via frontview and sure enough, when I got up in the morning minimserver would be down.
I decided to try uninstalling the add-on and installing the linux x86 version manually via shell. Did it a few days ago, minimserver has been rock stable ever since.

I also had this precise same problem with subsonic (a streamer software) that I also have installed in the NAS. The plugin installed via frontview would crash nightly and the manually installed version has been running for months without problems.

I think there is some kind of plug-in process cleaning operation running in the ReadyNas that's been killing the wrong processes or some other plugin (I saw the references to ReadyNas Vault) that interferes with other plugins.

Unfortunately the solutions that people have been finding to this problem all appear to be different, even if they all seem to exempt minimserver itself from any blame.

I, for one, am happy that I got it working, so donation has gone through. Well done Simon, do keep up the excellent work.

Cheers,

Thanks for this information (and the donation!)

Your explanation for the cause of this problem seems plausible. Perhaps there is some information in the ReadyNAS logs (not the MinimServer log) that would indicate what is happening on the ReadyNAS at the time that MinimServer is being killed.

[rweten]

Hi Simon, I am still having some problems losing the server overnight. I had not reported earlier because I had seen some new pattern and I wanted to see if it would repeat.

And it does. So here's the behaviour.

1. I uninstall MinimWatch and MinimServer, and reinstall from fresh. As long as this fresh install is left alone, the server stays up, day after day, night after night
2. I get new patch updates for MinimWatch and Server, and install them. Successful install messages, all is OK that evening
3. Next morning the server will be down. Blue/grey notification tray icon. No server showing in Kinsky. Kinsky can't play any tracks from the server. The minimum solution is to go into ReadyNAS frontview, stop the server, then restart it. Server then rescans for c. 20 mins and all is well again.
4. From then on, the server will go down every night. Regular as clockwork. The only solution is a complete uninstall (retaining the information files) then a fresh reinstall with a new download from the site.

I have now seen this same behaviour over at least three cycles of new software updates.

I'm scratching my head a bit. Seems very weird to me. Does this give you any new clues?

Of course, happy to collect log files again if you want me to - just let me know.

Richard

PS Apart from this, the product works very well. I'm delighted with the flexibility and love my ability to customise my browing options. Also it's a lot faster than my Twonky server, both in rescanning behaviour, and in response time to the control point (particularly for large requests e.g. list all Album Artists).

[simoncn]

(05-02-2014 21:53)rweten Wrote:  Hi Simon, I am still having some problems losing the server overnight. I had not reported earlier because I had seen some new pattern and I wanted to see if it would repeat.

And it does. So here's the behaviour.

1. In uninstall MinimWatch and MinimServer, and reinstall from fresh. As long as this fresh install is left alone, the server stays up, day after day, night after night
2. I get a new patch update for MinimWatch and Server, and install them. Successful install messages, all is OK that evening
3. Next morning the server will be down. Blue/grey notification tray icon. No server showing in Kinsky. Kinsky can't play any tracks from the server. The minimum solution is to go into ReadyNAS frontview, stop the server, then restart it. Server then rescans for c. 20 mins and all is well again.
4. From then on, the server will go down every night. Regular as clockwork. The only solution is a complete uninstall (retaining the information files) then a fresh reinstall with a new download from the site.

I have now seen this same behaviour over at least three cycles of new software updates.

I'm scratching my head a bit. Seems very weird to me. Does this give you any new clues?

Of course, happy to collect log files again if you want me to - just let me know.

Richard

PS Apart from this, the product works very well. I'm delighted with the flexibility and love my ability to customise my browing options. Also it's a lot faster than my Twonky server, both in rescanning behaviour, and in response time to the control point (particularly for large requests e.g. list all Album Artists).

Please set the MinimServer logging level to Debug and save the minimserver.log file that was written to the ReadyNAS backup share after the MinimServer process was killed. It is important to copy this file to a different location before MinimServer is restarted.

If you look in the ReadyNAS system logs, do you see any other activity at the time that MinimServer went down? This might help to identify which other process or service is killing the MinimServer process.

I am running the latest update on my ReadyNAS Duo v2 and I have never seen this problem.

[rweten]

Morning Simon.

I've checked the logs. It's not clear from the debug log exactly what time the server goes down, but I'm pretty sure it's early morning.

Checking the ReadyNAS system log file, I can see the following:

Feb 3 06:25:26 NASNV syslogd 1.5.0#6: restart.
Feb 3 23:04:30 NASNV kernel: Uncached vma cff43aa8 (addr 40020000 flags 080000d5 phy 06a68000) from pid 851
Feb 3 23:04:30 NASNV kernel: Uncached vma cff43a50 (addr 40021000 flags 080000d5 phy 06a68000) from pid 851
Feb 4 06:25:27 NASNV syslogd 1.5.0#6: restart.
Feb 4 21:36:18 NASNV kernel: Uncached vma c5cb6268 (addr 40020000 flags 080000d5 phy 04028000) from pid 17440
Feb 4 21:36:18 NASNV kernel: Uncached vma c3768160 (addr 40021000 flags 080000d5 phy 04028000) from pid 17440
Feb 5 06:25:23 NASNV syslogd 1.5.0#6: restart.
Feb 5 20:27:58 NASNV kernel: Uncached vma cef9bc60 (addr 40020000 flags 080000d5 phy 071d4000) from pid 25600
Feb 5 20:27:58 NASNV kernel: Uncached vma cef9bdc0 (addr 40021000 flags 080000d5 phy 071d4000) from pid 25600
Feb 6 06:25:24 NASNV syslogd 1.5.0#6: restart.
Feb 6 08:11:45 NASNV kernel: program smartctl.org is using a deprecated SCSI ioctl, please convert it to SG_IO

You will be more knowledgeable than me, but I'd suspect that restart thing at 06:25 is knocking Minimserver over?

Richard

[simoncn]

(06-02-2014 09:53)rweten Wrote:  Morning Simon.

I've checked the logs. It's not clear from the debug log exactly what time the server goes down, but I'm pretty sure it's early morning.

Checking the ReadyNAS system log file, I can see the following:

Feb 3 06:25:26 NASNV syslogd 1.5.0#6: restart.
Feb 3 23:04:30 NASNV kernel: Uncached vma cff43aa8 (addr 40020000 flags 080000d5 phy 06a68000) from pid 851
Feb 3 23:04:30 NASNV kernel: Uncached vma cff43a50 (addr 40021000 flags 080000d5 phy 06a68000) from pid 851
Feb 4 06:25:27 NASNV syslogd 1.5.0#6: restart.
Feb 4 21:36:18 NASNV kernel: Uncached vma c5cb6268 (addr 40020000 flags 080000d5 phy 04028000) from pid 17440
Feb 4 21:36:18 NASNV kernel: Uncached vma c3768160 (addr 40021000 flags 080000d5 phy 04028000) from pid 17440
Feb 5 06:25:23 NASNV syslogd 1.5.0#6: restart.
Feb 5 20:27:58 NASNV kernel: Uncached vma cef9bc60 (addr 40020000 flags 080000d5 phy 071d4000) from pid 25600
Feb 5 20:27:58 NASNV kernel: Uncached vma cef9bdc0 (addr 40021000 flags 080000d5 phy 071d4000) from pid 25600
Feb 6 06:25:24 NASNV syslogd 1.5.0#6: restart.
Feb 6 08:11:45 NASNV kernel: program smartctl.org is using a deprecated SCSI ioctl, please convert it to SG_IO

You will be more knowledgeable than me, but I'd suspect that restart thing at 06:25 is knocking Minimserver over?

Richard

I recall that from a previous MinimServer log that you (or someone else) sent, the MinimServer process was being killed at about 6.30 am.

From some web searching, this appears to be the time that the ReadyNAS runs the scripts in the /etc/cron.daily folder.

Please login via SSH and list the contents of the /etc/cron.daily folder. Alternatively, you can download the log files using Frontview and get this information from the etc-ls.log file.

[rweten]

Thanks Simon

I've downloaded the log files and uploaded them to your server. There's a lot in the etc.ls file (30k or so). I sent the full set of log files to your server on the basis you might want to look into other things too.

Appreciate your help and patience with this one, but it is quite frustrating. What is bizarre is this thing about fresh installs fixing it, then new patches screwing it up again!

R

[simoncn]

(06-02-2014 14:02)rweten Wrote:  Thanks Simon

I've downloaded the log files and uploaded them to your server. There's a lot in the etc.ls file (30k or so). I sent the full set of log files to your server on the basis you might want to look into other things too.

Appreciate your help and patience with this one, but it is quite frustrating. What is bizarre is this thing about fresh installs fixing it, then new patches screwing it up again!

R

The /etc/cron.d folder contains a file named frontview-backup. Are you running a daily backup at approximately 6.25 am? If so, please try disabling this to see if it fixes the problem.

I also saw that the contents of the /etc/frontview/addons/bin/MINIMSERVER/data directory were modified at 6:25 am this morning. Perhaps the daily backup is finding a file in this folder that is in use by the MinimServer process, and is killing the process so that it can back up this file.

The solution to this would be to exclude the /etc/frontview/addons/bin/MINIMSERVER/data directory from the daily backups.

[rweten]

I'll see what I can find. I didn't think I was running any daily back-ups, though.

Thanks for the insights; I'll see if this produces a fix.

R