I guess since it returned with the number of zones it shows that bind is running fine.
Yep, rndc looks good here–we weren’t trying to figure out if BIND was running, since I think we’d already established that it was, we were trying to figure out if rndc worked correctly (Webmin uses it for quite a few things).
The other bit I mentioned is probably the culprit in your case.
Find the named.pid file using locate:
It’s probably within a chroot, like so:
And so, the path according to Webmin (found in the BIND Module Config) will be:
Since Webmin should already know about the chroot.
and will not a “remove & re-install” of webmin & virtualmin just pickup all the domains and server packages on it’s own???
Nope. No way it could. The domains will continue to run–because Virtualmin merely configures them (mail might stop delivering, however, since the procmail configs for domains are stored in the Virtualmin configuration directory), but the Virtualmin data about them will be lost if you remove Virtualmin. Virtualmin isn’t like Webmin, where the vast majority of “work” you do happens in the configuration files of your software. It has it’s own quite large set of configuration data that it keeps up with, as it must to keep up with your domains, mail settings, templates, etc. for you.
If you have backups of the Webmin configuration directories, then you can restore the data easily (it’s small–no reason not to keep a separate backup of this data). But you’d probably also be restoring the configuration that is wrong in the case of your BIND problem!
This is merely a configuration problem. Nothing major, nothing difficult to fix, certainly nothing that requires doing drastic measures like restoring from backups or reinstalling. We just need to figure out which path Webmin has wrong, and correct it.