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
