systemd replaces SysV init scripts and some Linux distributions are migrating to or currently support systemd (such as Arch Linux). The traditional start-up script /etc/init.d/splunk (or /etc/rc.d/splunk) does not work in a pure systemd configuration, a unit file is required.
This thread is getting outdated. See the official documentation and additional information below:
- https://docs.splunk.com/Documentation/Splunk/7.2.6/Admin/RunSplunkassystemdservice
- https://docs.splunk.com/Documentation/Splunk/7.2.6/Workloads/Configuresystemd
- https://answers.splunk.com/answers/738877/splunk-systemd-unit-file-in-versions-722-and-newer.html
- https://www.duanewaddle.com/splunk-7-2-2-and-systemd/
There is now official documentation on this:
https://docs.splunk.com/Documentation/Splunk/8.0.3/Admin/RunSplunkassystemdservice
Is there an officially supported way to do this for Splunk 6.5.x that doesn't involve cutting and pasting from 10 different postings?
jmanto -- the direct answer to your question is No, there is NO official support for SystemD in Splunk prior to Splunk 7.2.
Also please keep in mind that Splunk 6.5.x has been EOL'ed and is no longer Supported. Please make sure to upgrade to either Splunk 7.2 or Newer for continued Splunk Support and for SystemD Support.
Um, no. According to the document below 6.5 is not EOL yet.
https://www.splunk.com/en_us/legal/splunk-software-support-policy.html
We pay quite a bit of money for support, so why do we have to chase down things like this for a supported version of Splunk?
Covers an answer on getting this working nicely, just adding it to here as this is one of the highest results in google
Covers an answer on getting this working nicely, just adding it to here as this is one of the highest results in google
On a fresh installation of CentOS/Redhat the following command works for me:
systemctl enable splunk
Systemd is now officially supported in Splunk 7.2.2
https://docs.splunk.com/Documentation/Splunk/7.2.2/Admin/RunSplunkassystemdservice
Splunkd is not able to automatically translate the ./splunk start|stop commands to systemctl start|astop command.
I am using 7.2.3 splunk install in Linux environment
I've also tested 7.2.3 and 7.2.4 and can confirm that splunk stop/start becomes systemctl stop Splunkd, systemctl start Splunkd
Note that the sudo permissions are not there so in many environments it will fail, it would be nice if it ran:
sudo systemctl stop Splunkd
As that would resolve the issue for many customers (7.2.4 does not have this feature, perhaps a future version will)
See other comments in here re: polkit, which will solve the problem of requiring root auth level.
@twinspop, tested on Oracle/RHEL 7.5 and it does not support determining the unit file in polkit. Therefore I can de-secure systemd by allowing the splunk user to run systemctl stop (or start anything)
Your solution would work if I had a modern version of polkit
Buried in WLM set-up is a suggested systemd service file. But it never worked for me. It always popped up an authentication request. For it to work, I had to modify polkit settings as below, minding the ordering of the files. Finally I have a working, fully functional systemd set-up for splunk. That was easy(tm).
// place in /etc/polkit-1/rules.d/50-splunk-service.rules
// polkitd will reload automatically
polkit.addRule(function(action, subject) {
var debug = true;
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "Splunkd.service" &&
subject.user == "splunk") {
return polkit.Result.YES;
}
});
I had to remove this line for it to work:
action.lookup("unit") == "Splunkd.service" &&
for some reason my "splunk start/stop" commands are not passing the unit variable (i did a log test which shows this as undefined). This is insecure for the moment but works for my test environment. Does anyone have any better suggestions?
As far as I know, the action.lookup
is only available in systemd >=226. CentOS/RHEL 7 ship with 219, so if you're using that, this is the reason. Current Debian stable ships 232, so you should be good there 🙂
Adding my confirmation that removing the unit lookup line fixed the issue.
Confirmed that I also needed to remove that line.
@compyy23 --> Yes the following Splunk Command will work:
./splunk enable boot-start -user splunk
This command set will create an init.d Script (/etc/init.d/splunk) that will be used by SystemD for the starting/stopping/restarting of Splunk during boot & reboot times or anytime you issue:
systemctl start splunk.service
systemctl stop splunk.service
systemctl restart splunk.service
There are several examples of unit Files for SystemD that could be used, such as the 1 I have posted above that I have personally been using for almost 1 year in my Splunk Repro Environment. This Environment consists of CentOS 6.9 & 7.5 Instances. The 7.5 Instances have been updated to use SystemD Unit files instead of the init.d Script and after a year of running Splunk with the unit file I posted earlier in this Answers Post, there have not been any issues seen.
Hopefully this information helps and gets you pointed in the "right direction".
Here is the script 7.2.2 creates with splunk enable boot-start -user splunk, since I didn't see it loaded anywhere:
#This unit file replaces the traditional start-up script for systemd
#configurations, and is used when enabling boot-start for Splunk on
#systemd-based Linux distributions.
[Unit]
Description=Systemd service file for Splunk, generated by 'splunk enable boot-start'
After=network.target
[Service]
Type=simple
Restart=always
ExecStart=/opt/splunk/bin/splunk _internal_launch_under_systemd
LimitNOFILE=65536
SuccessExitStatus=51 52
RestartPreventExitStatus=51
RestartForceExitStatus=52
User=splunk
Delegate=true
MemoryLimit=100G
CPUShares=1024
PermissionsStartOnly=true
ExecStartPost=/bin/bash -c "chown -R splunk:splunk /sys/fs/cgroup/cpu/system.slice/%n"
ExecStartPost=/bin/bash -c "chown -R splunk:splunk /sys/fs/cgroup/memory/system.slice/%n"
[Install]
WantedBy=multi-user.target
I am running Centos 7.5 and old way of boot enable still working ? what is the difference here ?