Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README.md: Various improvements #4

Closed
wants to merge 1 commit into from
Closed

Conversation

algernon
Copy link
Contributor

Rearrange the README a little bit, putting the source installation docs
at the top, adding more links, and rewording a few things here and
there.

Signed-off-by: Gergely Nagy algernon@balabit.hu

Rearrange the README a little bit, putting the source installation docs
at the top, adding more links, and rewording a few things here and
there.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
@bazsi
Copy link
Collaborator

bazsi commented Nov 12, 2013

merged, thanks.

@bazsi bazsi closed this Nov 12, 2013
@bazsi bazsi deleted the merge/h/README-update branch November 14, 2013 11:19
talien pushed a commit to talien/syslog-ng that referenced this pull request Jan 10, 2014
This implements very basic support for type hinting template strings,
where those hints will be available to value-pairs too, allowing any
user of either LogTemplate or value-pairs to handle different types of
values than plain strings. How they handle it, is up to the callers,
this patch just lays the groundwork that makes it possible to pass
these hints around.

Furthermore, this includes support for the on-error() statement, which
tells drivers how type-casting failures shall be handled: they can
either drop the message, drop the property, or fall back to string;
and can do either of these either verbosely, logging the fact, or
silently.

This fixes syslog-ng#4 and syslog-ng#5.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
justcallmegreg pushed a commit that referenced this pull request Feb 23, 2015
RabbitMQ module changed to the upstream. Relevant modifications to the code according to the API added.
Signed-off-by: Gergő Nagy gergo.nagy@balabit.com
bazsi added a commit that referenced this pull request Feb 21, 2016
syslog-ng was crashing in my development environment at startup
if the systemd-journal() driver was used, in a backtrace like this:

Program received signal SIGSEGV, Segmentation fault.
g_module_symbol (module=0x6771b0, symbol_name=0x7ffff4942a65 "sd_journal_open", symbol=0x7ffff7f838f0 <sd_journal_open>) at /build/glib2.0-ajuDY6/glib2.0-2.46.1/./gmodule/gmodule.c:818
818	/build/glib2.0-ajuDY6/glib2.0-2.46.1/./gmodule/gmodule.c: No such file or directory.
(gdb) bt
#0  g_module_symbol (module=0x6771b0, symbol_name=0x7ffff4942a65 "sd_journal_open", symbol=0x7ffff7f838f0 <sd_journal_open>) at /build/glib2.0-ajuDY6/glib2.0-2.46.1/./gmodule/gmodule.c:818
#1  0x00007ffff493e6cd in load_journald_subsystem () at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/modules/systemd-journal/journald-subsystem.c:105
#2  0x00007ffff493cd0c in systemd_journal_module_init (cfg=0x63a2a0, args=0x0) at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/modules/systemd-journal/systemd-journal-plugin.c:44
#3  0x00007ffff7b4a9d3 in plugin_load_module (module_name=0x6572a0 "sdjournal", cfg=0x63a2a0, args=0x0) at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/plugin.c:385
#4  0x00007ffff7b4a18c in plugin_find (cfg=0x63a2a0, plugin_type=3, plugin_name=0x675c80 "systemd-journal") at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/plugin.c:155
#5  0x00007ffff7b5ee8e in main_parse (lexer=0x63f010, dummy=0x7fffffffd0c8, arg=0x0) at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/cfg-grammar.y:580
#6  0x00007ffff7b2a7a5 in cfg_parser_parse (self=0x7ffff7dd4ee0 <main_parser>, lexer=0x63f010, instance=0x7fffffffd0c8, arg=0x0)
    at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/cfg-parser.h:83
#7  0x00007ffff7b2b7f7 in cfg_run_parser (self=0x63a2a0, lexer=0x63f010, parser=0x7ffff7dd4ee0 <main_parser>, result=0x7fffffffd0c8, arg=0x0)
    at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/cfg.c:430
#8  0x00007ffff7b2ba3a in cfg_read_config (self=0x63a2a0, fname=0x60e940 "etc/syslog-ng.conf", syntax_only=0, preprocess_into=0x0)
    at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/cfg.c:502
#9  0x00007ffff7b45368 in main_loop_read_and_init_config () at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/lib/mainloop.c:447
#10 0x0000000000401b31 in main (argc=1, argv=0x7fffffffd238) at /home/bazsi/zwa/projects/syslog-ng-ose-3.6/source/syslog-ng/syslog-ng/main.c:261

My belief is that the root cause was that the global variables in
journald-subsystem.c are named the same as the symbols in libsystemd.so,
and both are symbols with global visibility. My theory was that due to the name
clash, the actual pointer passed to g_module_symbol() was pointing
to the actual code of the functions, instead of the pointer we wanted
to store the values. I didn't completely confirm this theory, but
adding "static" qualifiers to the variables resolved the issue for me.

Honestly, I don't really like how journal-systemd.c is organized, but this
was only a distraction for me and I was satisfied with resolving the problem
for now.

Signed-off-by: Balazs Scheidler <balazs.scheidler@balabit.com>
Kokan added a commit to Kokan/syslog-ng that referenced this pull request Aug 29, 2020
Parameterized tests are the worst in Criterion. Specially with pointers and ASLR.

Causes test to fail when executed with ASAN:
```
==3181004==ERROR: AddressSanitizer: SEGV on unknown address 0x7faeee7938a8 (pc 0x7f0f053880e7 bp 0x7faeee7938a0 sp 0x7ffe7fe59510 T0)
==3181004==The signal is caused by a READ memory access.
    #0 0x7f0f053880e7 in PyObject_Call (/usr/lib/libpython3.8.so.1.0+0x1420e7)
    #1 0x4f7f7c in python_ack_tracker_test_ack_tracker_factory_impl /home/kokan/src/syslog-ng/build/../modules/python/tests/test_python_ack_tracker.c:124:42
    syslog-ng#2 0x7f0f05225e3e in criterion_internal_test_main (/usr/lib/libcriterion.so.3+0x8e3e)
    syslog-ng#3 0x4f7e34 in python_ack_tracker_test_ack_tracker_factory_jmp /home/kokan/src/syslog-ng/build/../modules/python/tests/test_python_ack_tracker.c:119:1
    syslog-ng#4 0x7f0f05225308  (/usr/lib/libcriterion.so.3+0x8308)
    syslog-ng#5 0x7f0f05236b4c  (/usr/lib/libcriterion.so.3+0x19b4c)
    syslog-ng#6 0x7f0f04626151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
    syslog-ng#7 0x41f43d in _start (/home/kokan/src/syslog-ng/build/modules/python/tests/Debug/test_python_ack_tracker+0x41f43d)
```

Signed-off-by: Kokan <kokaipeter@gmail.com>
Kokan added a commit to Kokan/syslog-ng that referenced this pull request Oct 2, 2020
Every time a key created a counter names is allocated. But it is not
freed. The only time it is freed when a new stats-cluster is created
from it (first time looked up) and the counter_names owenership
transfared to the stats-cluster.

With this patch the allocation is delayed to the ownership change, thus
only allocated if there is still a pointer to the memory.

Reproduction:
1. syslog-ng configuration with at least one network source
2. start syslog-ng with a leak detector
(2.1 optional do restart (in order to have the exact leak as above))
3. stop syslog-ng

=================================================================
==2095056==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x55a4f86db781 in calloc (/tmp/install/sbin/syslog-ng+0xc5781)
    #1 0x7f343f03a941 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x50941)
    syslog-ng#2 0x7f343acb37c7 in _make_connection_conter_stats_queryable /home/user/src/syslog-ng/build/../modules/afsocket/afsocket-source.c:1007:9
    syslog-ng#3 0x7f343acb30f3 in afsocket_sd_init_method /home/user/src/syslog-ng/build/../modules/afsocket/afsocket-source.c:1060:5
    syslog-ng#4 0x7f343acbc358 in afinet_sd_init /home/user/src/syslog-ng/build/../modules/afsocket/afinet-source.c:103:8
    syslog-ng#5 0x7f343f248e1a in log_pipe_init /home/user/src/syslog-ng/build/../lib/logpipe.h:301:23
    syslog-ng#6 0x7f343f248c88 in cfg_tree_start /home/user/src/syslog-ng/build/../lib/cfg-tree.c:1419:12
    syslog-ng#7 0x7f343f23af71 in cfg_init /home/user/src/syslog-ng/build/../lib/cfg.c:368:8
    syslog-ng#8 0x7f343f270b3c in main_loop_reload_config_apply /home/user/src/syslog-ng/build/../lib/mainloop.c:276:41
    syslog-ng#9 0x7f343f273162 in _consume_action /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:240:3
    syslog-ng#10 0x7f343f27321f in _invoke_sync_call_actions /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:250:7
    syslog-ng#11 0x7f343f2736ba in main_loop_worker_sync_call /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:396:7
    syslog-ng#12 0x7f343f2709d1 in main_loop_reload_config_commence /home/user/src/syslog-ng/build/../lib/mainloop.c:340:3
    syslog-ng#13 0x7f343f275852 in control_connection_reload /home/user/src/syslog-ng/build/../lib/mainloop-control.c:167:3
    syslog-ng#14 0x7f343f290c80 in control_connection_io_input /home/user/src/syslog-ng/build/../lib/control/control-server.c:378:3
    syslog-ng#15 0x7f343efd4b2c  (/usr/lib/libivykis.so.0+0x6b2c)
    syslog-ng#16 0x7f343f239c50 in run_application_hook /home/user/src/syslog-ng/build/../lib/apphook.c:125:11

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x55a4f86db781 in calloc (/tmp/install/sbin/syslog-ng+0xc5781)
    #1 0x7f343f03a941 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x50941)
    syslog-ng#2 0x7f343acb3e27 in _stop_connection_counter_stats_queryable /home/user/src/syslog-ng/build/../modules/afsocket/afsocket-source.c:1027:9
    syslog-ng#3 0x7f343acb38bd in afsocket_sd_deinit_method /home/user/src/syslog-ng/build/../modules/afsocket/afsocket-source.c:1073:3
    syslog-ng#4 0x7f343f2491d4 in log_pipe_deinit /home/user/src/syslog-ng/build/../lib/logpipe.h:316:25
    syslog-ng#5 0x7f343f2490e5 in cfg_tree_stop /home/user/src/syslog-ng/build/../lib/cfg-tree.c:1439:12
    syslog-ng#6 0x7f343f23b2d1 in cfg_deinit /home/user/src/syslog-ng/build/../lib/cfg.c:387:10
    syslog-ng#7 0x7f343f271ec2 in main_loop_exit_finish /home/user/src/syslog-ng/build/../lib/mainloop.c:427:3
    syslog-ng#8 0x7f343f273162 in _consume_action /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:240:3
    syslog-ng#9 0x7f343f27321f in _invoke_sync_call_actions /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:250:7
    syslog-ng#9 0x7f343f27321f in _invoke_sync_call_actions /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:250:7
    syslog-ng#10 0x7f343f2736ba in main_loop_worker_sync_call /home/user/src/syslog-ng/build/../lib/mainloop-worker.c:396:7
    syslog-ng#11 0x7f343f2709d1 in main_loop_reload_config_commence /home/user/src/syslog-ng/build/../lib/mainloop.c:340:3
    syslog-ng#12 0x7f343f275852 in control_connection_reload /home/user/src/syslog-ng/build/../lib/mainloop-control.c:167:3
    syslog-ng#13 0x7f343f290c80 in control_connection_io_input /home/user/src/syslog-ng/build/../lib/control/control-server.c:378:3
    syslog-ng#14 0x7f343efd4b2c  (/usr/lib/libivykis.so.0+0x6b2c)
    syslog-ng#15 0x7f343f239c50 in run_application_hook /home/user/src/syslog-ng/build/../lib/apphook.c:125:11

Signed-off-by: Kokan <kokaipeter@gmail.com>
szemere pushed a commit that referenced this pull request Dec 15, 2020
This commit accumulates synthetic messages in an array, and forwards them
after releasing the GroupingBy parser's lock.

It is NOT allowed to call log_pipe_forward_msg() when locks are held,
because it would slow down the entire pipeline, and it could also result
in deadlock, for example:

1. A new message is produced in syslog-ng's worker pool, which goes
   through the parser, so it acquires GroupingBy::lock, and starts
   processing the message (continues in step 3).

2. The main thread schedules grouping_by_timer_tick(), which needs to
   hold GroupingBy::lock, so it blocks and waits for the other thread.

3. A new synthetic message is emitted in the worker thread (step 1).
   stateful_parser_emit_synthetic() is called in
   grouping_by_expire_entry(), which is protected by GroupingBy::lock,
   The message goes through the pipeline with this lock held, reaches a
   destination, where main_loop_call(wait=TRUE) is called.

Worker waits for the main loop call to be scheduled and finished,
main thread waits for GroupingBy::lock, which will never be released.

A deadlock situation requires at least 2 locks:
- one was GroupingBy::lock;
- the other was main_task_lock and its GCond in main_loop_call().

Main thread:
```
#0  syscall ()
#1  g_mutex_lock_slowpath ()
#2  _grouping_by_timer_tick ()
#3  grouping_by_timer_tick ()
#4  iv_run_timers ()
#5  iv_main ()
#6  main_loop_run ()
#7  main ()
```

Worker thread:
```
#0  syscall ()
#1  g_cond_wait ()
#2  main_loop_call ()
#3  ml_batched_timer_postpone ()
#4  log_writer_queue ()
#5  log_dest_driver_queue_method ()
#6  log_multiplexer_queue ()
#7  log_multiplexer_queue ()
#8  log_filter_pipe_queue ()
#9  stateful_parser_emit_synthetic ()
#10 grouping_by_expire_entry ()
#11 timer_wheel_set_time ()
#12 grouping_by_set_time ()
#13 grouping_by_process ()
...
```

Important note:
The unlock trick wouldn't have worked in the timer expire callback case,
as we would be iterating through a non-locked data structure (TimerWheel)
that could be modified by other threads.

This commit is based on a00164c, which is
a similar deadlock fix for PatternDB.

Signed-off-by: László Várady <laszlo.varady@protonmail.com>
@bazsi bazsi mentioned this pull request Mar 9, 2021
sparlane added a commit to sparlane/syslog-ng that referenced this pull request Apr 29, 2022
log_proto_server_reset_error blindly attempts to deref the pointer,
which results in a crash when it is NULL.
Since this is trying to reset errors, if the object is NULL it definitely
wont have an errors to clear.

Crash is seen as:
Thread 1 (Thread 0x77fa5020 (LWP 405)):
 #0  0x0ff59618 in log_proto_server_reset_error (s=0x0) at ./lib/logproto/logproto-server.h:164
 syslog-ng#1  log_reader_work_finished (s=0x10053800) at lib/logreader.c:426
 syslog-ng#2  0x0fc75b98 in iv_fd_poll_and_run (st=st@entry=0x100270a0, abs=<optimized out>) at iv_fd.c:219
 syslog-ng#3  0x0fc770b4 in iv_main () at iv_main_posix.c:112
 syslog-ng#4  0x0ff5e060 in main_loop_run (self=0xfff629c <main_loop>) at lib/mainloop.c:657
 syslog-ng#5  0x10001264 in main (argc=<optimized out>, argv=<optimized out>) at syslog-ng/main.c:316

Change-Id: I8d63a342e74527e6f056afc44a60de05803d1d6e
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Anthony Lineham <anthony.lineham@alliedtelesis.co.nz>
HofiOne pushed a commit to HofiOne/syslog-ng that referenced this pull request Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants