[systemd-devel] [PATCH v2 3/3] WIP: service: add StartLimitInterval/StartLimitBurst/StartLimitAction
Michael Olbrich
m.olbrich at pengutronix.de
Thu Feb 9 03:59:47 PST 2012
On Wed, Feb 08, 2012 at 09:41:10PM +0100, Lennart Poettering wrote:
> On Wed, 08.02.12 10:10, Michael Olbrich (m.olbrich at pengutronix.de) wrote:
>
> > Signed-off-by: Michael Olbrich <m.olbrich at pengutronix.de>
> > ---
> > changes in v2:
> > - Directly set ratelimit.interval/ratelimit.burst
> > There are some issues with that:
> > The names are now inconsistent: ratelimit vs. start_limit, maybe we
> > should call the variable ratelimit_action?
>
> Hmm, ratelimiting is the generic term, so I'd rather not expose that
> name externally, since we might need it later on. For example, it might
> make sense one day to add a logging ratelimiter to the mix, where we'd
> have yet another ratelimiter.
>
> Hence I'd propose to rename the internal variable to start_limit or so.
ok.
> > setting StartLimitBurst=0 will trigger an assert. Where would I add
> > range checking?
>
> Hmm, I figure if interval or burst is 0 we should implicitly disable the
> ratelimiter, to give the user a nice way to disable the ratelimiting if
> he really wants. I have now changed ratelimit.c accordingly. Please
> check if this does what is needed.
Looks good.
> > /* Make sure we don't enter a busy loop of some kind. */
> > if (!ratelimit_test(&s->ratelimit)) {
> > - log_warning("%s start request repeated too quickly, refusing to start.", u->id);
> > + switch (s->start_limit_action) {
> > + case SERVICE_START_LIMIT_NONE:
> > + log_warning("%s start request repeated too quickly, refusing to start.", u->id);
> > + break;
> > + case SERVICE_START_LIMIT_REBOOT: {
> > + DBusError error;
> > + int r;
> > +
> > + log_warning("%s start request repeated too quickly, rebooting.", u->id);
> > + dbus_error_init(&error);
> > + r = manager_add_job_by_name(u->manager, JOB_START, SPECIAL_REBOOT_TARGET, JOB_REPLACE, true, &error, NULL);
> > + if (r < 0)
> > + log_error("Failed to reboot: %s.", bus_error(&error, r));
> > + break;
> > + }
>
> I think a fallback on reboot-force would make sense here on
> failure. i.e. don't have the "break" here on failure of
> manager_add_job_by_name(). But please add a comment /* fallthrough */ so
> that this is easy to see.
Hmmm, I considered this. However, if I mask reboot.target (e.g. to prevent
reboots during system update or something like that). Then we fail here
with:
Failed to reboot: Unit reboot.target is masked..
I'm not sure if forcing a reboot anyways is a good idea in this case.
> > + case SERVICE_START_LIMIT_REBOOT_FORCE:
> > + log_warning("%s start request repeated too quickly, force rebooting.", u->id);
> > + u->manager->exit_code = MANAGER_REBOOT;
> > + break;
> > + case SERVICE_START_LIMIT_REBOOT_IMMEDIATE:
> > + reboot(RB_AUTOBOOT);
>
> Please add a message here too. People on serial terminals still might
> want to know why their machine is suddenly rebooting and they couzld
> still read the message since serial terminals are not flushed at reboot.
Ah, yes, with log-target == console I can actually see a message there.
> > + break;
> > + default:
> > + log_error("start limit action=%i", s->start_limit_action);
> > + assert_not_reached("Unknown StartLimitAction.");
> > + }
> > return -ECANCELED;
>
> Could you move all of this into it's own function please?
Ok.
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the systemd-devel
mailing list