summaryrefslogtreecommitdiffstats
path: root/src/monitor/monitor_sbus.c
Commit message (Collapse)AuthorAgeFilesLines
* sbus: add new iface via sbus_conn_register_iface()Pavel Březina2015-01-231-7/+1
| | | | | | | | | | | | | | | | | | | Rename sbus_conn_add_interface() to sbus_conn_register_iface() and remove sbus_new_interface() calls since it is just one more unnecessary call outside the sbus code. The function sbus_new_interface() is made static and used directly in sbus_conn_register_iface(). The name was chosen to better describe what the function is doing. That it registers an interface on a given object path. The same interface can be used with different paths so it is not really about adding an interface. Preparation for: https://fedorahosted.org/sssd/ticket/2339 Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
* UTIL: Do not depend on monitor codeJakub Hrozek2014-10-091-34/+0
| | | | | | | Just moves code around. There should be a way to use the server.c module without linking the monitor code. Reviewed-by: Pavel Reichl <preichl@redhat.com>
* sbus: Refactor how we export DBus interfacesStef Walter2014-03-141-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most importantly, stop using per connection private data. This doesn't scale when you have more than one thing exporting or exported on a connection. Remove struct sbus_interface and expand sbus_conn_add_interface() function. Remove various struct sbus_interface args to connection initialization functions and make callers use sbus_conn_add_interface() directly. The old method was optimized for exporting one interface on a connection. We'll have connections that export zero, one or more interfaces. To export an interface on a DBus server, call sbus_conn_add_interface() from within the sbus_server_conn_init_fn. To export an interface on a DBus client, call sbus_conn_add_interface() after sbus_new_connection() returns. As before struct sbus_interface represents an object exported via DBus. However it is now talloc allocated. One can set instance data on the struct sbus_interface. This instance data is passed to the various handlers and used in their implementation. However, we now have type safe interface exporting in the various high level sss_process_init() sss_monitor_init() and so on. Introspection support was not in use, and is now gone until we implement it using the metadata (future patch). Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
* sbus: Add struct sbus_request to represent a DBus invocationStef Walter2014-03-141-22/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct sbus_request represents a request from a dbus client being handled by a dbus server implementation. The struct contains the message, connection and method (and in the future teh property) which is being requested. In the future it will contain caller information as well. sbus_request is a talloc memory context, and is a good place to attach any allocations and memory specific to the request. Each handler accepts an sbus_request. If a handler returns EOK, it is assumed that the handler will finish the request. Any of the sbus_request_*finish() methods can be used to complete the request and send back a reply. sbus_request_return_and_finish() uses the same argument varargs syntax as dbus_message_append_args(), which isn't a great syntax. Document it a bit, but don't try to redesign: The marshalling work (will follow this patch set) will remove the need to use varargs for most DBus implementation code. This patch migrates the monitor and data provider dbus code to use sbus_request, but does not try to rework the talloc context's to use it. Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
* sbus: Use constants to make dbus callsStef Walter2014-02-241-2/+2
| | | | | | | | | | | This allows us to remove duplicated information, and have the compiler check that when an method name is changed or removed the callers are updated. Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Sumit Bose <sbose@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com>
* Update DEBUG* invocations to use new levelsNikolai Kondrashov2014-02-121-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a script to update DEBUG* macro invocations, which use literal numbers for levels, to use bitmask macros instead: grep -rl --include '*.[hc]' DEBUG . | while read f; do mv "$f"{,.orig} perl -e 'use strict; use File::Slurp; my @map=qw" SSSDBG_FATAL_FAILURE SSSDBG_CRIT_FAILURE SSSDBG_OP_FAILURE SSSDBG_MINOR_FAILURE SSSDBG_CONF_SETTINGS SSSDBG_FUNC_DATA SSSDBG_TRACE_FUNC SSSDBG_TRACE_LIBS SSSDBG_TRACE_INTERNAL SSSDBG_TRACE_ALL "; my $text=read_file(\*STDIN); my $repl; $text=~s/ ^ ( .* \b (DEBUG|DEBUG_PAM_DATA|DEBUG_GR_MEM) \s* \(\s* )( [0-9] )( \s*, ) ( \s* ) ( .* ) $ / $repl = $1.$map[$3].$4.$5.$6, length($repl) <= 80 ? $repl : $1.$map[$3].$4."\n".(" " x length($1)).$6 /xmge; print $text; ' < "$f.orig" > "$f" rm "$f.orig" done Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Stephen Gallagher <sgallagh@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com>
* Make DEBUG macro invocations variadicNikolai Kondrashov2014-02-121-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | Use a script to update DEBUG macro invocations to use it as a variadic macro, supplying format string and its arguments directly, instead of wrapping them in parens. This script was used to update the code: grep -rwl --include '*.[hc]' DEBUG . | while read f; do mv "$f"{,.orig} perl -e \ 'use strict; use File::Slurp; my $text=read_file(\*STDIN); $text=~s#(\bDEBUG\s*\([^(]+)\((.*?)\)\s*\)\s*;#$1$2);#gs; print $text;' < "$f.orig" > "$f" rm "$f.orig" done Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Stephen Gallagher <sgallagh@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com>
* Don't give memory context in confdb where not neededJan Zeleny2012-02-211-1/+1
|
* New DEBUG facility - conversionPavel Březina2011-08-251-1/+2
| | | | | | | | | | https://fedorahosted.org/sssd/ticket/925 Conversion of the old debug_level format to the new one. (only where it was necessary) Removed: SSS_DEFAULT_DEBUG_LEVEL (completely replaced with SSSDBG_DEFAULT)
* Allow changing the log level without restartStephen Gallagher2011-05-061-4/+21
| | | | | | We will now re-read the confdb debug_level value when processing the monitor_common_logrotate() function, which occurs when the monitor receives a SIGHUP.
* Create common sss_monitor_init()Stephen Gallagher2011-05-061-0/+42
| | | | | | | | This was implemented almost identically for both the responders and the providers. It is easier to maintain as a single routine. This patch also adds the ability to provide a private context to attach to the sbus_connection for later use.
* Handle errors during log reopening betterStephen Gallagher2010-11-051-1/+2
|
* Write log opening failures to the syslogStephen Gallagher2010-10-191-1/+1
| | | | | If there is a problem with reopening the logs, it can be an audit trail issue.
* Fix a series of memory leaks in the SBUSStephen Gallagher2010-03-171-3/+6
|
* Properly handle dbus send attempts on a closed connectionStephen Gallagher2010-03-151-22/+3
| | | | | | | | dbus_connection_send_with_reply() will report success and return a NULL pending_reply when the connection is not open for communication. This patch creates a new wrapper around dbus_connection_send_with_reply() to properly detect this condition and report it as an error.
* Reopen logs when SIGHUP is caughtJakub Hrozek2010-03-081-0/+13
| | | | | | | | Upon receiving SIGHUP, the monitor signals all services to reopen their debug logs. It is also possible to signal individual services to reopen their particular files. Fixes: #332
* Rename server/ directory to src/Stephen Gallagher2010-02-181-0/+195
Also update BUILD.txt