/etc/default
The directory /etc/default
is never used on any Red Hat based distros. That's a Debian/Ubuntu-ism. For Centos 7 you can take a look at the packages that were installed that relate to fail2ban
like so:
$ rpm -aq|grep fail
fail2ban-server-0.9-9.el7.noarch
fail2ban-sendmail-0.9-9.el7.noarch
fail2ban-firewalld-0.9-9.el7.noarch
fail2ban-systemd-0.9-9.el7.noarch
fail2ban-0.9-9.el7.noarch
Contents of fail2ban-server
The fail2ban-server
contains the service file for Systemd.
$ rpm -ql fail2ban-server-0.9-9.el7.noarch | grep systemd
/usr/lib/python2.7/site-packages/fail2ban/server/filtersystemd.py
/usr/lib/python2.7/site-packages/fail2ban/server/filtersystemd.pyc
/usr/lib/python2.7/site-packages/fail2ban/server/filtersystemd.pyo
/usr/lib/systemd/system/fail2ban.service
Systemd service file
The contents of the Systemd service file:
$ more /usr/lib/systemd/system/fail2ban.service
[Unit]
Description=Fail2ban Service
After=syslog.target network.target firewalld.service
[Service]
Type=forking
ExecStart=/usr/bin/fail2ban-client -x start
ExecStop=/usr/bin/fail2ban-client stop
ExecReload=/usr/bin/fail2ban-client reload
PIDFile=/var/run/fail2ban/fail2ban.pid
Restart=always
[Install]
WantedBy=multi-user.target
So one could add the extra options to this file, as a quick and dirty way to confirm if they're working.
Long term fixes
To make them permanent, I'd add the options in a more "official" way so that updates to the fail2ban
package do not overwrite the modifications to this file. This can be accomplished by adding a customized version of the fail2ban.service
file in this directory:
/etc/systemd/system/fail2ban.service
NOTE: A file in this directory, /etc/systemd/system
always overrides the default .service
file.
However doing it this way have caveats, one being that if a service file is present here when fail2ban
were to be updated via yum
it would cause the service to be disabled, until you manually reenabled it. So instead you can override fragments of the .service
file by adding them to this directory under /etc
instead.
Excerpt
To edit a unit file provided by a package, you can create a directory
called /etc/systemd/system/unit.d/ for example
/etc/systemd/system/httpd.service.d/ and place *.conf files in there
to override or add new options. systemd will parse these *.conf files
and apply them on top of the original unit. For example, if you simply
want to add an additional dependency to a unit, you may create the
following file: /etc/systemd/system/unit.d/customdependency.conf
[Unit]
Requires=new dependency
After=new dependency
As another example, in order to replace the ExecStart directive for a
unit that is not of type oneshot, create the following file:
/etc/systemd/system/unit.d/customexec.conf
[Service]
ExecStart=
ExecStart=new command
so you could create a directory, /etc/systemd/system/fail2ban.service.d
and add *.conf
files in it with contents like this:
[Service]
ExecStart=
ExecStart=new command
Adding your options there.
Ulimits & Systemd
If you're trying to set a ulimit
option for a particular service, then have a look at the man page for systemd.exec
.
Excerpt
LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=,
LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=,
LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=
These settings control various resource limits for executed processes. See
setrlimit(2) for details. Use the string infinity to configure no limit
on a specific resource.
So simply adding LimitSTACK=256
to the customized .conf
file that I describe above should give you the same effect as setting ulimit -s 256
.
Excerpt - setrlimit(2) man page
If you have a look through the setrlimit(2)
man page you can see how the ulimit
switches line up with the Systemd limits.
RLIMIT_STACK
The maximum size of the process stack, in bytes. Upon reaching
this limit, a SIGSEGV signal is generated. To handle this signal,
a process must employ an alternate signal stack (sigaltstack(2)).
Since Linux 2.6.23, this limit also determines the amount of space
used for the process's command-line arguments and environment
variables; for details, see execve(2).
References
Best Answer
For anyone else running into the same issue, my problem was indeed caused by Dell Servers being picky about memory module placement. I had originally placed the 4 pairs of 4GB modules in slots 3 & 4 of all four memory risers (the original 4 pairs of 2GB modules I left in slots 1 & 2 of the memory risers).
However, for whatever reason Dell Servers don't work that way. What solved the problem was for me to place the pairs of 4GB modules in slots 1 & 2 in each riser and move the pairs of 2GB modules to slots 3 & 4.
I hope that helps someone else running into the same problem. Though, knowing now that this wasn't an error in kernel config, this question should probably be moved to ServerFault.