UPDATED Ended up changing the configuration once again. Removed the filterType= and blacklist= stanzas all together to get the configuration working properly. I used the filterType=blacklist stanza which worked but ended up breaking the machineTypes filter further into the configuration. Upon removing filterType=blacklist and blacklist.0=* the clients are properly parsing through the serverclass.conf file and receiving the proper apps and configurations for those apps. So my configuration ends up as below. [serverClass:aa] repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/aa/ whitelist.0=aa [serverClass:aa:app:SplunkLightForwarder] repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/aa/ stateOnClient = enabled restartSplunkd = true [serverClass:aa:app:sample_app] stateOnClient = disabled [serverClass:aa:app:gettingstarted] stateOnClient = disabled [serverClass:aa:app:windows] repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/aa/ machineTypes = windows-intel,windows-x64 restartSplunkd = true [serverClass:aa:app:unix] repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/aa/ machineTypes = linux-i686,linux-x86_64,freebsd-i386,sunos-sun4u restartSplunkd = true ... View more

The OTHER field represents groupings that are not in the top N most prevalent groups. For example, if you run a search like: search ... | timechart count by host the max number of host fields that would be returned by timechart is 10. If you have 25 distinct host s in your dataset, then the 15 least populous host s would be coalesced into OTHER . There are 2 ways to deal with this: Disable the use of OTHER by adding a useother=f parameter: search ... | timechart count by host useother=f This will generate a field for every host found in the dataset. Increase the threshold for OTHER grouping: search ... | timechart count by host where count in top50 This will generate a field for every host , up to 50. If there are more than 50, those excess will then be grouped into OTHER . There is a similar grouping call NULL , which can be disabled by using the usenull=f option. These parameters are available on both the timechart and chart command. For more information, see the search reference on timechart. ... View more

I assume you mean the script which ends up as /etc/init.d/splunk or similar? This thing invokes the launcher (bin/splunk) and passes its return values along. The values don't appear to be that useful right now. 0 obviously is success. 4 seems to suggest permissions problems 8 refers to environment problems The new 4.1 command line work incorporates this table: #define EXIT_NO_ARGS 8 #define EXIT_CMD_IGNORE 9 #define EXIT_FAILURE_USAGE 10 #define EXIT_FAILURE_DEPRECATED_CMD 11 #define EXIT_FAILURE_PARSE_CMD_LINE 12 #define EXIT_FAILURE_NO_HELP_EXISTS 14 #define EXIT_FAILURE_NO_DISPLAY_FUNC 15 #define EXIT_FAILURE_NO_CMD_EXISTS 16 #define EXIT_FAILURE_NOT_IMPLEMENTED 18 #define EXIT_FAILURE_NO_OBJ_EXISTS 19 #define EXIT_FAILURE_FGETS_READ 20 #define EXIT_FAILURE_REQD_ARG_MISSING 21 #define EXIT_FAILURE_REST_CALL 22 #define EXIT_FAILURE_DISPLAY_FUNC_ERR 23 #define EXIT_FAILURE_LOGIN 24 #define EXIT_FAILURE_URI_FORMAT 25 However we incorporate third party libraries. For example in some circumstances openssl (how the splunk executable communicates with splunkd) will exit(2) on its own. Compiling a complete list right now is not likely to be useful. Instead I would suggest: Try launching splunk yourself, ideally with the same user that the script does, or run the script yourself (sh -x -v /etc/init.d/splunk start) to see what happens. Review $SPLUNK_HOME/var/log/splunk/splunkd_stderr.log and splunkd.log ... View more