I am wondering if anyone can offer advice on how to overcome this problem. An application has a start/stop/status script which can be called directly and may also be called from a web based console which is not running as root. Provided you use one of the two possible methods the status will reflect whether you started/stopped the application.
However if you also want to make sure the app starts when the system reboots, and possibly after a failure, it seems logical to introdce a forking service into the systemd space. Now, if you start/stop the service using systemctl, the script and console correctly reflect the state of the service BUT if you stop and then start the application without using systemctl, the application is OK but systemctl status thinks the application has failed.
One possible solution that I’ve considered is creating a specific piece of code, with limited capability, that has setuid set with an owner of root, which would then invoke the systemctl action, which would then, in turn, run the main script. However, even with limited capability any code which uses setuid needs approval.
Is there any way of starting/stopping an application that is listed as service and telling systemd that it really is running OK/not failed.
>
>I am wondering if anyone can offer advice on how to overcome this
>problem. An application has a start/stop/status script which can be
>called directly and may also be called from a web based console which is
>not running as root. Provided you use one of the two possible methods
>the status will reflect whether you started/stopped the application.
>
>However if you also want to make sure the app starts when the system
>reboots, and possibly after a failure, it seems logical to introdce a
>forking service into the systemd space. Now, if you start/stop the
>service using systemctl, the script and console correctly reflect the
>state of the service BUT if you stop and then start the application
>without using systemctl, the application is OK but systemctl status
>thinks the application has failed.
>
>One possible solution that I’ve considered is creating a specific piece
>of code, with limited capability, that has setuid set with an owner of
>root, which would then invoke the systemctl action, which would then, in
>turn, run the main script. However, even with limited capability any
>code which uses setuid needs approval.
>
>Is there any way of starting/stopping an application that is listed as
>service and telling systemd that it really is running OK/not failed.
So what is wrong with setuid scripts to invoke systemctl?
Also,
Why the aversion to using systemctl commands instead of whatever you’re doing now?
I’m guessing wildly, but I’m assuming that you’re seeing an inconsistency only because you’re invoking the app using a different Pid. Inspect the service Unit file and make sure that value is specified in whatever other way you’re invoking. Or, if it’s not defined, then appropriate modifications should be done to resolve your issue.
Also, you should know that a Linux CGroup is created for every newly invoked service if it’s not invoked by something else. By using Cgroups, stopping and restarting, and shutdown is now possible which wasn’t possible before because when a service is restarted even if it might be assigned a new Pid, it is still managed within the same Cgroup. In the old “pre-systemd” days, the restarted service would be an unmanaged orphan. Nowadays, by stopping the Cgroup even restarted services will be stopped reliably.
So, depending on whatever your external commands are doing it might not even work reliably unless it understands this tidbit how systemd works now.
Hadn’t realised anyone had picked up on this. Unfortunately I don’t think I can have explained myself properly.
The application in question is supplied with a start/stop script which can be invoked from command line or via a web page. It knows nothing about systemctl and, so far as I am aware, there are no specific plans to change the application to use systemctl to start and stop it.
The problem that I perceived is that when systemctl is doing the job it doesn’t like any other method to be used and I haven’t been able to find any way around this.
There must be a large number of applications out there similar to this that had to have start/stop scripts before systemctl existed and I suspect that many of them can’t be simply changed to allow systemctl to take over. The major factor with this one is the fact that permitted users are allowed to start/stop the application from the web GUI.
On 2014-06-27 15:06, davidlwilcox wrote:
>
> Hadn’t realised anyone had picked up on this. Unfortunately I don’t
> think I can have explained myself properly.
>
> The application in question is supplied with a start/stop script which
> can be invoked from command line or via a web page. It knows nothing
> about systemctl and, so far as I am aware, there are no specific plans
> to change the application to use systemctl to start and stop it.
Well, edit that file and add the sysstemd support yourself.
You can see some “rc…” scripts that when called they say “redirecting
to systemd”. That’s what you have to do, velis nolis (that’s a Latin
saying used in math).
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)