Virtual servers shown as IDs in the select box. Backup fails.

Hello all,

I have 77 virtual servers on my server, and 4 of them only show their ID on the virtualmin select options.
The map.dom shows:

=139361315343882 14533898921115 142707176235109 141236246495481

How can I fix this problem? I don't know what domains are these IDs.
Is there a virtual server creation log, where I could see what those domains are?

I know the domains that are missing from the list... what happens if edit the map.dom file and set the wrong domain name?

My system:

Operating system CentOS Linux 7.4.1708
Webmin version 1.872
Usermin version 1.734
Virtualmin version 6.02
Theme version Authentic Theme 19.07
Firewall version ConfigServer Security & Firewall 11.07
Kernel and CPU Linux 3.10.0-693.17.1.el7.x86_64 on x86_64

Please help , backup fails for this domains.

Thank you



Check the files under /etc/webmin/virtual-server/domains with those IDs to see what they contain.

Hi Jamie,

The four files are empty:

-rwx------   1 root root 2699 Apr  9 10:00 139229053454934
-rwx------   1 root root 2652 Apr  9 10:00 139229328358933
-rwx------   1 root root 2820 Apr  9 10:00 139359378716162
-rwx------   1 root root 2652 Apr  9 10:00 139361115040773
-rwx------   1 root root    0 Dec 17 01:10 139361315343882
-rwx------   1 root root 2544 Apr  9 10:00 139463214259836
-rwx------   1 root root 2714 Apr  9 10:00 139585159338382
-rwx------   1 root root 2674 Apr  9 10:00 140292140531556
-rwx------   1 root root 2673 Apr  9 10:00 1403713966108684
-rwx------   1 root root 2786 Apr  9 10:00 140933042968614
-rwx------   1 root root 2580 Apr  9 10:00 140933432676376
-rwx------   1 root root 2719 Apr  9 10:00 141100729530232
-rwx------   1 root root 3033 Apr  9 10:00 14114871221162
-rwx------   1 root root    0 Dec 17 01:10 141236246495481
-rwx------   1 root root 2608 Apr  9 10:00 141598090221763
-rwx------   1 root root 2648 Apr  9 10:00 141875146053284
-rwx------   1 root root    0 Dec 17 01:10 142707176235109
-rwx------   1 root root 2576 Apr  9 10:00 142772163844597
-rwx------   1 root root 2557 Apr  9 10:00 142772165744613
-rwx------   1 root root 2506 Apr  9 10:00 143679243515887
-rwx------   1 root root 2638 Apr  9 10:00 1441737317401
-rwx------   1 root root    0 Dec 17 01:10 14533898921115
-rwx------   1 root root 2984 Apr  9 10:00 1453915494127538

What can I do?

Just delete those files.

Hi Jamie,

Ok, I've moved the files to /tmp and restarted webmin. The IDs don't show on select box anymore. But the domains are not back. I have 4 domains missing from the list. The domains are working, but backups are not done and I can't manage them. What do I do now? Thanks

You can re-import the domains into Virtualmin at Add Servers -> Import Virtual Server.

I'm wondering why those files are empty though. Do you happen to know which action in Virtualmin could have caused this?

Thank you Jamie, I was able to reimport the domains. I don't know.. but looking at the empty files above, they were all updated at the same time, Dec 17 01:10. Thats when we run the backups... so I would assume that the cause is backup related.
I had some problems with the server that receives the backups, it was rebooting randomly. So maybe the remote server rebooted when server was doing a backup process? Does that make sense?

Thank you

Yeah, if the system rebooted just at the time those files were being written, it is possible that filesystem corruption could happen which could leave them empty.

Just a idea about this as I too have had the same issue before... its rare but it does happen.

My suggestion is VM make a backup copy before the backup for that domain starts then delete it after the backup was completed. This way should the backup fail because of a reboot the backup file can simply be renamed and no loss of domain info/features.

This is actually what happens for ALL files writes done by Webmin - only when a new file is completely written is it renamed over the old, so that a crash in the middle shouldn't leave you with an empty file. However, there's no guarantee that the underlying filesystem has done the right thing :-(