 | syslog-ng | 182 Members |
| 3 Servers |
| syslog-ng | 182 Members |
| 3 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2023 | ||
 vostrelt | Yes, I do. | 12:16:58 |
 bazsi77 | so when the destination becomes available, you just add a new log path that takes the named pipe as a log source and sends it on to the real destination, right? | 12:17:44 |
| vostrelt | Right. Otherwise I would have to change the syslog configuration once more after the named pipe is emptied. | 12:19:32 |
| bazsi77 | this works, although you pay the additional overhead of doing everything over the pipe. | 12:20:26 |
| bazsi77 | what I had in mind originally was somewhat different: 1) early boot: system() -> /var/log/bootup.log 2) when the destination becomes availabe: - remove the old log path that takes system() to bootup.log - add a log path that takes system() to the new destination - also add a log path that takes /var/log/bootup.log and sends it to the same destination 3) in early boot, remove the bootup.log | 12:22:14 |
| bazsi77 | with that the bootup.log remains available until the host is up | 12:22:46 |
| vostrelt | In 2) would the order of messages be preserved? If messages start coming from system is it ensured (timestamps?) that they will be sent after those from file? | 12:36:50 |
| vostrelt | In 3) how do I know it is safe to remove the file (all messages sent)? | 12:37:46 |
| bazsi77 | I would remove it at the next boot, e.g. it only records the current boot | 12:38:31 |
| bazsi77 | message ordering is a good point | 12:38:52 |
| vostrelt | message ordering is a good point | 12:42:53 |
| vostrelt | So the answer is no, the order would not be ensured? | 12:43:21 |
| bazsi77 | yeah, that's the case. since these would be two separate sources, they'd be processed in parallel. | 12:43:43 |
| bazsi77 | if however you are doing everything through the pipe, that should serialize everything. | 12:44:16 |
| bazsi77 | if your message rate is not extreme, it should not matter much. extreme here meaning at least 10s of thousands per sec. | 12:45:10 |
| vostrelt | That should be OK. Only small part of logged messages is processed this way (around 10 messages after the boot and then typically 1 message per minute). | 12:56:02 |
| vostrelt | Thanks for consulting and be well. | 12:56:20 |
| 18 Jul 2023 | ||
 hofione | hi, in cfg.h i see the following
#define __cfg_is_feature_enabled(cfg, min_version) \
({ \
/* the flip-over for min_version reached, set min_version to 0 */ G_STATIC_ASSERT(min_version == 0 || VERSION_VALUE_CURRENT < ((min_version) - 1)); \
version_convert_from_user(cfg->user_version) >= (min_version) - 1; \
})
could someone plz explain why (min_version) - 1 is used in the comparisions and not min_version simply? | 07:57:03 |
| hofione | * hi, in cfg.h i see the following
#define __cfg_is_feature_enabled(cfg, min_version) \
({ \
/* the flip-over for min_version reached, set min_version to 0 */ G_STATIC_ASSERT(min_version == 0 || VERSION_VALUE_CURRENT < ((min_version) - 1)); \
version_convert_from_user(cfg->user_version) >= (min_version) - 1; \
})
could someone plz explain why (min_version) - 1 is used in the comparisions and not (min_version) simply? | 08:09:38 |
 eumel8 changed their display name from eumel8 to eumel8#0. | 13:55:23 | |
| eumel8 changed their display name from eumel8#0 to eumel8. | 13:55:24 | |
 mranno | the reason for this hides behind the fact that __cfg_is_feature_enabled() is not really what its name says. it's not about enabling a feature, but to enable warnings for an upcoming preview feature.it's really confusing, I have to re-read the code every time I saw this. take a look at lib/filter/filter-expr-grammar.ym:87, I think that explains how it works.see also: https://github.com/syslog-ng/syslog-ng/blob/17c697d21e84e1f6a863456deeca80748ff37bdd/lib/cfg.h#L214-L218 | 16:03:19 |
| mranno | * the reason for this hides behind the fact that __cfg_is_feature_enabled() is not really what its name says. it's not about enabling a feature, but to enable warnings for an upcoming preview feature.it's really confusing, I have to re-read the code every time I see this. take a look at lib/filter/filter-expr-grammar.ym:87, I think that explains how it works.see also: https://github.com/syslog-ng/syslog-ng/blob/17c697d21e84e1f6a863456deeca80748ff37bdd/lib/cfg.h#L214-L218 | 16:04:54 |
| mranno | syslog-ng PE also complicated the implementation of this switch, as we had to do it in a way that allows PE to remain in compatibility mode without warnings, even after 4.0 was released | 16:09:37 |
| hofione | "enable warnings for an upcoming preview feature." explains it, thank you! | 16:24:16 |
| 20 Jul 2023 | ||
| mranno | grg_2145 Could you please share the testdb branch for this PR? https://github.com/syslog-ng/syslog-ng/pull/4551 | 08:38:30 |
 grg_2145 | I merged it this morning, can you retrigger it, or is it already ran like less than 2 hours ago? | 09:02:22 |
| mranno | grg_2145 https://ci.syslog-ng.com/job/kira-test-compile-cmake-run-testdb/11976/testReport/junit/syslog-ng-pe-testdb_functions_source-drivers_python-source-driver_010-python-source-test-generate-persist-name/zts__python_source_generate_persist_name/platform_ubuntu_xenial_amd64product_oseversion_4_2syslogger_syslogd/ I don't see any difference in the new run, it looks like the pattern is still "python,mypythonsource".you can test the changes before merging: https://github.com/syslog-ng/syslog-ng/wiki/Kira---syslog-ng-automate-test-system | 09:28:54 |
| mranno | * grg_2145 https://ci.syslog-ng.com/job/kira-test-compile-cmake-run-testdb/11976/testReport/junit/syslog-ng-pe-testdb_functions_source-drivers_python-source-driver_010-python-source-test-generate-persist-name/zts__python_source_generate_persist_name/platform_ubuntu_xenial_amd64product_oseversion_4_2syslogger_syslogd/ I don't see any difference in the new run, it looks like the pattern is still "python,mypythonsource".you can test the changes before merging: https://github.com/syslog-ng/syslog-ng/wiki/Kira---syslog-ng-automate-test-system#examples | 09:31:47 |
| grg_2145 | hmm i think testdb was not yet synced out, let me ask arountthis, we merged the following changes this morning this seems like it is out of sync: | 09:33:25 |