[lug] help with zic?

rm at mamma.varadinet.de rm at mamma.varadinet.de
Thu Jan 18 02:12:52 MST 2001


On Thu, Jan 18, 2001 at 12:03:02AM -0700, D. Stimits wrote:
> Justin wrote:
> > 
> > I posted about this problem a little bit ago but was not able to fix the
> > problem. When I do a 'uname -a' this is my output:
> > root at newschool:/etc/rc.d# uname -a
> > Linux newschool 2.4.0 #1 Sun Jan 14 17:56:03 Local time zone must be
> > set--see zic manuai686 i686 unknown
> > I cannot seem to get the localtime set with the zic program. I have
> > tried doing 'timeconfig', setting the time w/ the 'date' command, and
> > also many variations of zic (such as zic -d /usr/share/zoneinfo, zic -l
> > /usr/share/zoneinfo/US/Mountain) Non of these has resolved the issue,
> > and I'm running out of ideas. Anyone have any other ideas?
> > 
[...]
> 
> Does timetool work to alter time? And if the zic command (which I'm not
> familiar with) fails, try an strace log to see what it dies at:
> strace -oziclog.txt zic

Hmm, i doubt that zic itself has a problem. Zic is needed when you 
need to compile your own timezone information file, something that
a normal Linux user shouldn't need -- have a look at /usr/share/zoneinfo,
there should be a pile of zone info files. Usually there's a link from
'/etc/localtime' to one of the zone info files in this directory tree.

#1 Sun Jan 14 17:56:03 Local time zone must be set--see zic manuai686 i686 unknown
                       |                                         |
                       *-----------------------------------------*
		             |
 This looks like the output of 'uname' got intermixed with the error message
 created from another program/library call. I assume if you redirect 
 stderr to a file the output of uname will look different ('uname -a 2> /tmp/log').
 
 What happens if you set you TZ environment variable expicitly? (man 3 tzset
 gives some info on the time zone setup BTW)?


> There'll be a lot of output, but you can assume any answers are probably
> in the last 20% or so. And even then, lines that end with = 0 will be
> success and mostly ignorable.

I would strace uname instead. But since strace only traces system calls
this might not show the problem, ' strace -v -ff -e trace=open uname -a '
will show you what files 'uname' does attempt to open. A better tool
would be 'ltrace' (you might need to install it). This will show library
calls  (and system calls if used with the '-s' switch).

 Ralf





More information about the LUG mailing list