Virtualmin freezes on "Restoring Apache virtual host configuration"

I have been planning to renew my Virtualmin Pro license for a while now, I just haven't gotten around to it yet because I have been trying to make some infrastructure changes and switch Web hosting providers, thus the need for the current domain restore. I only have 23 virtual servers, and their total size is under 500 MB, and so since I am running on an SSD I didn't think the restore would take very long.

Here is the output from the given command:

It is indeed still stuck on "Restoring Apache virtual host configuration." What's worse is that this is the second virtual server being restored; the first went through this step without any problems, and that server was larger in terms of total file size than is the current server being restored. Thank you, -Logan

Hi,

I installed strace via yum and then ran the command, here is its output:

strace: attach: ptrace(PTRACE_ATTACH, ...): No such process

Thanks, -Logan

Hi,

I ran the command and it said "Process 4710 attached" but nothing else after that. It's still running, it's been about 5 minutes now, but there is still no output.

For reference, Webmin reports that process 4710, restore-domain.pl, is using 92.4% of CPU.

Thanks, -Logan

Update: strace is still running but no new output has been added. Similarly, restore-domain.pl is still running but has also not moved, and CPu usage is now at 93.0%.

Thanks, -Logan

Hi,

I stopped the restore process a few hours ago and restarted it, this time starting a stack trace immediately. Everything seemed to move along just fine until the "Restoring Apache virtual host configuration" part.

Here are the last few lines from the stack trace:

stat("/home/audioshout/fcgi-bin/php5.fcgi", {st_mode=S_IFREG|0755, st_size=202, ...}) = 0 geteuid() = 0 pipe([5, 10]) = 0 ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffb1f32510) = -1 ENOTTY (Inappropriate ioctl for device) lseek(5, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) ioctl(10, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffb1f32510) = -1 ENOTTY (Inappropriate ioctl for device) lseek(10, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe46c29aa10) = 13998 close(10) = 0 read(5, "OK\n", 8192) = 3 read(5, "#!/bin/bash\n", 8192) = 12 read(5, "PHPRC=$PWD/../etc/php5.6\n", 8192) = 25 read(5, "export PHPRC\n", 8192) = 13 read(5, "umask 022\n", 8192) = 10 read(5, "PHP_FCGI_MAX_REQUESTS=500\n", 8192) = 26 read(5, "export PHP_FCGI_MAX_REQUESTS\n", 8192) = 29 read(5, "SCRIPT_FILENAME=$PATH_TRANSLATED"..., 8192) = 33 read(5, "export SCRIPT_FILENAME\n", 8192) = 23 read(5, "exec /opt/rh/php56/bin/php-cgi\n", 8192) = 31 read(5, "", 8192) = 0 close(5) = 0 kill(13998, SIGKILL) = 0 wait4(13998, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], 0, NULL) = 13998 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=13998, si_status=SIGKILL, si_utime=2, si_stime=3} ---

As far as sending the backup file, I'm not exactly sure how I would do that because each virtual server is in its own TAR file, but I don't currently have a public Web server available to put the file on. I can give you SSH access to the server though if you'd like to take a look there at the backup files.

Thanks, -Logan

Good morning Jamie,

I just sent you an e-mail with SSH details. It will be coming from loganmeril@gmail.com.

Thanks, -Logan

Hi, just wanted to see if any progress has been made on this thus far? Because this very same restore worked on my other machine running CentOS 6 and Virtualmin 4.11 I was considering downgrading the current server to Virtualmin 4.11 from 4.13 if we can't get this resolved, as this has already caused more downtime than I would have liked. I look forward to seeing what you're able to do with this and if you are able to find and fix the issue. Thanks so much!

Honestly it varies each time I run the command, for some weird reason. Usually it's audioshout.com though. But it's usually the second or third domain that it tries to restore, if you run the full command I gave in my e-mail.

I am also logged in as root now too if you need to send a quick message via wall or something like that.

Thanks!

Restoring now....

Update: Restore has as of now gone farther than before, but seems to be stuck now on "Restoring SpamAssassin and Procmail configurations" for the virtual server cloud.onefridge.net. Not sure if it's hung or is just taking an abnormally long time, as it usually completed this step in only a few seconds for other servers. Will update again if things change.

Update 2: Never mind, looks to be caused by Virtualmin being unable to connect to my remote LDAP server, which I am checking now.

Update 3: Just checked the remote LDAP server and restarted the Virtualmin restore, let's see if things go OK this time. Also rebooted the Virtualmin machine. Will post if anything else goes wrong. Thanks.

Everything works now!! I'm not sure what you did, Jamie, but you fixed the issue. The restore process completed successfully and Virtualmin is humming along quite nicely now. Thank you so much for resolving the problem. What was the specific issue, anyway?

Thanks!