Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 579168 - net-analyzer/fail2ban: cannot start on systemd
Summary: net-analyzer/fail2ban: cannot start on systemd
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Netmon project
URL:
Whiteboard:
Keywords: PATCH
: 601424 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-04-06 14:43 UTC by Alexey Korepanov
Modified: 2019-03-27 10:10 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for fail2ban-0.9.4 (fail2ban.run.patch,409 bytes, patch)
2016-04-11 21:49 UTC, Alexey Korepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Korepanov 2016-04-06 14:43:39 UTC
Starting fail2ban in systemd fails with error:
ERROR  There is no directory /run/fail2ban to contain the socket file
/run/fail2ban/fail2ban.sock.

I tried fail2ban versions 0.9.3-r1 and 0.9.4 with the same results.

While /run/fail2ban is created by openrc ebuild, this is ignored in 
systemd service. I am not sure about how this should be done,
on arch linux forums there is a solution to create a file
  /etc/tmpfiles.d/fail2ban.conf
with one line:
  D /run/fail2ban 0755 root root -

Reproducible: Always

Steps to Reproduce:
1. systemctl start fail2ban
2. ???
3. PROFIT
Comment 1 Alexey Korepanov 2016-04-11 21:25:54 UTC
Another solution I found is to add a line

ExecStartPre=/bin/mkdir -p /run/fail2ban

to the systemd unit file. Or to add

RuntimeDirectory=fail2ban

to the systemd unit file.
Comment 2 Alexey Korepanov 2016-04-11 21:49:06 UTC
Created attachment 430190 [details, diff]
Patch for fail2ban-0.9.4

This is a really simple patch for fail2ban-0.9.4 that fixes the problem. Patch for 0.9.3 would be different, because systemd unit file is different.

Note that this patch has to be applied *before* /var/run -> /run replacement in the ebuild.
Comment 3 Mike Gilbert gentoo-dev 2016-04-12 14:43:40 UTC
(In reply to Alexey Korepanov from comment #1)

Either method would work, though I personally prefer the RuntimeDirectory approach.
Comment 4 Alexey Korepanov 2016-04-12 15:13:44 UTC
I am a bit suspicious of RuntimeDirectory, I do not know what systemd does with

RuntimeDirectory=fail2ban

if the folder /run/fail2ban already exists (is created by tmpfiles.d).
Comment 5 Mike Gilbert gentoo-dev 2016-04-12 17:48:29 UTC
So test it?
Comment 6 Alexey Korepanov 2016-04-12 19:07:20 UTC
Ok, I tested it. If the directory exists, then it is happily used, and after the service stops it is removed. But I couldn't find this behaviour documented. That is, I don't expect a problem, but using RuntimeDirectory is somewhat less clear than mkdir. Personally I'd be fine with both, but would prefer mkdir :-)
Comment 7 Mike Gilbert gentoo-dev 2016-04-12 19:52:23 UTC
(In reply to Alexey Korepanov from comment #6)

Oh, we already install a tmpfiles fragment for this.

/usr/lib/tmpfiles.d/fail2ban-tmpfiles.conf

So you either need to reboot or run the following after installation:

systemd-tmpfiles --create fail2ban-tmpfiles.conf

A better solution would be to have upstream replace the tmpfiles fragment with the RuntimeDirectory setting.
Comment 8 Alexey Korepanov 2016-04-12 20:01:40 UTC
OK, thank you. I didn't notice that tmpfiles.d file is already installed, and I did not reboot for a very long time.

I created an issue on fail2ban's github 5 days ago
https://github.com/fail2ban/fail2ban/issues/1384
Comment 9 Pacho Ramos gentoo-dev 2017-02-28 19:53:41 UTC
*** Bug 601424 has been marked as a duplicate of this bug. ***
Comment 10 Alexey Korepanov 2018-04-05 19:46:24 UTC
This has been fixed in fail2ban-0.10
https://github.com/fail2ban/fail2ban/pull/1618/commits/1cd67ecaa260bdaa6e62383ed783d5910587c258

But 0.10 is not yet stable. When it is stabilized, this bug is resolved.
Comment 11 Jeroen Roovers (RETIRED) gentoo-dev 2019-03-27 10:10:59 UTC
(In reply to Alexey Korepanov from comment #10)
> This has been fixed in fail2ban-0.10