About mitch

mitch · ‎03-16-2011

Yeah, looks like a change in the 4.2 timeframe busted that. I'll make sure it gets fixed for 4.2.1

mitch · ‎03-10-2011

Jason -- at least of the reports that we've seen several seem to have popped up when enabling LDAP auth. Other crash reports didn't have LDAP at all. We've also successfully run LDAP on SuSE 11 with splunk 4.1.6 in-house, without problems. So you're right -- the bug in SuSE's libc isn't related to LDAP. However, it does seem that using LDAP changes the timing of things to help provoke the crash for some environments.

mitch · ‎03-09-2011

Hi. I finally have a good answer for your question. Over the last several months we saw a slow trickle of reports of this crash, but we never had enough information to isolate it. What made it more frustrating is that it seemed to happen to just a few customers, and even for them it seemed to be hard to reproduce.. sometimes they would have splunk crash several times in a row then the problem would suddenly disappear for no apparent reason. Finally we had enough reports to piece together the common thread: all of the reports are running 64-bit SuSE 11 of some sort. After a LOT of investigation we found out that it's due to a known bug in SuSE which Novell is planning to fix for OpenSuSE 11.4. They'll presumably also fix it in a future SLES version as well. The good news is that we have identified a workaround to splunk that lets us avoid this bug and will include it in all future versions of splunk (i.e. newer than "4.1.7" which is current as of this writing) If this crash is happening often enough to cause you serious problems (and you can't wait for the next splunk release) you may want to get an early-access testing build from splunk support. Please reference bug "SPL-37331" so they know what issue you're referring to. Again, this is ONLY for 64-bit SuSE installs: no other OSes are affected by this issue.

mitch · ‎07-28-2010

I'm not sure what you mean by "8.2"... maybe "Solaris 8 2/04"? But anyway, we currently support Solaris 8 only on SPARC. Our Intel Solaris packages require Solaris 9 or above.

mitch · ‎07-28-2010

I agree with Lowell above -- if it's exactly an hour off it's probably not a time extraction issue, but a timezone issue. Info that would be useful: * Do a search that finds that single event and then add "| eval t=_time | table t" to the search. You should see the raw UNIX epoch time (i.e. seconds since Midnight 1/1/1970, GMT). What number do we report that for that event. It'll be a number around 1.2 billion. * What OS are you running? * What version of Splunk? * What timezone are you in? How specifically is it configured in the OS?

mitch · ‎07-23-2010

...although be aware that file will get replaced each time you upgrade Splunk. You'll have to re-apply.

mitch · ‎07-23-2010

Yeah, looks like a bug. On AIX, "splunk enable boot-start" adds splunkd and splunkweb to SRC. Unfortunately the way that it does it probably won't respect the "disable webserver" setting because once its in SRC, bin/splunk isn't the one doing the launching and it doesn't get a chance to apply that setting. I'll have to think about how to handle this one. It should be easy to manually fix on the box if you just do a: # rmssys -s splunkweb to remove splunkweb from SRC

mitch · ‎07-22-2010

If you want to have it do time extraction at index-time it IS possible, but only if you're willing to set up custom a custom datetime.xml file. The easier-to-use TIME_FORMAT setting doesn't have any way to specify hexadecimal numbers, so you have to get down and dirty with some XML to make it happen. Also, you'll need to be running Splunk 4.1.4 — earlier versions had more limited support for hex epoch values. You'll need a datetime.xml file that make a regex to match the timestamp and extract it as "hexepoch". Lets call it $SPLUNK_HOME/etc/my-hex-epoch.xml: <datetime> <define name="_hexepoch" extract="hexepoch"> <text><![CDATA[([\da-fA-F]{8})]]></text> </define> <timePatterns> <use name="_hexepoch"/> </timePatterns> <datePatterns> </datePatterns> </datetime> Then in props.conf you'd configure the sourcetype as: DATETIME_CONFIG = /etc/my-hex-epoch.xml MAX_TIMESTAMP_LOOKAHEAD = 8

mitch · ‎07-22-2010

Yeah, it looks like a tonumber() function is a badly needed addition to the language. I'm going to file a bug report right now. The one (gross) workaround that I can think of is to abuse the strptime() time parser. This would only work on non-negative integers, but it might be enough for your immediate issue: $ splunk search '* | head 1 | eval a="0001L" | eval b="0002L" | eval c=strptime(rtrim(a,"L"),"%s") + strptime(rtrim(b,"L"),"%s") | table a b c' a b c ----- ----- -------- 0001L 0002L 3.000000

Posts	9
Solutions	3
Karma Given	1
Karma Received	14
Member Since	‎07-22-2010

Online Status	Offline
Date Last Visited	‎06-05-2020 02:02 AM

Re: 4.2 upgrade on PPC Mac - "Bad CPU type in exec...

Re: Linux - splunkd v4.1.4 crash with LDAP authent...

Re: Linux - splunkd v4.1.4 crash with LDAP authent...

Re: Splunk 4.0.9 on Solaris 8.2

Re: Splunk Time stamp Error

Re: Can I change the splunk favicon per instance?

Re: disable webserver ignored on AIX?

Re: hex encoded unix timestamp?

Re: How to force "eval" to cast an expression as n...