https://bugzilla.samba.org/show_bug.cgi?id=2607
------- Additional Comments From [EMAIL PROTECTED] 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. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
