Logs won't be fixed short of a reboot, unless you like monkeying around in the shell. Syslog records it's offset from GMT when it starts up.
--Bill On Mon, Feb 16, 2009 at 8:17 AM, Bill Marquette <bill.marque...@gmail.com> wrote: > On Sun, Feb 15, 2009 at 5:58 PM, Nathan Eisenberg > <nat...@atlasnetworks.us> wrote: >> Hello, >> >> >> >> I recently changed the timezone on one of our PFSense boxes, as it thought >> it was 12 hours ahead of where it actually is. Since I have made that >> change, states do not appear to be expiring normally, and the logs are still >> labeled with the old date/time offset. However, the result of 'date' in the >> command line is correct. > > Short answer: don't do that. > > Long answer: > Yeah, don't change dates on a running unix system unless you plan on > restarting all services afterwards. At best, what you did is > increased the expiration time on all states by 12 hours (including > states that would normally have expired in say 30 seconds). At worst, > you also are no longer running the kernel thread that cleans up states > (well, at least for the next 12 hours - by the time you read this, > your system might actually be back to normal). > >> Restarting this box is pretty difficult, although I am confident that a >> reboot would fix the issue. Do I have any other options? > > Wait it out, assuming you don't run out of state table entries and > hose the box first. It'll either recover once it catches up to the > date it _used_ to have, or you'll be rebooting it. > > --Bill > --------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
