The /etc/webmin/apache/config file contains obsolete command

As the screenshot shows it is "service httpd graceful". What option or exact command should be here for RHEL 7.x based Virtualmin systems?

The server is a fresh CentOS 7.x install, but Virtualmin configuration was copied from another server. Anyway, even if this setting came from Virtualmin configuration backup file, there should be a check somewhere in the middle to verify the RHEL version and replace the faulty command.

Just so you know, the "apache2ctl graceful" command didn't work on CentOS 7.x, but the "apachectl graceful" did.

root@centos7:/root# apache2ctl graceful -bash: apache2ctl: command not found root@centos7:/root# apachectl graceful

Anyway, my original request was to update the obsolete command in /etc/webmin/apache/config for RHEL 7.x systems. So maybe we need to get the following three commands:

replaced respectively by:

?

Here is the content of freshly installed CentOS 7.x Virtualmin system:

So please make sure to replace the commands as suggested above. The "service httpd reload" command for the "apply_cmd" option could be replaced with systemctl reload httpd instead of apachectl graceful, but I am not sure which one is more appropriate.

Please note "apply_cmd" should be equal to systemctl reload httpd and not apachectl graceful otherwise Anacron keeps sending the following message:

It executes without without any warnings, however if apachectl graceful is left in the Webmin config file for Apache then the system sends the above notification message, so I believe the ideal value for apply_cmd= should be systemctl reload httpd.

Moreover, I noticed another empty value in the file:

which probably should be equal to apachectl graceful.

In the same manner I suggest to replace

in /etc/webmin/mysql/config with

For that matter all RHEL 6.x style service name command need to be replaced by RHEL 7.x style systemctl command name.

I've found the following incidents:

Doesn't the reload command completely stop and re-start Apache though? Whereas graceful just tells it to re-read the config.

I am not sure, Jamie, but that might be true for RHEL 6.x. As I said before on RHEL 7.x the system sends the following notice:

so it is redirecting graceful to reload anyway, then why we don't make it easier for the system and use the correct command without redirecting it?

Please also read http://www.cyberciti.biz/faq/apache-making-changes-config-file-without-r... which seems to imply both are the same.

The accepted answer on another thread http://stackoverflow.com/questions/671667/apache-httpd-reload compares restart and reload:

/my/path/to/httpd restart Causes the current httpd process to exit, which means for a time the server appears to be down, as in not serving any requests.

    /my/path/to/httpd reload Does not cause the current server to exit, which means connections are never refused and thus the server never looks down (but is rather slow for a little while)

Also, will you please replace all these commands:

I'm reluctant to use systemctl more widely, as the service command is compatible with more distributions.

I see your concern, however you have different repositories for different OS distributions, don't you? If so then you can safely replace all commands in RHEL 7.x-based distributions (https://en.wikipedia.org/wiki/List_of_Linux_distributions#RHEL-based) since RHEL 7.x switched to "systemctl command service-name" format and all the consecutive releases will do too.

Moreover, you can switch one level up and replace all "service" commands on Fedora-based distributions (https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet), because it was not RHEL, but Fedora which made a shift: https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

Please also read https://fedoraproject.org/wiki/Systemd and especially pay attention to this quote from https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s...

Expect legacy commands to be deprecated!

systemctl fully replaces traditional utilites like service and chkconfig. While some services can still be administered with these legacy commands, all services can be administered with systemctl.

So "service ..." will be eventually deprecated on Fedora-based distros. Then why wait, especially when Virtualmin is sending unnecessary reports because of the old-style commands?

Hi Jamie,

I would still love to hear your stance on the following quote from:

https://fedoraproject.org/wiki/Systemd and especially pay attention to this quote from https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s...

Expect legacy commands to be deprecated!

systemctl fully replaces traditional utilites like service and chkconfig. While some services can still be administered with these legacy commands, all services can be administered with systemctl.

Please try to understand while it is ok to leave "service ..." style commands on Debian based distros, all of them should be replaced by "systemctl ..." style on Fedora-based distros. Otherwise, Virtualmin/Webmin based systems will just keep sending unnecessary notification messages to root mail. Which is really annoying.

Unfortunately, all CentOS 7.x based Virtualmin systems keep sending everyday notifications to root like:

And it is really annoying as we can't block the root messages to be able to receive other important notifications. So I am afraid all "service" like commands have to be replaced systemwide.

Eric,

Please read the issue from the very beginning. Jamie doesn't want to replace all "service" like style commands as he thinks it is more universal. Which is true as it works on other distros like Debian, Ubuntu. However as I explained above Fedora-based systems like RHEL, CentOS, Scientific Linux, etc will eventually completely switch to "systemctl" style commands.

Manually editing is not helpful as (1) we have lot's of such servers and (2) the next update from Virtualmin repository could override our changes. And that is why I am asking Jamie and the team to really pay attention to above stated changes in Fedora-world. You really can not ignore them and eventually will have to replace all "service" like commands to "systemctl" like ones, however the problem is that until then all Fedora 7.x based Virtualmin server owners have to suffer from receiving unnecessary notifications. It is extremely problematic when you have lot's of Virtualmin servers.

Thanks Eric,

We will try to manually update logrotate on all previously existing servers. However, I still believe there is no much sense in keeping the following obsolete commands in Fedora-based systems, they all need to be replaced as otherwise Virtualmin systems will keep sending unnecessary notifications:

This is still an issue on Webmin 1.770 as all the "service" style commands there intact and all our systems keep sending us annoying messages... :(

It was completely new install from CentOS 7.x template available through Cloudmin UI.

CentOS 7.0 64-bit KVM instance with base OS

Sure:

But I have already edited commands in /etc/webmin/apache/config.

Anyway, what is the status of the following files under /etc/webmin/ directory:

which also have the following obsolete commands:

and the system is occasionally giving or sending notices because of them?

Please have them all changed for CentOS 7.x. You can leave them on Debian based systems, but RHEL will never return to "Service" style command and there is no point of torturing us, Virtulmin/Webmin system administrators - we can't turn of root mail, at the same time it is sending so many unnecessary messages because of these commands.

Those other config files will be updated in the next Webmin release.

Thanks Jamie!

However, I just did a fresh install of Webmin 1.770 onto a VM created in Cloudmin from the CentOS 7 64-bit KVM template, and /etc/webmin/apache/config looked correct

Strange. The only thing is coming to my mind then is that probably I downloaded that image long time ago, which most probably is true, because there were lot's of updates.

Could you make Cloudmin check if the image file is too old and either (1) to automatically download the newest one or (2) output a recommenddation to update the file?