[pfSense Support] Date Change Bug

[Nathan Eisenberg]

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.

Restarting this box is pretty difficult, although I am confident that a reboot 
would fix the issue.  Do I have any other options?

Best Regards,
Nathan Eisenberg
Atlas Networks, LLC
Phone: 206-577-3078
supp...@atlasnetworks.us
www.atlasnetworks.us

RE: [pfSense Support] Date Change Bug

[Christopher Iarocci]

What did you change it to?  If you chose a GMT -X setting, they don't work
properly.  You have to choose a location time zone, not just the GMT + or -
setting.

 

Christopher Iarocci

Network Solutions Manager

Twin Forks Office Products

631-727-3354

 

From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us] 
Sent: Sunday, February 15, 2009 6:59 PM
To: support@pfsense.com
Subject: [pfSense Support] Date Change Bug

 

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.

 

Restarting this box is pretty difficult, although I am confident that a
reboot would fix the issue.  Do I have any other options?

 

Best Regards,

Nathan Eisenberg

Atlas Networks, LLC

Phone: 206-577-3078

supp...@atlasnetworks.us

www.atlasnetworks.us

 

Re: [pfSense Support] Date Change Bug

[Bill Marquette]

On Sun, Feb 15, 2009 at 5:58 PM, Nathan Eisenberg
 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

Re: [pfSense Support] Date Change Bug

[Bill Marquette]

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
 wrote:
> On Sun, Feb 15, 2009 at 5:58 PM, Nathan Eisenberg
>  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

RE: [pfSense Support] Date Change Bug

[Nathan Eisenberg]

That's what I discovered - I had originally set it to GMT -8, and it is now 
America/Los Angeles

Best Regards,
Nathan Eisenberg
Atlas Networks, LLC
Phone: 206-577-3078
supp...@atlasnetworks.us<mailto:supp...@atlasnetworks.us>
www.atlasnetworks.us<http://www.atlasnetworks.us>

From: Christopher Iarocci [mailto:ciaro...@tfop.net]
Sent: Monday, February 16, 2009 5:46 AM
To: support@pfsense.com
Subject: RE: [pfSense Support] Date Change Bug

What did you change it to?  If you chose a GMT -X setting, they don't work 
properly.  You have to choose a location time zone, not just the GMT + or - 
setting.

Christopher Iarocci
Network Solutions Manager
Twin Forks Office Products
631-727-3354

From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us]
Sent: Sunday, February 15, 2009 6:59 PM
To: support@pfsense.com
Subject: [pfSense Support] Date Change Bug

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.

Restarting this box is pretty difficult, although I am confident that a reboot 
would fix the issue.  Do I have any other options?

Best Regards,
Nathan Eisenberg
Atlas Networks, LLC
Phone: 206-577-3078
supp...@atlasnetworks.us<mailto:supp...@atlasnetworks.us>
www.atlasnetworks.us<http://www.atlasnetworks.us>