the "service" command available on debian,ubuntu,centos (perhaps elsewhere) can work with both systemd unit files and sysvinit scripts. This particularly helps on system shere systemd is installed but not run as init (pid 1), since systemctl fails in such case. I have added this code into /usr/local/ispconfig/server/lib/classes/system.inc.php and so far it works on debian 10 with both sysvinit and systemd //* service command default for systemd&sysvinit if (is_executable('/usr/sbin/service')){ $app->log('Using service command to restart service',LOGLEVEL_DEBUG); //* Test service name via regex if(preg_match('/[a-zA-Z0-9\.\-\_]/',$servicename)) { return 'service '.$servicename.' '.$action; } else { $app->log('service name contains invalid chars: '.$servicename,LOGLEVEL_DEBUG); } }
still, the code for sysvinit scripts it there. The code I posted does not care which init system is used.
That's actually true but I'am on @Th0m side here. service is just a bash wrapper script that could be removed by future distributions and since systemd is the defacto standard, let's use systemd service handling instead of "service".
anything may happen in the future. Wouldn't it be better to support multiple possible options as they are available now?
You say in the first post that you are using Debian 10, systemd is the default init system of Debian 10, so you should not use old sysvinit scripts anymore on your system and instead of changing ISPConfig, you should replace your remaining old init scripts which you might have written manually to a systemd service files. We support multiple init systems already. ISPConfig currently supports sysvinit and systemd-based systems. If systemd is installed, then systemd is preferred over sysvinit and used to restart services. All current Linux distributions that are supported by ISPConfig use systemd only, sysvinit is not used anymore. Sure and when a new Linux init system shows up in the next years and becomes the default in any of the Linux distributions that are supported by ISPConfig, then we will support that as well at that timepoint.
My point is, systemd can be installed but not used as init system so reloading by systemctl does not work. This patch fixes this behaviour by using something that exists in systems I have checked (debian,ubuntu,centos 7), so I think it's the most universal solution at least up to this date.
Which is not supported by ISPConfig and not used by any of the supported Linux distributions. You did not follow our ISPConfig install instructions, which set up a system using systemd on Debian 10, and now instead of fixing your setup, you ask us to change ISPConfig instead. I doubt that it is officially recommended to use service command wrapper instead of systemctl on a system with systemd installed. What we might do though is that you change your code to apply to systems only that do not use systemd but have it installed. In other words, you must test that systemd is inactive and not started even if it's installed and only use service command in such a rare case, then we can implement it.
Btw. if you had issues with restarting services, then the common reasons are either that you missed enabling the service in systemd (use systemd enable command to fix that) as ISPConfig will restart services only that are properly enabled (it is not enough to install a service and skip to enable it) or you started the service manually using an init script, which prevents that systemd can restart it. In the second case, stop it using the init script, check with ps command that really all processes are stopped and then start it properly using systemctl command again.
I proposed to avoid this by using "service" wrapper that already does all of this. I have tested it and it works as needed at least on debian 10. no, my particular problem is that I don't use systemd but have it installed because of dependencies. systemctl does not work in this case, service does.
Inspired by the discussion I search the internet and found this interesting post (see also the one below that): https://askubuntu.com/questions/903354/difference-between-systemctl-and-service-commands So, "service" first checks for upstart, then systemd, then SysVInit Now, after reading a lot I would also vote against the sue of the service command. In the future, ispconfig might want to use functions of systemd, which are not in the featureset of the service wrapper. That will become a mess in the code. However, leave this snipped here for people who are allergic of systemd and still want to use ispconfig.
At least the ispconfig 3.1 PDF manual says nothing about systemd. Since ISPConfig seems to support sysvinit, I have expected it to work with it. I found a case where it does not work and proposed a solution. I can only tell that the service command is here exactly for cases if someone wants to be compatible with multiple init systems and has proper tests for those. It was used by ISPConfig with upstart and it's still uused in install/lib/installer_base.lib.php, but commented in server/lib/classes/system.inc.php looking at most of scripts they test for /run/systemd/system like service from debian distro: if [ -d /run/systemd/system ]; then is_systemd=1 fi perhaps this check could be added to existing checks or replace them
The ISPConfig 3.1 manual does not even cover installations on Debian 10, so how should it mention it? The ISPConfig installation instructions can be found here: https://www.ispconfig.org/documentation/ and as you can see in the perfect server guides for Debian 10, they use systemd. And the perfect server guides define the system requirements for an ISPConfig setup on a specific OS version. It has been explained to you by several people now that service command should not be used on systems that have systemd installed and that's why ISPConfig is not using it when it finds systemd. That's a test if systemd is running, which is basically what I suggested to you in #8 to implement if you like to see this in ISPConfig instead of proposing to change to the service command.
I see that we disagree that command specifically designed to do something "should not" be used for that something. I didn't start this thread to blame anyone but to improve whatever. Well - it's your software, your decision. This is why I have posted this. Test for "/run/systemd/system" directory looks easy and should work. #8 was however just generic recommendation to do a check, at that time I've had no idea what to check for. I plan to test it.
I have tested using: if((is_executable('/bin/systemd') || is_executable('/usr/bin/systemctl'))&&is_dir('/run/systemd/system')){ instead of simple: if(is_executable('/bin/systemd') || is_executable('/usr/bin/systemctl')){ and it works with both systemd and sysvinit the code is also used in: install/lib/installer_base.lib.php
Interesting discussion, thanks. The Perfect guide for Ubuntu 20 does seems to prefer the use of 'service' versus 'systemctl', and in a single instruction uses both: In my own scripting related to ISPConfig installation, I have notes to go back and replace 'service' with 'systemctl', and have not done that yet because of the explicit references in the Perfect guide. So if the word is 'always use systemctl because systemd is the current distro default and the current ISPConfig standard", then I will change my own scripts and request that the Perfect guide get updated as well - maybe with a new v22 doc and for related distros.
