On Tue, Sep 18, 2012 at 1:21 PM, Zdenek Styblik
<zdenek.styb...@gmail.com> wrote:
> On Mon, Sep 17, 2012 at 3:46 PM, <dick.detwei...@emerson.com> wrote:
>>
>> Hello all,
>>
>> I lead a group that uses ipmitool in server control software we write and 
>> maintain.  We have uncovered a curious issue with ipmitool's 'sel set time' 
>> and 'exec' commands.  This is using ipmitool version 1.8.10.  I have looked 
>> through the change logs for 1.8.11 and 12 and not seen this problem 
>> addressed.
>>
>> If we issue 'sel set time' from the command line, and then put the exact 
>> same command into a file and use exec to execute it, we get an hour's 
>> difference in the commands.  Here is a screen shot:
>>
>> Is this a known issue?
>>
>> Thanks,
>> Dick
>>
>
> Hello Dick,
>
> to tell you whether it is known issue or not; it is hard when people
> refuse to use SF.net bug tracker. I don't remember seeing this one in
> there, so I'd say it is not a known issue.
>
> Anyway, here is what I got and what I got to:
>
> ~~~ debug output
> [root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool sel time
> set "09/14/2012 18:30:00"
> TM before mktime()
> hour: 18
> min: 30
> isdst: 3
> tz1: 'GMT'
> tz2: 'GMT'
> ---
> TM after mktime()
> hour: 18
> min: 30
> isdst: 1
> tz1: 'CET'
> tz2: 'CEST'
> ---
> Leaving time alone.
>
> Delta is '2'
>
> 09/14/2012 18:30:00
> [root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool exec time
> TM before mktime()
> hour: 18
> min: 30
> isdst: 0
> tz1: 'GMT'
> tz2: 'GMT'
> ---
> TM after mktime()
> hour: 19
> min: 30
> isdst: 1
> tz1: 'CET'
> tz2: 'CEST'
> ---
> Leaving time alone.
>
> Delta is '2'
>
> 09/14/2012 19:30:00
> ~~~ debug output
>
> The reason, as you can see, is tm.tm_isdst being set to random value.
> And once it is set to value 0, other time it is set to > 0. Setting
> tm.tm_isdst to (-1) prior calling mktime() gives, at least,
> deterministic behaviour.
>
> From mktime() man page:
> ``The value specified in the tm_isdst field informs mktime() whether
> or not daylight saving time (DST) is in effect for the time supplied
> in the tm  structure:  a  positive  value means  DST is in effect;
> zero means that DST is not in effect; and a negative value means that
> mktime() should (use timezone information and system databases to)
> attempt to determine whether DST is in effect at the specified time.''
>

Ok, "should" is not "always" as written below. I'm wondering whether
it means it is not going to work (reliably) for some platforms(meaning
OS).

> In other words and short, the following change will force mktime() to
> *always* check whether DST is in use or not instead of using random
> value. One way or another, use of random value set in/to tm.tm_isdst
> should be eliminated!
>
> ~~~ snip lib/ipmi_sel.c
>                 if (strptime(time_string, time_format, &tm) == 0) {
>                         lprintf(LOG_ERR, "Specified time could not be 
> parsed");
>                         return -1;
>                 }
>                 tm.tm_isdst = (-1);
>                 t = mktime(&tm);
>                 if (t < 0) {
>                         lprintf(LOG_ERR, "Specified time could not be 
> parsed");
>                         return -1;
>                 }
> ~~~ snip lib/ipmi_sel.c
>
> I can't put more time into this right now, but debug above should give
> enough clues what's wrong. And actually, patch/fix seems to be solid
> to me. Please note, however, that Host's timezone is used and that
> might not be what you intended. In such case another parameter that
> specifies timezone should be added.
>
> Please fill SF.net ticket(or tickets, because these are two separate
> things!) for this. If you don't have SF.net account/access, please,
> say so.
>
> Thanks and regards,
> Z.
>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Ipmitool-devel mailing list
>> Ipmitool-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to