[
https://issues.apache.org/jira/browse/VCL-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Kurth updated VCL-1027:
----------------------------
Description:
I have seen this occur on server requests when multiple users are added in a
short amount of time. The ext_sshd service is restarted every time a user is
added. There is some threshold in systemd that prevents this, causing the
service to stop and not restart without waiting for a few seconds.
This is the error:
{noformat}
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
Job for ext_sshd.service failed because start of the service was attempted too
often. See "systemctl status ext_sshd.service" and "journalctl -xe" for details.
To force a start use "systemctl reset-failed ext_sshd.service" followed by
"systemctl start ext_sshd.service" again.
{noformat}
When this occurs, users can't connect to the reservation. There is currently no
code that detects or corrects this.
Options could be added to the systemd service file created in
{{systemd.pm::add_ext_sshd_service}}.
>From the _systemd.service_ man page:
{panel}
StartLimitInterval=, StartLimitBurst=
Configure service start rate limiting. By default, services which
are started more than 5 times within 10 seconds are not permitted to start any
more times until the 10 second interval ends. With these two options, this rate
limiting may
be modified. Use StartLimitInterval= to configure the checking
interval (defaults to DefaultStartLimitInterval= in manager configuration file,
set to 0 to disable any kind of rate limiting). Use StartLimitBurst= to
configure how many
starts per interval are allowed (defaults to DefaultStartLimitBurst=
in manager configuration file). These configuration options are particularly
useful in conjunction with Restart=; however, they apply to all kinds of starts
(including
manual), not just those triggered by the Restart= logic. Note that
units which are configured for Restart= and which reach the start limit are not
attempted to be restarted anymore; however, they may still be restarted
manually at a later
point, from which point on, the restart logic is again activated.
Note that systemctl reset-failed will cause the restart rate counter for a
service to be flushed, which is useful if the administrator wants to manually
start a service and
the start limit interferes with that.
StartLimitAction=
Configure the action to take if the rate limit configured with
StartLimitInterval= and StartLimitBurst= is hit. Takes one of none, reboot,
reboot-force, reboot-immediate, poweroff, poweroff-force or poweroff-immediate.
If none is set,
hitting the rate limit will trigger no action besides that the start
will not be permitted. reboot causes a reboot following the normal shutdown
procedure (i.e. equivalent to systemctl reboot). reboot-force causes a forced
reboot which
will terminate all processes forcibly but should cause no dirty file
systems on reboot (i.e. equivalent to systemctl reboot -f) and reboot-immediate
causes immediate execution of the reboot(2) system call, which might result in
data loss.
Similar, poweroff, poweroff-force, poweroff-immediate have the
effect of powering down the system with similar semantics. Defaults to none.
{panel}
was:
I have seen this occur on server requests when multiple users are added in a
short amount of time. The ext_sshd service is restarted every time a user is
added. There is some threshold in systemd that prevents this, causing the
service to stop and not restart without waiting for a few seconds.
This is the error:
{noformat}
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
[root@bn17-97 ~]# service ext_sshd restart
Redirecting to /bin/systemctl restart ext_sshd.service
Job for ext_sshd.service failed because start of the service was attempted too
often. See "systemctl status ext_sshd.service" and "journalctl -xe" for details.
To force a start use "systemctl reset-failed ext_sshd.service" followed by
"systemctl start ext_sshd.service" again.
{noformat}
When this occurs, users can't connect to the reservation. There is currently no
code that detects or corrects this.
Options could be added to the systemd service file created in
{{systemd.pm::add_ext_sshd_service}}. Two potential additions under the
\[Service\] section:
* Restart=on-failure
* RestartSec=3s
> External SSH service under systemd fails to restart if several restarts are
> rapidly attempted
> ---------------------------------------------------------------------------------------------
>
> Key: VCL-1027
> URL: https://issues.apache.org/jira/browse/VCL-1027
> Project: VCL
> Issue Type: Improvement
> Reporter: Andy Kurth
> Assignee: Andy Kurth
> Fix For: 2.5
>
>
> I have seen this occur on server requests when multiple users are added in a
> short amount of time. The ext_sshd service is restarted every time a user is
> added. There is some threshold in systemd that prevents this, causing the
> service to stop and not restart without waiting for a few seconds.
> This is the error:
> {noformat}
> [root@bn17-97 ~]# service ext_sshd restart
> Redirecting to /bin/systemctl restart ext_sshd.service
> [root@bn17-97 ~]# service ext_sshd restart
> Redirecting to /bin/systemctl restart ext_sshd.service
> [root@bn17-97 ~]# service ext_sshd restart
> Redirecting to /bin/systemctl restart ext_sshd.service
> [root@bn17-97 ~]# service ext_sshd restart
> Redirecting to /bin/systemctl restart ext_sshd.service
> [root@bn17-97 ~]# service ext_sshd restart
> Redirecting to /bin/systemctl restart ext_sshd.service
> Job for ext_sshd.service failed because start of the service was attempted
> too often. See "systemctl status ext_sshd.service" and "journalctl -xe" for
> details.
> To force a start use "systemctl reset-failed ext_sshd.service" followed by
> "systemctl start ext_sshd.service" again.
> {noformat}
> When this occurs, users can't connect to the reservation. There is currently
> no code that detects or corrects this.
> Options could be added to the systemd service file created in
> {{systemd.pm::add_ext_sshd_service}}.
> From the _systemd.service_ man page:
> {panel}
> StartLimitInterval=, StartLimitBurst=
> Configure service start rate limiting. By default, services which
> are started more than 5 times within 10 seconds are not permitted to start
> any more times until the 10 second interval ends. With these two options,
> this rate limiting may
> be modified. Use StartLimitInterval= to configure the checking
> interval (defaults to DefaultStartLimitInterval= in manager configuration
> file, set to 0 to disable any kind of rate limiting). Use StartLimitBurst= to
> configure how many
> starts per interval are allowed (defaults to
> DefaultStartLimitBurst= in manager configuration file). These configuration
> options are particularly useful in conjunction with Restart=; however, they
> apply to all kinds of starts (including
> manual), not just those triggered by the Restart= logic. Note that
> units which are configured for Restart= and which reach the start limit are
> not attempted to be restarted anymore; however, they may still be restarted
> manually at a later
> point, from which point on, the restart logic is again activated.
> Note that systemctl reset-failed will cause the restart rate counter for a
> service to be flushed, which is useful if the administrator wants to manually
> start a service and
> the start limit interferes with that.
> StartLimitAction=
> Configure the action to take if the rate limit configured with
> StartLimitInterval= and StartLimitBurst= is hit. Takes one of none, reboot,
> reboot-force, reboot-immediate, poweroff, poweroff-force or
> poweroff-immediate. If none is set,
> hitting the rate limit will trigger no action besides that the
> start will not be permitted. reboot causes a reboot following the normal
> shutdown procedure (i.e. equivalent to systemctl reboot). reboot-force
> causes a forced reboot which
> will terminate all processes forcibly but should cause no dirty
> file systems on reboot (i.e. equivalent to systemctl reboot -f) and
> reboot-immediate causes immediate execution of the reboot(2) system call,
> which might result in data loss.
> Similar, poweroff, poweroff-force, poweroff-immediate have the
> effect of powering down the system with similar semantics. Defaults to none.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
