[BR]: STDIN is closed and triggers libuv error in external programs during actionban about fail2ban HOT 8 CLOSED

i recently noticed that i was not getting any output from this command, even though it performs as expected from the terminal.

What does it mean exactly? Only output of host is missing, but everything other in action work?
Or the whole action doesn't work?
If the it is the last, don't you see some errors in fail2ban.log (please provide the whole excerpt, starting with Ban ... up to error-message).

Alternatively would not this help?

host <ip> 2>/dev/null

FYI, instead of host command, you can simply use the tag <ip-host>, it'd resolve the hostname of ` directly in fail2ban without to invoke external command.
Here is the whole list of dynamic and ticket-related tags for 0.11.2 or last master

Just not forget to replace your _host_command in action (the invocation-chars `` belongs into _host_command itself, because otherwise it'd try to execute result of <ip-host>)

- `%(_host_command)s`\n
+ %(_host_command)s\n

and

# _host_command = `%(_host)s`
_host_command = <ip-host>

Also you don't really need this include in mail-host action - you can set it directly from jail.local:

# either in default:
action_mh = %(action_)s
            %(mta)s-host[sender="%(sender)s", ... , _host_command="<ip-host>"]
...
# or in jail:
[my-custom-jail]
#action   = %(action_mh)s[_host_command="`some-command <ip> 2>/dev/null`"]
action   = %(action_mh)s[_host_command="<ip-host>"]

By the way, mailing actions, not to mention such with a whois or host-resolve, are not recommended - they may generate large delays (up to timeout) and so unexpectedly retard the further bans (for other ips).

from fail2ban.

i recently noticed that i was not getting any output from this command, even though it performs as expected from the terminal.

What does it mean exactly? Only output of host is missing, but everything other in action work? Or the whole action doesn't work? If the it is the last, don't you see some errors in fail2ban.log (please provide the whole excerpt, starting with Ban ... up to error-message).

sorry for not being clear. the rest of the command works as expected and the mailing succeeds. there are simply blank lines in the message where the output of host <ip> should be rendered

Hi,

The IP 1.2.3.4 has just been banned by Fail2Ban after
0 attempts against my-custom-jail.


Here is more information about 1.2.3.4 :




Regards,

Fail2Ban

Alternatively would not this help?

host <ip> 2>/dev/null

i'm not clear on your suggestion. the error is triggered because STDIN has been closed for the sub-process, so when libuv goes to open the first available file descriptor, it gets FD#0, and thinks something must be wrong, since the first available should be FD#3 or higher.

so redirecting STDERR would mask the error, but not improve the situation since the command dies without generating any output.

2024-04-12 20:54:08,206 fail2ban.utils          [568192]: #09-Lev. 7fa64416bbb0 -- exec: printf %b "Hi,\n
The IP 1.2.3.4 has just been banned by Fail2Ban after
0 attempts against my-custom-jail.\n\n
Here is more information about 1.2.3.4 :\n
`host 1.2.3.4`\n\n
Matches:\n
\n\n
Regards,\n
Fail2Ban" | mail -s "[Fail2Ban] my-custom-jail: banned 1.2.3.4 from proxy01" [email protected]
2024-04-12 20:54:08,206 fail2ban.utils          [568192]: DEBUG   7fa64416bbb0 -- stderr: "host: ./src/unix/core.c:570: uv__close: Assertion `fd > STDERR_FILENO' failed."

FYI, instead of host command, you can simply use the tag `, it'd resolve the hostname of `` directly in fail2ban without to invoke external command. Here is the whole list of dynamic and ticket-related tags for 0.11.2 or last master

thank you for pointing me to this. i will give it a try.

but it still seems that i will run into the underlying problem if, for example i need to call out to dig/host/nslookup in order to get different output than is currently contained in <ip-host> or if i need to manipulate the output before injecting it by piping it through other command, similar to the charset-correcting idioms currently used in the _whois_convert_charset in action.d/mail-whois-common.conf.

By the way, mailing actions, not to mention such with a whois or host-resolve, are not recommended - they may generate large delays (up to timeout) and so unexpectedly retard the further bans (for other ips).

thank you for pointing this out, as i had not thought about this particular complication. i was mostly using the existing whois actions as a template without thinking about the broader impact of these actions.

do you have any suggestions for applying actions that are ancillary to the actual banning, but that still provide some utility? for example is there an equivalent to "backgrounding" an action command that would essentially make it fire-and-forget, not waiting for the exit status?

from fail2ban.

the command dies without generating any output.

Well I can do nothing here, I guess either it is an issue of host program... or of your platform, or some settings (systemd unit? whatever)...
To exclude settings issue (in systemd or pty or whatever), you can start fail2ban-server from console and check whether you'd see the same behavior.
Anyway, I never saw something like that in fail2ban (or else where), neither with host (it was used previously before <ip-host> was implemented), nor with other commands.

is there an equivalent to "backgrounding" an action command that would essentially make it fire-and-forget, not waiting for the exit status?

Yes (simply add & at end of command):

some-command arg1 ... argN 2>&1 &

However if you have a lot of bans and therefore many of such invocations, you could flood your system with many background processes. So be careful with that.
An alternative is some action cumulating the data and doing the job asynchronously (e. g. send one mail per 100 IPs or after some latency).

from fail2ban.

the command dies without generating any output.

Well I can do nothing here, I guess either it is an issue of host program... or of your platform, or some settings (systemd unit? whatever)... To exclude settings issue (in systemd or pty or whatever), you can start fail2ban-server from console and check whether you'd see the same behavior. Anyway, I never saw something like that in fail2ban (or else where), neither with host (it was used previously before <ip-host> was implemented), nor with other commands.

yes, i have an older system where the host idiom still works. the version of the bind9 libs on that system does not depend on libuv, hence the lack of error. but from my strace, i have already confirmed that the complaint from host/libuv is legitimate. ie, there is no STDIN/FD#0 for the spawned process.

my only question was whether the file descriptor was being closed in the fail2ban code or in some included python library, since the parent fail2ban-server process clearly has a valid STDIN, even it is attached to /dev/null. if the sub-process inherited that file descriptor, there would be no problem. it is the active closing of STDIN that triggers the error. ie, it's the difference between

~$  host 1.2.3.4 0</dev/null
Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)

and

~$  host 1.2.3.4 0<&-
Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
host: ./src/unix/core.c:570: uv__close: Assertion `fd > STDERR_FILENO' failed.
Aborted

but if you have not experienced or cannot reproduce, that is fine. the report is here for others to find if they experience similar or if you come across a related issue down the road.

is there an equivalent to "backgrounding" an action command that would essentially make it fire-and-forget, not waiting for the exit status?

Yes (simply add & at end of command):

some-command arg1 ... argN 2>&1 &

wow. given that this syntax is in the config files, i would not have expected that to work. thanks for clarifying.

However if you have a lot of bans and therefore many of such invocations, you could flood your system with many background processes. So be careful with that. An alternative is some action cumulating the data and doing the job asynchronously (e. g. send one mail per 100 IPs or after some latency).

exactly what i am beginning work on right now. i already have a cronjob that emails a ban summary at the end of the day. i am simply adapting this to include the reverse DNS lookup and log lines.

thanks for the pointer, for all of your help and for the wonderful tool.

from fail2ban.

if the sub-process inherited that file descriptor, there would be no problem. it is the active closing of STDIN that triggers the error.

It is not made intentionally, but may be the aftereffect of forking (depending on the kind of start of the server) or something inside the unit or init.d-script or whatever you use to start fail2ban...

For the first one can try to rewrite start command for the server:
See for instance this commit: 528a7a5
Important is:

- Type=forking
+ Type=simple
- ExecStart=/usr/bin/fail2ban-client -x start
+ ExecStart=/usr/bin/fail2ban-server -xf start

This will start fail2ban as server without forking, directly in foreground.

For init.d scripts to daemonize non-forking process one have to use for start something like that:

- /usr/bin/fail2ban-client -x start
+ nohup /usr/bin/fail2ban-server -xf start 2>&1 &

No idea how it'd look with stdin in that cases - I never needed stdin in services/daemons, thus I'm stumped for an answer.
However IIRC, on a linux box nohup would redirect stdin from /dev/null.

from fail2ban.

if the sub-process inherited that file descriptor, there would be no problem. it is the active closing of STDIN that triggers the error.

It is not made intentionally, but may be the aftereffect of forking (depending on the kind of start of the server) or something inside the unit or init.d-script or whatever you use to start fail2ban...

For the first one can try to rewrite start command for the server: See for instance this commit: 528a7a5 Important is:

- Type=forking
+ Type=simple
- ExecStart=/usr/bin/fail2ban-client -x start
+ ExecStart=/usr/bin/fail2ban-server -xf start

This will start fail2ban as server without forking, directly in foreground.

No idea how it'd look with stdin in that cases - I never needed stdin in services/daemons, thus I'm stumped for an answer. However IIRC, on a linux box nohup would redirect stdin from /dev/null.

interesting. starting it in the foreground in a terminal did not show the problem. i will fiddle with the systemd unit file shortly and see if i can get it running there. the challenge is that i would like to be able to strace it from the start so that i can get an idea of when close(0) is being called, but i'm not sure if systemd will start it under strace.

from fail2ban.

the challenge is that i would like to be able to strace it from the start so that i can get an idea of when close(0) is being called

You don't need to search for this, as already said, it was probably the intent and purpose of demonization, so I guess forking do it intentionally for some important reason (no time to seek for the prehistory)...
And the piece is probably here:

Anyway I don't think we would change something here by forking or demonization process (since it could affect many systems and platforms), so if you really need stdin (why for Gods sake one may need it in service/daemon?), simply use non-forking variant of foreground start, as I described above.

from fail2ban.

strangely enough my systemd unit file was already as you described.

Type=simple
ExecStart=/usr/bin/fail2ban-server -xf start

so i don't think daemonization could have been the culprit.

even more strange, i cannot reproduce the behavior after having to fully stop at start the server while testing the unit file. in all of my other edits and testing, i was calling fail2ban-client reload to reread the configs, so the parent process was the same on that had been running since 8 Apr.

so even after reverting all of my configs to the versions prior to filing this BR, the behavior is no longer there. at this point i can only guess that there was some broken state with the long-running server process, or one or the threads.

but one thing that i know for sure: i am out of CPU cycles for the night. :-)

thank you for your help and your indulgence.

from fail2ban.