https://bugzilla.samba.org/show_bug.cgi?id=2607 ------- Additional Comments From paul@debian.org 2005-04-14 07:32 ------- What timezone is your system running in? -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
https://bugzilla.samba.org/show_bug.cgi?id=2607
wayned@samba.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From wayned@samba.org 2005-04-14 09:50 -------
You don't mention if you're using syslog() or direct-to-file logging.
Also, I
assume you have chroot enabled.
Rsync makes sure that it calls localtime() before it calls chroot(), so this
should ensure that it has loaded the local timezone before all the /etc files
vanish via chroot(). In the syslog case, the timestamp is out of rsync's
control, but rsync does also call openlog() before it calls chroot().
If you're using syslog, is syslogd running?
If the problem is a direct-to-file logging, try running a program that just
calls localtime() on a time_t of the current time, calls chroot(), and then
calls strftime(). If that has the same timezone problem, it would be good to
file a bug report with your C library provider.
Another work-around might be to set TZ in your environment (e.g. TZ=PST8PDT).
This all works fine for me under Debian Sarge (with or without TZ set).
Let me know if you can't figure out what's wrong.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
https://bugzilla.samba.org/show_bug.cgi?id=2607 ------- Additional Comments From kilburna@iservnetworks.com 2005-04-14 18:13 ------- I am using direct-to-file logging. My BIOS setting is local. My rc.conf is set CLOCK="local". I also set TZ='Australia/Sydney'; export TZ in profile. Also set lrwxrwxrwx 1 root root 36 Apr 15 10:51 /etc/localtime -> /usr/share/zoneinfo/Australia/Sydney which is how Gentoo sets the timezone. After transfer, the localtime() is always using UTC (off by 10 hrs) 2005/04/15 11:00:45 [7209] name lookup failed for 192.168.1.250: Name or service not known 2005/04/15 11:00:45 [7209] rsync to test from support#iservnetworks.com@unknown (192.168.1.250) 2005/04/15 01:00:46 [7209] sent 69 bytes received 695 bytes total size 11321603 Any help would be appreciated. Might be a C lib issue. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
https://bugzilla.samba.org/show_bug.cgi?id=2607
------- Additional Comments From wayned@samba.org 2005-04-15 08:41 -------
Created an attachment (id=1163)
--> (https://bugzilla.samba.org/attachment.cgi?id=1163&action=view)
Output timestamp after a chroot call
Try this program out. If it fails to output the current time, file a bug
report with gentoo about it. If it succeeds, let me know.
Also, try the TZ work-around again, but format it like the example in comment
#2 -- you need two timezone abbreviations surrounding an offset from UTC. For
instance, this works for me:
export TZ=AST-10ADT
I don't know if the abbreviations are right, so use whatever is output by
"date" for your timezone -- put the standard-time abbreviation first,
and the
datelight-savings-time abbreviation second (or omit it if you don't go on
daylight-savings-time).
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
https://bugzilla.samba.org/show_bug.cgi?id=2607 ------- Additional Comments From kilburna@iservnetworks.com 2005-04-15 22:42 ------- Here is the output of the your program. It gives the correct time. tux tmp # gcc -o tztest tztest.c tux tmp # ./tztest 2005/04/16 15:13:25 current time I have also written a short C prog, similar to yours, and it too gives the correct time result. The I wrote a perl script and it gives the correct time. I spent a lot of time digging into forums, and this problem has surfaced many times, but there has been no definitive solution. I have built a completely new box and the problem still occurs. I look after a 1TB storage and logging is used extensively. I changed to chroot=no and the logging time is fine. I will look into the code, but the problem seems to centred around chroot and glibc. I know that I upgraded glibc and then this issue started. I also tried the TZ=UTC10EST nad other combinatiins with no difference. I also used zic to create a new timezone file with no difference -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
https://bugzilla.samba.org/show_bug.cgi?id=2607 ------- Additional Comments From vanes002@umn.edu 2005-04-17 02:02 ------- So - to which version of glibc did you upgrade when this problem started? I looked at the localtime/timezone related sources in http://ftp.gnu.org/pub/gnu/glibc/glibc-2.3.4.tar.gz and as long at the TZ envariable does not change and tzset() is not explicitly called, then the timezone info from the first localtime() is retained and no further filesystem access is needed (that's how it's also worked in the past). My guess is that the TZ variable is being clobbered/modified somehow. Try this (as root) to see the parent daemon environment: cat /proc/`cat /var/run/rsyncd.pid`/environ Then, start a child process by starting a transfer via your daemon that will take a long time so you can look at the environment for the child. Tail the rsyncd log to get the child PID and do cat /proc/_PID_/environ You don't have to report the whole environ content - just look for TZ= and report what it has for a value in both cases. The TZ envariable isn't needed as long as you have /etc/localtime set properly. So try this - in your rsyncd init script, before starting the daemon, insert unset TZ so the daemon starts without a TZ variable and restart the daemon (also restore chroot = yes in your config). This should prevent any enviroment change from affecting the timezone processing. Then try a transfer and see if the child timestamp is now OK. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
Apparently Analagous Threads
- [Bug 2607] New: Rsync logging time incorrectly
- DO NOT REPLY [Bug 4318] New: automatic module creation with rights on server
- DO NOT REPLY [Bug 4402] New: Incorrect time logged with glibc 2.5
- problem running test on a system without /etc/localtime
- Another issue with Sys.timezone