yes, as said reject_unknown_client_hostname is relatively strict, one
needs to set an exception now and then if the server is legit in the end...
but it's not legit requests more often...
https://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
On 21/09/2023 21:06, David
yes that was in the first message, I reimplemented everything, it is
working without any issues now. that was not the problem btw. that was
not even there at the time of the first message, this is actually the
reimplementatiom I did on the rsyslog side. as said, it works without
any issues
Subject: Re: [rsyslog] Repeated 111 to rsyslog UDS from nginx
I don't think we are talking same things anymore.
I told you several times journald is not involved in this. you cannot
find 1 line of these logs in journald, so I am not using journald as
queue, because I am not using journald
(Disclaimer: I have not read all this thread in depth.)
This flag "confirmMessages=on" sounds suspicious. With this flag, omprog
waits for the script to confirm each received log line (if I recall well),
but your script (looking at your first message) doesn't seem to do this (?)
(to be sure we
hmm,
dlang@dlang-mobile:~$ nslookup 66.167.227.145 8.8.8.8
145.227.167.66.in-addr.arpa name = mail.lang.hm.
Authoritative answers can be found from:
dlang@dlang-mobile:~$ nslookup mail.lang.hm 8.8.8.8
Server: 8.8.8.8
Address:8.8.8.8#53
Non-authoritative answer:
Name:
to rsyslog UDS from nginx
I don't think we are talking same things anymore.
I told you several times journald is not involved in this. you cannot find 1
line of these logs in journald, so I am not using journald as queue, because
I am not using journald at all for this process.
"you did not conf
I don't think we are talking same things anymore.
I told you several times journald is not involved in this. you cannot
find 1 line of these logs in journald, so I am not using journald as
queue, because I am not using journald at all for this process.
"you did not configure rsyslog to use a
this is a standard reject_unknown_client_hostname from postfix, this is
relatively strict, but ususally no problem on clean servers, I have only
a handful exceptions
this is not the IP you sent from...the mail came from 66.167.227.145
cannot find your hostname, [66.167.227.145]; from=
to=
___
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
On Thu, 21 Sep 2023, TG Servers wrote:
I did not get a single message from you David regarding that, that confused
me quite a bit as Rainer mentioned you already before, now I know why :
450 4.7.25 Client host rejected: cannot find your hostname, [66.167.xxx.xxx];
from= to= proto=ESMTP helo=
if you are sending logs to journald and having journald send logs to syslog, you
are using journald as a queue for the delivery
when you were delivering directly to rsyslog, what was probably happening (we
don't know because you never enabled impstats to see) is that the logs were
arriving,
I did not get a single message from you David regarding that, that
confused me quite a bit as Rainer mentioned you already before, now I
know why :
450 4.7.25 Client host rejected: cannot find your hostname,
[66.167.xxx.xxx]; from= to=
proto=ESMTP helo=
made an exception now
But to the
depends on the journald config. It can be configured to queue to disk, with
limits on disk size.
David Lang
On Thu, 21 Sep 2023, Rainer Gerhards wrote:
I guess it works because journal always throws messages away if it cannot
deliver them quickly. Luke a very short timeout+drop queue config
I guess it works because journal always throws messages away if it cannot
deliver them quickly. Luke a very short timeout+drop queue config in
rsyslog.
Rainer
Sent from phone, thus brief.
David Lang schrieb am Do., 21. Sept. 2023, 08:23:
> now you have journald acting as a queue, so all
now you have journald acting as a queue, so all messages from journald will end
up delayed when your script cannot keep up. You haven't solved the problem of
the slow script, you've just added another layer of buffer to fill up before you
notice.
with rsyslog you can set the queue size to
the only way I was able to fix this was to use a dedicated socket
created via systemd and passed via systemd to rsyslog
since then it is working without any issues.
although I implemented a queue, too, this did not fix the problem as
long as the socket was handled by rsyslog itself
so this is
when rsyslog starts up, it generates various log messages, are they being sent
to the script?
it would really help to see the queue data from impstats
David Lang
On Mon, 18 Sep 2023, TG Servers via rsyslog wrote:
I don't know what this is... I implemented a complete queue solution and
it
I don't know what this is... I implemented a complete queue solution and
it occasionally happens when there is no request but one in sight, and
this one gets a 111 then, nothing in nginx debug log, no error to be
seen in rsyslog log
but one thing I realized, after a restart the first log
rsyslog does not just pipe the socket to the script. It reads a message from the
socket, adds it to a queue (by default the main queue), then a separate thread
reads from the queue and sends the line to the script.
If the script takes too long to process the line, then a backlog of messages
I just wanted to add that in a further message as it came to my mind.
you were faster...
the script is definitely "slow", this is what I know for sure as it does
quite a lot of processing/analytics in the background, so even if you
trigger it from command line it can take half a sec or so I
> so far not a single 111 today, I let this run the until late evening,
> and if there is stil no 111 I will put back the python script in order
> because right now there are 2 possibilities, I moved the socket as said,
> and I skipped the script and just appended the message to a file
> if either
so far not a single 111 today, I let this run the until late evening,
and if there is stil no 111 I will put back the python script in order
because right now there are 2 possibilities, I moved the socket as said,
and I skipped the script and just appended the message to a file
if either of the
: Re: [rsyslog] Repeated 111 to rsyslog UDS from nginx
- PHISHING ALERT -
This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click
on a link
Cc: David Lang
Subject: Re: [rsyslog] Repeated 111 to rsyslog UDS from nginx
- PHISHING ALERT -
This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you
what I did today in the morning was to put the socket in /run
input(type="imuxsock" socket="/run/logmat")
until now no errors so far but that does not mean a lot as there is not
much traffic right now.
you mean remove the python script or the whole script call? what I could
do is to echo the
my thought is that if rsyslog is getting blocked (queues full) then it will stop
accepting new logs via unix sockets.
can you enable impstats and see if you have any reports of the main queue being
full during the times that this happens?
full configs for rsyslog could identify if there is
Maybe a debug logs helps, but if rsyslog does not emit an error
message, it does not sound like it has some issue. I also don't see a
relation to the script. But to be sure, would it be possible to
temporarily remove it and see if that changes anything?
Rainer
El lun, 18 sept 2023 a las 9:09, TG
Hi Rainer,
this is from nginx error log, yes.
No I cannot find any other errors, thats my problem
But it happens every single day, regularly...
as just written in another message re the question if it occurs with
rsyslog restart or logrotate :
no absolutely not, I cannot see any relation to
___
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
Hi Yury,
no absolutely not, I cannot see any relation to things like that, that
is what leaves me a bit baffled here.
You can see this is all from one day, and if there is a 111 on 2:52:19
on 2:52:22 there is everything ok (just as an example)
Rsyslog restarts run between 0:10 and 0:15,
Is this from a nginx text log? Any errors infos from rsyslog itself?
Rainer
PS: I do not see how this can be related to rsyslog, but you never
know. I do not yet understand the fault scenario TBH.
El dom, 17 sept 2023 a las 18:39, TG Servers via rsyslog
() escribió:
>
> Hi,
>
> ever since I
Hello!
Does the timing match with rsyslog restarts (manual or logrotate-initiated)?
On Mon, 18 Sept 2023 at 00:39, TG Servers via rsyslog <
rsyslog@lists.adiscon.com> wrote:
> Hi,
>
> ever since I started logging to a UDS from my nginx I get the occasional
> 111 in my nginx error logs.
> As I
Hi,
ever since I started logging to a UDS from my nginx I get the occasional
111 in my nginx error logs.
As I literally don't have any other information or log entries I
honestly do not know how to debug this.
The thing is requests one second, or a few seconds later are processed
totally
33 matches
Mail list logo
