Archive
Highlighted

Invalid latest_time: latest_time must be after earliest_time

Explorer

Hi - I've just installed splunk-5.0-140868 for Solaris 10 SPARC. The setup was very easy and as soon as I logged in I switched the license from TRIAL to FREE.

I then added the local servers "messages" file which is in the syslog format. No problem with this but whenever I use the Search facility where the Search is - source="/var/adm/messages" I get the error:

Invalid latesttime: latesttime must be after earliest_time.

Any ideas why I get this?

I've tried adding some other log files all from the local server and they also give the same error.

Thanks - Julian.

Tags (1)
0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Path Finder

I had this same problem on Splunk v4.3.2 and once I upgraded to v4.3.3, it went away. If this has returned on v5, I guess I won't be upgrading.

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Explorer

Ah I've just realised that after adding new data and then clicking on the search link and selecting a source - ie., /var/adm/messages - if the drop down list on the top right is set to "Custom time" it gives this error. If I select anything else, last 15mins, last 60mins etc it works fine.

So something about the "Custom time" which is the default setting is causing this, wonder if I can just change it so this is not the default option.

Thanks - Julian.

View solution in original post

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Splunk Employee
Splunk Employee

It's always going to be the case that Splunk will enforce a "latest time after earliest time" condition. To reverse the two is non-sensical. No events in a time-based series are going to simultaneously be before time X and after time X + 5.

The issue you're seeing is probably related to viewstates--the notes that Splunk keeps internally to help present the same view "as last time". So if you clicked on an event (drilldown, or used the custom time range picker) to view some messages, and somehow the earliest and latest markers were reversed, Splunk is going to remember that. The fact that your time picker read "custom time" is further evidence of that.

As you've already noted, just use the time picker to select a valid time range, and everything will be happy.

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Explorer

OK, is there a way to get rid of this behaviour? As in if I did something to cause how do I fix it, it's really annoying. I don't care what time range it displays just as long as I don't get this error on screen.

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Splunk Employee
Splunk Employee

The state of the time picker is saved in the 'viewstates.conf' file for the combination of user / app / view. So for example, I have this value in $SPLUNK_HOME/etc/users/admin/sos/local/viewstates.conf:

[splunk_ps:_current]
TimeRangePicker_0_3_0.default = Last 7 days

You can safely remove viewstates.conf for your user / app (containing state for all of the views in that app) combo and the error should go away.

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Explorer

Ah right thanks, should have said I'd tried amending viewstates.conf for the relevant user and it made no difference at all. Did the ./splunk stop | start as well.

I've just moved ./etc/users/admin/search/local/viewstates.conf out of the way and done a restart and I still get the same result.

"Invalid latesttime: latesttime must be after earliest_time"

Also just upgraded to the latest version and made no difference.

0 Karma
Highlighted

Re: Invalid latest_time: latest_time must be after earliest_time

Path Finder

In poking through the returned data - when it did work it looks like the format should be.

YYYY-MM-DDTHH:MM:SS

Example: 2015-05-02T07:30:00

You can also append your timezone at the end as well. Really this is way harder than it should be.

0 Karma