On Dec 22, 2020 I submitted this bug report: https://www.virtualmin.com/comment/831622#comment-831622
re: JamieCameron said this would be fixed in the next virtualmin release. I have yet to see this fix on Ubuntu apt-get update / apt-get install
Now when I add a new virtual server, I have to manually hack and copy files from: /etc/init.d/php-fcgi-domain
...and also
/lib/systemd/system/php-fcgi-domain.service
From existing domain files.
After that, I have to run systemctl daemon-reload and systemctl start (service name)
This is on Ubuntu 18.04.5 LTS
This is a CRITICAL / showstopper bug. Please try it yourself on an Ubuntu 18.04.5 installation. Webmin and Virtualmin is severely corrupted. After waiting a month for a fix -- this has now become a high priority item.
I appreciate the webmin/virtualmin solution - but it has become unbearable to deal with because of this issue. Who knows how many silent users have dealt with this issue and simply given up on webmin/virtualmin as a result?
Comments
Submitted by tonyant on Mon, 02/01/2021 - 14:41 Comment #1
Submitted by tonyant on Mon, 02/01/2021 - 14:43 Comment #2
Fixed typo
Submitted by JamieCameron on Tue, 02/02/2021 - 20:48 Comment #3
Which Webmin version are you running there? The latest release (1.971) should already contain a fix for this.
Wait, is this Nginx? If so, what is Virtualmin Nginx module do you have installed? (can be checked on System Settings > Features and Plugins page.)
Submitted by tonyant on Wed, 02/03/2021 - 13:46 Comment #5
Yes, I'm running NGINX -- It handles port scans and small DoS a lot better than bloated Apache. -- A lot of people are using NGINX more and more these days.
We run both non-ssl and SSL websites.
The error that creates this seems to be in this file: /usr/share/webmin/virtualmin-nginx/virtualmin-nginx-lib.pl
Check around line 1708
Current:
"Starts Nginx PHP FastCGI server for $d->{'dom'} (Virtualmin)", &command_as_user($d->{'user'}, 0, "$envs $cmd >>$log 2>&1 </dev/null")." & echo \$! >$pidfile && chmod +r $pidfile", &command_as_user($d->{'user'}, 0, "kill `cat $pidfile`")." ; sleep 1",I think the second line is missing something to give a full path to the kill command (and the cat command) -- systemd runs first and doesn't have access to a user environment path if I remember correctly.
I'm really wondering why the first command which ends up as an ExecStart for systemctl says:
$envs $cmd...but the second command that ends up in ExecStop doesn't have the $envsIt seems to be one of the most confusing things that gets a lot of people I'm on Ubuntu (debian).. Here's someone talking about it on Centos that could help https://unix.stackexchange.com/questions/347873/set-path-for-a-systemd-unit
Submitted by tonyant on Thu, 02/04/2021 - 03:40 Comment #6
I can come close to fixing this problem EXCEPT for one single escaped \ backslash character that needs to be removed manually.
/usr/share/webmin/virtualmin-nginx/virtualmin-nginx-lib.pl Line 1708
This will create this type of entry in /libs/systemd/system/php-fcgi-domain.service
...and systemd will still complain about an Exec Format error. But all I have to do now is manually remove the backlash infront of the kill command:
...and now I can do:
...and things work. fcgi-php gets started for the user just fine, like it should. ** Removing the first backslash \ before the kill command is important.** It's obvious that this function is going thorough a regex and all single quotes are being escaped somewhere. Hope this helps a programmer that knows how to fix it.
Okay, thanks for your ideas. The real source of the issue was that commands didn't have absolute paths. It's going to be fixed in Nginx module 2.19.
You are welcome to try the patch.
Thanks for reporting.
Submitted by tonyant on Thu, 02/04/2021 - 13:04 Comment #8
I can confirm this patch works!! Thank you so much for fixing it.