resolv.conf can be missing during boot. This is not fatal and we will check for its existence later. Reviewed-by: Pavel Reichl <preichl@redhat.com>
If resolv.conf is not available when SSSD is starting, check for its existence later. Ticket: https://fedorahosted.org/sssd/ticket/2590 Reviewed-by: Pavel Reichl <preichl@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Properties are single value of a small number of predefined D-Bus types. There is no need to generate them with codegen. Actually, the source generator for property getters is already quite mess with branching for array, strings and object paths. Adding any more complex type in the future (such as dictionary) would require even more branching or creating a separate path for it. Hard coding the getters will simplify creating new ones for more complex types. This patch also reduces lots of code duplication and creates a simple function for GetAll. Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
If kill timer was successfully executed then it will be released by libtevent.
So we should not released it in mt_svc_exit_handler for the second time.
[sssd] [mt_svc_exit_handler] (0x0040): Child [ifp] terminated with signal [9]
[sssd] [talloc_log_fn] (0x0010): talloc: access after free error - first free
may be at ../tevent_timed.c:351
[sssd] [talloc_log_fn] (0x0010): Bad talloc magic value - access after free
==19129== Invalid read of size 4
==19129== at 0x50470CD: talloc_chunk_from_ptr (talloc.c:372)
==19129== by 0x50470CD: _talloc_free (talloc.c:1559)
==19129== by 0x11086C: mt_svc_exit_handler (monitor.c:2754)
==19129== by 0x8AF9B2F: sss_child_invoke_cb (child_common.c:181)
==19129== by 0x4E39823: tevent_common_loop_immediate (tevent_immediate.c:135)
==19129== by 0x4E3AF4D: poll_event_loop_once (tevent_poll.c:649)
==19129== by 0x4E38FEC: _tevent_loop_once (tevent.c:530)
==19129== by 0x4E3AA4A: poll_event_loop_wait (tevent_poll.c:677)
==19129== by 0x84C4B02: server_loop (server.c:668)
==19129== by 0x10D9A6: main (monitor.c:3028)
==19129== Address 0xb8a06c0 is 64 bytes inside a block of size 176 free'd
==19129== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19129== by 0x50472F2: _talloc_free_internal (talloc.c:1057)
==19129== by 0x50472F2: _talloc_free (talloc.c:1581)
==19129== by 0x4E3D0A3: tevent_common_loop_timer_delay (tevent_timed.c:351)
==19129== by 0x4E3AF59: poll_event_loop_once (tevent_poll.c:653)
==19129== by 0x4E38FEC: _tevent_loop_once (tevent.c:530)
==19129== by 0x4E3AA4A: poll_event_loop_wait (tevent_poll.c:677)
==19129== by 0x84C4B02: server_loop (server.c:668)
==19129== by 0x10D9A6: main (monitor.c:3028)
Resolves:
https://fedorahosted.org/sssd/ticket/2572
Reviewed-by: Stephen Gallagher <sgallagh@redhat.com>
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>
There are actually two bugs here:
1) When either the kill(SIGTERM) or kill(SIGKILL) commands returned
failure (for any reason), we would talloc_free(svc) which removed it
from being eligible for restart, resulting in the service never
starting again without an SSSD service restart.
2) There is a fairly wide race condition where it's possible for a
SIGKILL timer to "catch up" to the child exit handler between us
noticing the termination and actually restarting it. The race
happens because we re-enter the mainloop and add a restart
timeout to avoid a quick failure if we keep restarting due to a
transitory issue (the mt_svc object, and therefore the SIGKILL
timer, were never freed until we got to the actual service
restart).
We can minimize this race by recording the timer_event for the
SIGKILL timeout in the mt_svc object. This way, if the process
exits via SIGTERM, we will immediately remove the timer for the
SIGKILL. Additionally, we'll catch the special-case of an ESRCH
response from the kill(SIGKILL) and assume that it means that the
process has exited. The only other two possible errors are
* EINVAL: (an invalid signal was specified) - This should be
impossible, obviously.
* EPERM: This process doesn't have permission to send signals to
this PID. If this happens, it's either an SELinux bug or
else the process has terminated and a new process that
SSSD doesn't control has taken the ID over.
So in the incredibly unlikely case that one of those occurs, we'll
just go ahead and try to start a new process.
This patch also removes the incorrect talloc_free(svc) calls on the
kill() failures and replaces them with an attempt to just start up
the service again and hope for the best.
Resolves:
https://fedorahosted.org/sssd/ticket/2525
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
This reverts commit cff89439b21f8573c6896b09cb1a8d5f9de3144c.
The previous fix was not sufficient and similar warning appears after different
change in function load_configuration.
src/monitor/monitor.c: In function ‘main’:
src/monitor/monitor.c:2962:24: error: ‘monitor’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
monitor->is_daemon = !opt_interactive;
^
cc1: all warnings being treated as errors
It's better to disable optimisation of function load_configuration after fail
in chown(unlink) instead of checking errno for 0 and overriding it with EINVAL.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Resolves: https://fedorahosted.org/sssd/ticket/2506 Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>