pnp repeatedly detecting drives that don't exist ....

[colinjones]

Second or third time this has happened to my core in the last couple of months resulting in a full rebuild. Hoping to avoid that this time!

Suddenly the pnp scripts think they have detected a drive, initially the IP is the internal address of the core, but the name is clearly pulled from some text file somewhere. No matter what you say to do with it, from then on one after another comes up with different names - the names are something to do with LMCE, presumably coming from a text file that contains strings for the UI maybe? Looks like the pnp script has spun off into outer space and I have no idea what caused it.

I had just recently followed Thom's instructions to drop the pluto_media database so I could start afresh, but this is the first time I had tried this, the previous times this happened had the exact same symptoms but I hadn't just dropped the db...

Any thoughts on what might be happening, and what I might be able to do to stop it other than killing the pnp scripts.... tried a reboot and reload... nope..

[tschak909]

try purging the pnpqueue table.

Code: [Select]

DELETE FROM PnpQueue;

-Thom

[colinjones]

Thom

Chatted to possy, and by the time we got to look at it, it had mysteriously stopped happening. Checked the pnpqueue table based on your suggestion and predictably it was empty.

As I say, this isn't the first time the exact same thing has happened to me and the previous time it was a completely different build. Looks like the StorageDevices_SambaRadar script got stuck in a hole, with a bunch of error text messages it was parsing trying to scan as networks, and thus failing. Would love to know whether these were actually queued in the pnpqueue table. But I suspect not - I think it was still looping through the script and processing script errors as if they were networks. I don't have any reason to believe that something else had queued junk data into the pnpqueue as they seemed to be errors internal to that script. For my further understanding:

1) what is responsible for populating the pnp queue?
2) what is responsible for reading the pnpqueue and then calling StorageDevices_SambaRadar with that info?
3) StorageDevices_SambaRadar seems to be self contained in terms of scanning the network based on a subnet passed to it, so is it really related to the pnpqueue at all?

Coming back to that script - the stuff above are just symptoms. The cause seems to be that when the script is called and passed a subnet, in the form 192.168.80.1/24, when the issue happened it was passed 192.168.80.1/ which caused an unhandled error, and the error messages that resulted are then parsed as if they are devices on the network and the core tries to add them. Working backwards through the scripts network_parameters seems to be the one that passes the dodgy network, maybe from a semi-failed SQL query? (particularly, the IntNetmask seems not to be set correctly)

In any case, I guess there is room for improvement in both the radar's error handling and tracking down a possible bug in the previous script... but I'm no where near confident enough to attack that!