!SxCwoMDDLFxMJcVaKl:matrix.org

syslog-ng

182 Members
3 Servers

Load older messages


SenderMessageTime
11 Jul 2023
@_discord_347847304394571786:t2bot.iomranno Hi, the current implementation is permissive, I think this is the only "reason" 11:57:44
@_discord_347847304394571786:t2bot.iomranno I don't think any of those 2 test cases are real requirements. The last one might be interesting 11:59:52
@_discord_1125805993410953286:t2bot.ioalexb271 Thanks for the quick reply! So the ones ending in \n are not important, but then the ones ending with \r are important? Do I get that right? Or are the ones with the \r also not strictly necessary? 12:03:18
@_discord_347847304394571786:t2bot.iomranno I'm not aware of any software that implements the proxy protocol incorrectly.
I think as long as we conform this specification, we are good:
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
12:06:41
@_discord_347847304394571786:t2bot.iomranno (I think you can change the expected results of the tests under the "INVALID PROTO" section without breaking any real use-cases. ) 12:09:34
@_discord_1125805993410953286:t2bot.ioalexb271 Okay, thanks! 12:57:00
@_discord_1125805993410953286:t2bot.ioalexb271 I've been able to put together a pull request about proxy processing refactored into the logtransport layer (#4544). I've been able to adapt most of the relevant tests, but some functions, including the ones testing line endings, report errors while reading from the network and currently there aren't any mock infrastructure for logtransport input (while the logproto server could simply use mocked transports). 15:05:59
12 Jul 2023
@_discord_1128302060387971132:t2bot.iovostrelt joined the room.03:31:55
13 Jul 2023
@_discord_1128302060387971132:t2bot.iovostrelt Hello, could you please help me solving the following syslog-ng challenge? I have messages that are generated earlier than the client machine networking is set up. And I want them to be sent to a remote syslog server with a correct timestamp (when they were generated). So I think whether it can be done in following way.Start the syslog-ng with configuration that will force it to store the messages to a buffer (because networking is not set up yet, destination not ready). Update the syslog-ng configuration let it send bufferred messages (when networking is setup, destination ready). How can it be achieved? What about throttle(0) and disk-buffer? 12:08:46
@_discord_1128302060387971132:t2bot.iovostrelt * Hello, could you please help me solving the following syslog-ng challenge? I have messages that are generated earlier than the client machine networking is set up. And I want them to be sent to a remote syslog server with a correct timestamp (when they were generated). So I think whether it can be done in following way. 1. Start the syslog-ng with configuration that will force it to store the messages to a buffer (because networking is not set up yet, destination not ready). 2. Wait for the networking to be set up. 3. Update the syslog-ng configuration let it send bufferred messages (when networking is setup, destination ready). How can it be achieved? What about throttle(0) and disk-buffer? 12:09:18
@_discord_258949722205716480:t2bot.iogrg_2145 Hi
We noticed that during testing that the BatchedAckTracker's batched_ack_callback/ack_callback is never called. (possibly it is an issue for the others as well)
I did 2 test with the following commits, both of them are working:
https://github.com/syslog-ng/syslog-ng/commit/723d2aa8c4ea9bec770db0d362d17ca4b43b5cfb
https://github.com/syslog-ng/syslog-ng/commit/69c211e1c0460cb679466467dcf6b4b6e3d03f67
Based on mainly my second test the problem is that the fake classes are not calling the super class's init method, and it's causing the issue which is that, by skipping the super's constructor, python is never calling the C py_batched_ack_tracker_factory_init function.
NOTE: previously I thought that it is working but is missed the failing testcases which were testing these.

I am about create a pr: https://github.com/syslog-ng/syslog-ng/pull/4549
12:12:04
@_discord_258949722205716480:t2bot.iogrg_2145 * Hi
We noticed that during testing that the BatchedAckTracker's batched_ack_callback/ack_callback is never called. (it is an issue for the others as well)
I did 2 test with the following commits, both of them are working:
https://github.com/syslog-ng/syslog-ng/commit/723d2aa8c4ea9bec770db0d362d17ca4b43b5cfb
https://github.com/syslog-ng/syslog-ng/commit/69c211e1c0460cb679466467dcf6b4b6e3d03f67
Based on mainly my second test the problem is that the fake classes are not calling the super class's init method, and it's causing the issue which is that, by skipping the super's constructor, python is never calling the C py_batched_ack_tracker_factory_init function.
NOTE: previously I thought that it is working but is missed the failing testcases which were testing these.

I am about create a pr: https://github.com/syslog-ng/syslog-ng/pull/4549
12:12:29
@_discord_347847304394571786:t2bot.iomranno Thanks! Did this break the tests of the PubSub source as well? 12:15:53
@_discord_258949722205716480:t2bot.iogrg_2145 yes this was the issue 12:16:02
@_discord_258949722205716480:t2bot.iogrg_2145 Do you think that having the fake class missing for the LogSource causes any isse? (that one's super().init(...) call is also missing) 12:16:59
@_discord_258949722205716480:t2bot.iogrg_2145 * Do you think that having the fake class missing for the LogSource and the LogFetcher causes any isse? (that one's super().init(...) call is also missing) 12:18:07
@_discord_347847304394571786:t2bot.iomranno de init() method of the LogSource and LogFetcher classes are "pure virtual", they don't have to be called.
but all __init__() (constructor) should call its parent constructor for the sake of completeness in my opinion.
12:24:27
@_discord_258949722205716480:t2bot.iogrg_2145 sure i'll add the fake classes for those just in case 12:26:23
@_discord_258949722205716480:t2bot.iogrg_2145 it should be done hopefullt actions thinks this as well 🙂 12:39:00
@_discord_258949722205716480:t2bot.iogrg_2145 * it should be done hopefully actions thinks this as well 🙂 12:46:40
@_discord_1128302060387971132:t2bot.iovostrelt OK, I see throttle(0) would not work, as that means "unlimited". Can you think of different way to force the syslog to buffer the messages? 13:17:16
@_discord_347847304394571786:t2bot.iomranno When flags(flowc) 13:19:08
@_discord_347847304394571786:t2bot.iomranno * When flags(flow-control) is enabled on your log path and you configure disk-buffer() for your network destination, it will queue messages up until the destination becomes available. But I'm not 100% sure I understood the full context.

You can also configure the "reconnect" timer with the time-reopen() optoin.
13:20:55
@_discord_347847304394571786:t2bot.iomranno * When flags(flow-control) is enabled on your log path and you configure disk-buffer() for your network destination, it will queue messages up until the destination becomes available. But I'm not 100% sure I understood the full context.

You can also configure the "reconnect" timer with the time-reopen() option.
13:20:58
@_discord_347847304394571786:t2bot.iomranno * When flags(flow-control) is enabled on your log path and you configure disk-buffer() for your network destination, syslog-ng will queue messages up until the destination becomes available. (But I'm not 100% sure I understood the full context.)

A connection towards the destination will be tried every time-reopen() seconds.
13:22:19
14 Jul 2023
@_discord_1128302060387971132:t2bot.iovostrelt Thanks for reply. I'll try to be clearer. I'm looking for a way how to tell syslog to buffer messages with specific tag (during machine startup) to send them later when the destination is known and ready. Maybe it will work with initial configuration that will define destination that will be unreachable + configuration update when the destination becomes known and ready. 06:53:29
@_discord_914929598179975239:t2bot.iobazsi77 You could simply store this in a separate file destination and have that sent when the network based destination becomes available. At this point you'd use a file source. But that's just one idea. 06:55:37
@_discord_1128302060387971132:t2bot.iovostrelt I guess the time in syslog message would not be the time they were generated. It would be the time the network destination becomes ready. 07:12:12
@_discord_914929598179975239:t2bot.iobazsi77 Not necessarily. For syslog-ng the timestamp is the property of the message. 07:13:05
@_discord_914929598179975239:t2bot.iobazsi77 If you read a syslog-like file the timestamp would be parsed and when sent out being used as timestamp 07:13:34

Show newer messages


Back to Room ListRoom Version: 10