Fun with xymonlaunch and MAXTIME
list Ralph Mitchell
Apparently the tasks.cfg MAXTIME option is not very tolerant of spacing:
MAXTIME 10m - with two spaces, is interpreted as 10 seconds
MAXTIME 10m - with one space, is interpreted as 600 seconds
I think the problem lies at line 276 in xymon-4.3.28/common/xymonlaunch.c:
tspec = p + strspn(p, "0123456789");
switch (*tspec) {
case 'm': curtask->maxruntime *= 60; break; /*
Minutes */
case 'h': curtask->maxruntime *= 3600; break; /*
Hours */
case 'd': curtask->maxruntime *= 86400;
break; /* Days */
}
The pointer p is pointing to the first character after "MAXTIME ". That's
fine as long as it points to a numeric string. If it doesn't point to a
string of digits, tspec doesn't end up pointing to the multiplier, so
MAXTIME is handled as seconds.
Adding a space to the strspn string should fix it:
tspec = p + strspn(p, " 0123456789");
Similarly, at line 254, for the INTERVAL option.
Ralph Mitchell
list Japheth Cleaver
▸
On 2/22/2017 1:06 PM, Ralph Mitchell wrote:
Apparently the tasks.cfg MAXTIME option is not very tolerant of spacing:
MAXTIME 10m - with two spaces, is interpreted as 10 seconds
MAXTIME 10m - with one space, is interpreted as 600 seconds
I think the problem lies at line 276 in xymon-4.3.28/common/xymonlaunch.c:
tspec = p + strspn(p, "0123456789");
switch (*tspec) {
case 'm': curtask->maxruntime *= 60; break; /* Minutes */
case 'h': curtask->maxruntime *= 3600; break; /* Hours */
case 'd': curtask->maxruntime *= 86400; break; /* Days */
}
The pointer p is pointing to the first character after "MAXTIME ". That's fine as long as it points to a numeric string. If it doesn't point to a string of digits, tspec doesn't end up pointing to the multiplier, so MAXTIME is handled as seconds.
Adding a space to the strspn string should fix it:
tspec = p + strspn(p, " 0123456789");
Similarly, at line 254, for the INTERVAL option.Hi, Yikes, yes we should definitely be more whitespace-tolerant here. It's possible this has been the root for occasional unexpected behavior over the years for some folks. Thanks for the catch; this will be in the next update. Regards, -jc
list Ralph Mitchell
On Wed, Feb 22, 2017 at 4:10 PM, Japheth Cleaver <user-87556346d4af@xymon.invalid>
▸
wrote:
On 2/22/2017 1:06 PM, Ralph Mitchell wrote:Apparently the tasks.cfg MAXTIME option is not very tolerant of spacing: MAXTIME 10m - with two spaces, is interpreted as 10 seconds MAXTIME 10m - with one space, is interpreted as 600 seconds
I think the problem lies at line 276 in xymon-4.3.28/common/xymonlaunc h.c:
▸
tspec = p + strspn(p, "0123456789"); switch (*tspec) { case 'm': curtask->maxruntime *= 60; break; /* Minutes */ case 'h': curtask->maxruntime *= 3600; break; /* Hours */ case 'd': curtask->maxruntime *= 86400; break; /* Days */ } The pointer p is pointing to the first character after "MAXTIME ". That's fine as long as it points to a numeric string. If it doesn't point to a string of digits, tspec doesn't end up pointing to the multiplier, so MAXTIME is handled as seconds. Adding a space to the strspn string should fix it: tspec = p + strspn(p, " 0123456789"); Similarly, at line 254, for the INTERVAL option.Hi, Yikes, yes we should definitely be more whitespace-tolerant here. It's possible this has been the root for occasional unexpected behavior over the years for some folks.
That area in the code has not changed much since at least 4.3.12 - I diff'd
4.3.12 and 4.3.28 to see what might have changed to break it, because it
seemed to work in 4.3.12. Turns out I had used two spaces insstead of
one....
You might want to throw in a \t as well, so it can tolerate tabs.
Ralph Mitchell