Moving from CentOS 5 to CentOS 7, discovered that a test in a SysV initscript for whether it is running interactively, instead of at boot time, no longer works.
Under CentOS 7 / systemd, is there some way for the initscript to know this?
On 18 Dec 2016 10:59, "whitivery" co55-sy1t@dea.spamcon.org wrote:
Moving from CentOS 5 to CentOS 7, discovered that a test in a SysV initscript for whether it is running interactively, instead of at boot time, no longer works.
Under CentOS 7 / systemd, is there some way for the initscript to know this?
Generally "interactive" init scripts are not in any way supported under any RHEL version and can't be done under systemd on EL7
What is it that it does and you are actually trying to achieve?
If it's a password or something like that it's possible to integrate with the systemd-ask-password facility from a unit file, but it is quite complex relatively speaking so it'd be useful to know the actual goal in mind before going down this road.
James Hogarth james.hogarth@gmail.com wrote:
On 18 Dec 2016 10:59, "whitivery" co55-sy1t@dea.spamcon.org wrote:
Moving from CentOS 5 to CentOS 7, discovered that a test in a SysV initscript for whether it is running interactively, instead of at boot time, no longer works.
Under CentOS 7 / systemd, is there some way for the initscript to know this?
Generally "interactive" init scripts are not in any way supported under any RHEL version and can't be done under systemd on EL7
What is it that it does and you are actually trying to achieve?
If it's a password or something like that it's possible to integrate with the systemd-ask-password facility from a unit file, but it is quite complex relatively speaking so it'd be useful to know the actual goal in mind before going down this road.
It is a system with several servers (various platforms/distros).
One piece of software runs on all of the servers. For it to operate correctly, the instance on one server (prime) must start before the others (auxiliary).
So a boot delay is added (via a script sourced from initscript, which first waits for network to come up) to set the boot delay values for each server - prime at 0, others at some other value of 15 to 110 seconds depending on platform.
But when it is necessary to manipulate the service interactively via the "service" command, the boot delay needs to be bypassed.
On Sun, Dec 18, 2016 at 08:50:54PM -0800, whitivery wrote:
It is a system with several servers (various platforms/distros).
One piece of software runs on all of the servers. For it to operate correctly, the instance on one server (prime) must start before the others (auxiliary).
So a boot delay is added (via a script sourced from initscript, which first waits for network to come up) to set the boot delay values for each server - prime at 0, others at some other value of 15 to 110 seconds depending on platform.
But when it is necessary to manipulate the service interactively via the "service" command, the boot delay needs to be bypassed.
Well, the first thing I'd do is make the service wait for the network to be online. In the [Unit] section add Wants=network-online.target.
Secondly, I'd try to find a way for the auxiliary services to ping the prime service to ensure its up, and make that script a ExecStartPre entry in the [Service] section. You'll want to adjust the TimeoutStartSec in case it might exceed the DefaultTimeoutStartSec in /etc/systemd/system.conf, which is 90 seconds.
Jonathan Billings billings@negate.org wrote:
On Sun, Dec 18, 2016 at 08:50:54PM -0800, whitivery wrote:
It is a system with several servers (various platforms/distros).
One piece of software runs on all of the servers. For it to operate correctly, the instance on one server (prime) must start before the others (auxiliary).
So a boot delay is added (via a script sourced from initscript, which first waits for network to come up) to set the boot delay values for each server - prime at 0, others at some other value of 15 to 110 seconds depending on platform.
But when it is necessary to manipulate the service interactively via the "service" command, the boot delay needs to be bypassed.
Well, the first thing I'd do is make the service wait for the network to be online. In the [Unit] section add Wants=network-online.target.
Secondly, I'd try to find a way for the auxiliary services to ping the prime service to ensure its up, and make that script a ExecStartPre entry in the [Service] section. You'll want to adjust the TimeoutStartSec in case it might exceed the DefaultTimeoutStartSec in /etc/systemd/system.conf, which is 90 seconds.
Thank you for the idea, but as mentioned, the same service runs on a mix of server platforms and distros, and the older ones do not use systemd, so I'd prefer to stick with SysV type initscripts that work on all of them.
whitivery co55-sy1t@dea.spamcon.org wrote:
Jonathan Billings billings@negate.org wrote:
On Sun, Dec 18, 2016 at 08:50:54PM -0800, whitivery wrote:
It is a system with several servers (various platforms/distros).
One piece of software runs on all of the servers. For it to operate correctly, the instance on one server (prime) must start before the others (auxiliary).
So a boot delay is added (via a script sourced from initscript, which first waits for network to come up) to set the boot delay values for each server - prime at 0, others at some other value of 15 to 110 seconds depending on platform.
But when it is necessary to manipulate the service interactively via the "service" command, the boot delay needs to be bypassed.
Well, the first thing I'd do is make the service wait for the network to be online. In the [Unit] section add Wants=network-online.target.
Secondly, I'd try to find a way for the auxiliary services to ping the prime service to ensure its up, and make that script a ExecStartPre entry in the [Service] section. You'll want to adjust the TimeoutStartSec in case it might exceed the DefaultTimeoutStartSec in /etc/systemd/system.conf, which is 90 seconds.
Thank you for the idea, but as mentioned, the same service runs on a mix of server platforms and distros, and the older ones do not use systemd, so I'd prefer to stick with SysV type initscripts that work on all of them.
Follow-up: with no other solution, I solved the problem externally.
I made an alias (actually, a shell function) for "service". If the interactive user is trying to start or restart the affected service, a flag (sourced environment variable in a file under /etc/default) is set, the real service binary is called, the initscript sees the flag and skips the boot delay, then the "service" function restores the flag.
Less than ideal but it works.
-
James Hogarth -
Jonathan Billings -
whitivery