zsh-completion: a more style/tag aware _systemctl by llua · Pull Request #5 · systemd/systemd

llua · 2015-06-01T18:52:01Z

using _wanted instead of calling compadd directly. this allows the user to customize
possible matches.

An example being, grouping units by type:
autoload -Uz compinit; compinit
zstyle ':completion:' menu select
zstyle ':completion:' group-name ''
zstyle ':completion:' format 'Completing %d'
zstyle -e ':completion:::systemctl-(((re|)en|dis)able|(re|)start|reload):'
tag-order 'local type; for type in service template target socket;
reply+=( systemd-units:-${type}:${type} ); reply=( "$reply systemd-units:-misc:misc" )'
zstyle ':completion::systemd-units-template' ignored-patterns '^@'
zstyle ':completion::systemd-units-target' ignored-patterns '^.target'
zstyle ':completion::systemd-units-socket' ignored-patterns '^.socket'
zstyle ':completion::systemd-units-service' ignored-patterns '^.service'
zstyle ':completion::systemd-units-misc' ignored-patterns '(@|.(service|socket|target))'

using _wanted instead of calling compadd directly. this allows the user to customize possible matches. An example being, grouping units by type: autoload -Uz compinit; compinit zstyle ':completion:*' menu select zstyle ':completion:*' group-name '' zstyle ':completion:*' format 'Completing %d' zstyle -e ':completion:*:*:systemctl-(((re|)en|dis)able|(*re|)start|reload*):*' \ tag-order 'local type; for type in service template target socket; reply+=( systemd-units:-${type}:${type} ); reply=( "$reply systemd-units:-misc:misc" )' zstyle ':completion:*:systemd-units-template' ignored-patterns '^*@' zstyle ':completion:*:systemd-units-target' ignored-patterns '^*.target' zstyle ':completion:*:systemd-units-socket' ignored-patterns '^*.socket' zstyle ':completion:*:systemd-units-service' ignored-patterns '^*.service' zstyle ':completion:*:systemd-units-misc' ignored-patterns '*(@|.(service|socket|target))' also, <poke> http://lists.freedesktop.org/archives/systemd-devel/2015-May/032012.html

…[email protected] zsh-completion: a more style/tag aware _systemctl

================================================================= ==64281==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a) #1 0x5651f79ad34e in malloc_multiply (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e) #2 0x5651f79b02d6 in strjoin (/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6) #3 0x5651f79be1f5 in files_add (/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5) #4 0x5651f79be6a3 in conf_files_list_strv_internal (/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3) #5 0x5651f79bea24 in conf_files_list_nulstr (/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24) #6 0x5651f79ad01a in main (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a) #7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s). This happens due to the wrong cleanup attribute is used (free vs strv_free)

If systemd is built with GCC address sanitizer or leak sanitizer the following memory leak ocurs: May 12 02:02:46 linux.site systemd[326]: ================================================================= May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected memory leaks May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 object(s) allocated from: May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f) May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap src/shared/strv.c:163 May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185 May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223 May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828 May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121 May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667 May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 object(s) allocated from: May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f) May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap src/shared/strv.c:152 May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185 May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223 May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828 May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121 May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667 May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) leaked in 4 allocation(s). There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_

$ /usr/lib/systemd/systemd-timedated (wait until auto-exit) ================================================================= ==396==ERROR: LeakSanitizer: detected memory leaks Direct leak of 928 byte(s) in 1 object(s) allocated from: #0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1) #1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480 #2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576 #3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 #4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 #5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 #6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 #7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 #8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 #9 0x562a83aae1af in main src/timedate/timedated.c:730 #10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 77 byte(s) in 1 object(s) allocated from: #0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a) #1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963 #2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 #3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 #4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 #5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 #6 0x562a83aae1af in main src/timedate/timedated.c:730 #7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f) #1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382 #2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601 #3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 #4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 #5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 #6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 #7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 #8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 #9 0x562a83aae1af in main src/timedate/timedated.c:730 #10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s). This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()

Make sure we never close fds before we drop their related event-source. This will cause horrible disruptions if the fd-num is re-used by someone else. Under normal conditions, this should not cause any problems as the close() will drop the fd from the epoll-set automatically. However, this changes if you have any child processes with a copy of that fd. This fixes issue systemd#163. Background: If you create an epoll-set via epoll_create() (lets call it 'EFD') you can add file-descriptors to it to watch for events. Whenever you call EPOLL_CTL_ADD on a file-descriptor you want to watch, the kernel looks up the attached "struct file" pointer, that this FD refers to. This combination of the FD-number and the "struct file" pointer is used as key to link it into the epoll-set (EFD). This means, if you duplicate your file-descriptor, you can watch this file-descriptor, too (because the duplicate will have a different FD-number, hence, the combination of FD-number and "struct file" is different as before). If you want to stop watching an FD, you use EPOLL_CTL_DEL and pass the FD to the kernel. The kernel again looks up your file-descriptor in your FD-table to find the linked "struct file". This FD-number and "struct file" combination is then dropped from the epoll-set (EFD). Last, but not least: If you close a file-descriptor that is linked to an epoll-set, the kernel does *NOTHING* regarding the epoll-set. This is a vital observation! Because this means, your epoll_wait() calls will still return the metadata you used to watch/subscribe your file-descriptor to events. There is one exception to this rule: If the file-descriptor that you just close()ed was the last FD that referred to the underlying "struct file", then _all_ epoll-set watches/subscriptions are destroyed. Hence, if you never dup()ed your FD, then a simple close() will also unsubscribe it from any epoll-set. With this in mind, lets look at fork(): Assume you have an epoll-set (EFD) and a bunch of FDs subscribed to events on that EFD. If you now call fork(), the new process gets a copy of your file-descriptor table. This means, the whole table is copied and the "struct file" reference of each FD is increased by 1. It is important to notice that the FD-numbers in the child are exactly the same as in the parent (eg., FD systemd#5 in the child refers to the same "struct file" as FD systemd#5 in the parent). This means, if the child calls EPOLL_CTL_DEL on an FD, the kernel will look up the linked "struct file" and drop the FD-number and "struct file" combination from the epoll-set (EFD). However, this will effectively drop the subscription that was installed by the parent. To sum up: even though the child gets a duplicate of the EFD and all FDs, the subscriptions in the EFD are *NOT* duplicated! Now, with this in mind, lets look at what udevd does: Udevd has a bunch of file-descriptors that it watches in its sd-event main-loop. Whenever a uevent is received, the event is dispatched on its workers. If no suitable worker is present, a new worker is fork()ed to handle the event. Inside of this worker, we try to free all resources we inherited. However, the fork() call is done from a call-stack that is never rewinded. Therefore, this call stack might own references that it drops once it is left. Those references we cannot deduce from the fork()'ed process; effectively causing us to leak objects in the worker (eg., the call to sd_event_dispatch() that dispatched our uevent owns a reference to the sd_event object it used; and drops it again once the function is left). (Another example is udev_monitor_ref() for each 'worker' that is also inherited by all children; thus keeping the udev-monitor and the uevent-fd alive in all children (which is the real cause for bug systemd#163)) (The extreme variant is sd_event_source_unref(), which explicitly keeps event-sources alive, if they're currently dispatched, knowing that the dispatcher will free the event once done. But if the dispatcher is in the parent, the child will never ever free that object, thus leaking it) This is usually not an issue. However, if such an object has a file-descriptor embedded, this FD is left open and never closed in the child. In manager_exit(), if we now destroy an object (i.e., close its embedded file-descriptor) before we destroy its related sd_event_source, then sd-event will not be able to drop the FD from the epoll-set (EFD). This is, because the FD is no longer valid at the time we call EPOLL_CTL_DEL. Hence, the kernel cannot figure out the linked "struct file" and thus cannot remove the FD-number plus "struct file" combination; effectively leaving the subscription in the epoll-set. Since we leak the uevent-fd in the children, they retain a copy of the FD pointing to the same "struct file". Thus, the EFD-subscription are not automatically removed by close() (as described above). Therefore, the main daemon will still get its metadata back on epoll_watch() whenever an event occurs (even though it already freed the metadata). This then causes the free-after-use bug described in systemd#163. This patch fixes the order in which we destruct objects and related sd-event-sources. Some open questions remain: * Why does source_io_unregister() not warn on EPOLL_CTL_DEL failures? This really needs to be turned into an assert_return(). * udevd really should not leak file-descriptors into its children. Fixing this would *not* have prevented this bug, though (since the child-setup is still async). It's non-trivial to fix this, though. The stack-context of the caller cannot be rewinded, so we cannot figure out temporary refs. Maybe it's time to exec() the udev-workers? * Why does the kernel not copy FD-subscriptions across fork()? Or at least drop subscriptions if you close() your FD (it uses the FD-number as key, so it better subscribe to it)? Or it better used FD+"struct file_table*"+"struct file*" as key to not allow the childen to share the subscription table.. *sigh* Seems like we have to live with that API forever.

$ /usr/lib/systemd/systemd-timedated (wait until auto-exit) ================================================================= ==396==ERROR: LeakSanitizer: detected memory leaks Direct leak of 928 byte(s) in 1 object(s) allocated from: #0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1) systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480 systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576 systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 77 byte(s) in 1 object(s) allocated from: #0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a) systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963 systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f) systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382 systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601 systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s). This is due to missing _cleanup_bus_message_unref_ in context_read_ntp() (cherry picked from commit 6b71bab)

$ /usr/lib/systemd/systemd-timedated (wait until auto-exit) ================================================================= ==396==ERROR: LeakSanitizer: detected memory leaks Direct leak of 928 byte(s) in 1 object(s) allocated from: #0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1) systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480 systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576 systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 77 byte(s) in 1 object(s) allocated from: #0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a) systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963 systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) Indirect leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f) systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382 systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601 systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915 systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051 systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647 systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038 systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94 systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192 systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730 systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s). This is due to missing _cleanup_bus_message_unref_ in context_read_ntp() (cherry picked from commit 6b71bab) Cherry-picked from: 6b71bab Resolves: #1222517

This makes systemctl robust regarding journal truncation. This is a follow-up for 2cf4172 Fixes: Core was generated by `./systemctl status systemd-journald'. Program terminated with signal SIGBUS, Bus error. PID 8569 - core TID 8569: #0 0x00007f246cc89ed6 __memcmp_sse4_1 #1 0x0000557ebbc6f42c journal_file_init_header #2 0x0000557ebbc77262 journal_file_open #3 0x0000557ebbc42999 file_type_wanted #4 0x0000557ebbc42e08 add_any_file #5 0x0000557ebbc43832 add_directory #6 0x0000557ebbc4401c add_root_directory #7 0x0000557ebbc442e9 add_root_directory #8 0x0000557ebbc446fc add_search_paths #9 0x0000557ebbbacb5e show_journal_by_unit #10 0x0000557ebbb8376d print_status_info #11 0x0000557ebbb86a0b show_one #12 0x0000557ebbb87954 show #13 0x0000557ebbc20b1f dispatch_verb #14 0x0000557ebbb90615 systemctl_main #15 0x0000557ebbb9159f main #16 0x00007f246cb3e731 __libc_start_main #17 0x0000557ebbb75ae9 _start

Fixes: Oct 20 09:10:49 systemd-sysusers[144]: Direct leak of 20 byte(s) in 1 object(s) allocated from: Oct 20 09:10:49 systemd-sysusers[144]: #0 0x7f3565a13e60 in malloc (/lib64/libasan.so.3+0xc6e60) Oct 20 09:10:49 systemd-sysusers[144]: #1 0x7f3565526bd0 in malloc_multiply src/basic/alloc-util.h:70 Oct 20 09:10:49 systemd-sysusers[144]: #2 0x7f356552cb55 in tempfn_xxxxxx src/basic/fileio.c:1116 Oct 20 09:10:49 systemd-sysusers[144]: #3 0x7f356552c4f0 in fopen_temporary src/basic/fileio.c:1042 Oct 20 09:10:49 systemd-sysusers[144]: #4 0x7f356555e00e in fopen_temporary_label src/basic/fileio-label.c:63 Oct 20 09:10:49 systemd-sysusers[144]: #5 0x56197c4a1766 in make_backup src/sysusers/sysusers.c:209 Oct 20 09:10:49 systemd-sysusers[144]: #6 0x56197c4a6335 in write_files src/sysusers/sysusers.c:710 Oct 20 09:10:49 systemd-sysusers[144]: #7 0x56197c4ae571 in main src/sysusers/sysusers.c:1817 Oct 20 09:10:49 systemd-sysusers[144]: #8 0x7f3564dee730 in __libc_start_main (/lib64/libc.so.6+0x20730)

"%d (%m) %s\n" crashes asan: google/sanitizers#759 So, let's place %m after %s Fixes: ``` $ ./libtool --mode=execute ./test-selinux ... ============ test_misc ========== ASAN:DEADLYSIGNAL ================================================================= ==2981==ERROR: AddressSanitizer: SEGV on unknown address 0x000041b58ab3 (pc 0x7fd9c55a0eb2 bp 0x7fffdc2f9640 sp 0x7fffdc2f8d68 T0) #0 0x7fd9c55a0eb1 (/lib64/libasan.so.3+0xdeeb1) #1 0x7fd9c5550bbf (/lib64/libasan.so.3+0x8ebbf) #2 0x7fd9c5552cdd in __interceptor_vsnprintf (/lib64/libasan.so.3+0x90cdd) #3 0x7fd9c5063715 in log_internalv src/basic/log.c:680 #4 0x7fd9c506390a in log_internal src/basic/log.c:697 #5 0x561d398181a2 in test_misc src/test/test-selinux.c:81 #6 0x561d398185e8 in main src/test/test-selinux.c:117 #7 0x7fd9c493a400 in __libc_start_main (/lib64/libc.so.6+0x20400) #8 0x561d39817859 in _start (/home/vagrant/systemd-asan/.libs/lt-test-selinux+0x1859) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.3+0xdeeb1) ==2981==ABORTING ```

The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..7b0a5ef 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -168,7 +168,7 @@ static uint8_t msg_advertise[198] = { 0x00, 0x17, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x0b, - 0x03, 0x6c, 0x61, 0x62, 0x05, 0x69, 0x6e, 0x74, + 0x01, 0x6c, 0x01, 0x62, 0x00, 0x0a, 0x6e, 0x74, 0x72, 0x61, 0x00, 0x00, 0x1f, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, @@ -338,9 +338,7 @@ static int test_advertise_option(sd_event *e) { assert_se(!memcmp(addrs, &msg_advertise[124], r * 16)); r = sd_dhcp6_lease_get_domains(lease, &domains); - assert_se(r == 1); - assert_se(!strcmp("lab.intra", domains[0])); - assert_se(domains[1] == NULL); + assert_se(r == -ENOENT); r = sd_dhcp6_lease_get_ntp_addrs(lease, &addrs); assert_se(r == 1); ``` Fixes: ``` ================================================================= ==15043==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 #6 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 #5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 #6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 #7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 #8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 #9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 #10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 #11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 #12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 #13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```

The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..4e14d8f 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -286,6 +286,8 @@ static int test_advertise_option(sd_event *e) { assert_se(optlen == 11); assert_se(dhcp6_lease_set_domains(lease, optval, optlen) >= 0); + assert_se(dhcp6_lease_set_domains(lease, optval, + optlen) >= 0); break; case SD_DHCP6_OPTION_SNTP_SERVERS: ``` Fixes: ``` ==27369==ERROR: LeakSanitizer: detected memory leaks Direct leak of 10 byte(s) in 1 object(s) allocated from: #0 0x7f90e7d21160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f90e7467f69 in strv_extend src/basic/strv.c:552 #2 0x5612fcc19379 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x5612fcc1acdf in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x5612fcc06b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x5612fcc0a987 in main src/libsystemd-network/test-dhcp6-client.c:761 #6 0x7f90e6d46400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 10 byte(s) leaked in 1 allocation(s). ```

We would only log a terse message when pid1 or systemd-journald crashed. It seems better to reuse the normal code paths as much as possible, with the following differences: - if pid1 crashes, we cannot launch the helper, so we don't analyze the coredump, just write it to file directly from the helper invoked by the kernel; - if journald crashes, we can produce the backtrace, but we don't log full structured messages. With comparison to previous code, advantages are: - we go through most of the steps, so for example vacuuming is performed, - we gather and log more data. In particular for journald and pid1 crashes we generate a backtrace, and for pid1 crashes we record the metadata (fdinfo, maps, etc.), - coredumpctl shows pid1 crashes. A disavantage (inefficiency) is that we gather metadata for journald crashes which is then ignored because _TRANSPORT=kernel does not support structued messages. Messages for the systemd-journald "crash" have _TRANSPORT=kernel, and _TRANSPORT=journal for the pid1 "crash". Feb 26 16:27:55 systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=11/SEGV Feb 26 16:27:55 systemd[1]: systemd-journald.service: Unit entered failed state. Feb 26 16:37:54 systemd-coredump[18801]: Process 18729 (systemd-journal) of user 0 dumped core. Feb 26 16:37:54 systemd-coredump[18801]: Coredump diverted to /var/lib/systemd/coredump/core.systemd-journal.0.36c14bf3c6ce4c38914f441038990979.18729.1488145074000000.lz4 Feb 26 16:37:54 systemd-coredump[18801]: Stack trace of thread 18729: Feb 26 16:37:54 systemd-coredump[18801]: #0 0x00007f46d6a06b8d fsync (libpthread.so.0) Feb 26 16:37:54 systemd-coredump[18801]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: #6 0x00005577688d2e98 dispatch_message_real (systemd-journald) Feb 26 16:37:54 kernel: systemd-coredum: 9 output lines suppressed due to ratelimiting Feb 26 16:37:54 systemd-journald[18810]: Journal started Feb 26 16:50:59 systemd-coredump[19229]: Due to PID 1 having crashed coredump collection will now be turned off. Feb 26 16:51:00 systemd[1]: Caught <SEGV>, dumped core as pid 19228. Feb 26 16:51:00 systemd[1]: Freezing execution. Feb 26 16:51:00 systemd-coredump[19229]: Process 19228 (systemd) of user 0 dumped core. Stack trace of thread 19228: #0 0x00007fab82075c47 kill (libc.so.6) #1 0x000055fdf7c38b6b crash (systemd) #2 0x00007fab824175c0 __restore_rt (libpthread.so.0) #3 0x00007fab82148573 epoll_wait (libc.so.6) #4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) #5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) #6 0x000055fdf7c4a380 manager_loop (systemd) #7 0x000055fdf7c402c2 main (systemd) #8 0x00007fab82060401 __libc_start_main (libc.so.6) #9 0x000055fdf7c3818a _start (systemd) Poor machine ;)

zonque added a commit that referenced this pull request Jun 2, 2015

Merge pull request #5 from systemd-mailing-devs/1432910411-14517-1-gi…

d4cb023

…[email protected] zsh-completion: a more style/tag aware _systemctl

zonque merged commit d4cb023 into systemd:master Jun 2, 2015

This was referenced Jun 8, 2015

util:bind_remount_recursive() fix "use after free" #96

Merged

localectl, loginctl (sd-bus?) memory leak #185

Closed

teg mentioned this pull request Jun 17, 2015

hashmap debugging is not thread-safe #264

Closed

rickysarraf mentioned this pull request Sep 23, 2015

crash in journald #1353

Closed

Serafean mentioned this pull request Jan 14, 2016

I/O errors on journal files can make apps using sd-journal SIGBUS (such as qtcreator) #2323

Open

elkrejzi mentioned this pull request Jan 22, 2016

systemd-udevd crashes at shutdown #2418

Closed

TKSpyrop mentioned this pull request Jan 26, 2016

systemd-journal-upload dumps core due to SIGABRT, watchdog timeout #2439

Closed

TKSpyrop mentioned this pull request Feb 9, 2016

systemd crash #2558

Closed

glaubitz mentioned this pull request Feb 16, 2016

[sparc64]: systemctl fails with 'Failed to parse bus message: Bad message' #2633

Closed

klement mentioned this pull request Apr 1, 2016

systemd-journal abort when journal capacity exceeded #2924

Closed

1 of 2 tasks

glaubitz mentioned this pull request May 25, 2016

testsuite: test-dhcp-server fails on sparc64 with bus error (unaligned access) #3347

Closed

fsateler mentioned this pull request Dec 19, 2016

systemctl segfault when told to cat a non-existent template unit #4912

Closed

hese10 mentioned this pull request Mar 31, 2017

systemd-journald coredump when file system full #5678

Closed

1 of 2 tasks

taskset mentioned this pull request Sep 15, 2020

automount: fix crash when manager->dev_autofs_fd is -1 #17060

Closed

hexiaowen mentioned this pull request Sep 23, 2020

Assertion 'n_rehashed == n_entries(h)' failed at src/basic/hashmap.c:1206, function resize_buckets() #11497

Closed

JackFangXN mentioned this pull request Sep 24, 2020

journal coredump #17153

Closed

lclgo mentioned this pull request Nov 11, 2020

MOUNT_MOUNTING_DONE triggers assert in mount_start, core generated. #17570

Closed

jcg190701 mentioned this pull request Dec 8, 2020

systemd coredump when it comes to unit_name_to_prefix or unit_name_to_type #17897

Closed

oracle1992 mentioned this pull request Dec 11, 2020

journal: deal better with reading from zeroed out journal mmaps #15557

Merged

y33988979 mentioned this pull request Dec 25, 2020

systemd crash (SIGABRT); and dbus: Failed to activate service 'org.freedesktop.systemd1': timed out #18080

Closed

gaoyi1988 mentioned this pull request Dec 28, 2020

daemon-reexec coredump #18099

Closed

vinithaharimoorthy mentioned this pull request Feb 12, 2021

RFE: add NotBefore= and NotAfter= concept to timer units #16733

Open

ddstreet mentioned this pull request May 25, 2021

networkd crashes when advertising blackhole route thru BGP #19648

Closed

jbowler mentioned this pull request Jul 27, 2021

nss-systemd: conflict with recent pam_unix #20299

Closed

csy97 mentioned this pull request Aug 18, 2021

Always working journald #20473

Closed

iaguis mentioned this pull request Aug 19, 2021

Add RestrictFileSystems= property using LSM BPF #18145

Merged

This was referenced Sep 8, 2021

core: fix free undefined pointer when strdup failed in the first loop #20662

Merged

cmd "systemctl start [email protected]" may cause coredump when some {m,re}alloc failed #20666

Closed

keszybz mentioned this pull request Jan 3, 2022

coredump: do not crash if we failed to acquire exe path #21976

Merged

pawanbadganchi mentioned this pull request Jun 16, 2022

Systemd Crash #23761

Closed

kreijack mentioned this pull request Aug 4, 2022

systemd-boot: add check to EFI / XBOOTLDR partition #22491

Closed

jonnygrant mentioned this pull request Jan 1, 2023

systemd SIGABRT core file manager_clear_jobs_and_units assert(hashmap_isempty(m->jobs)); #25405

Closed

mrc0mmand mentioned this pull request Mar 27, 2023

cryptenroll: fix a memory leak #27018

Merged

ghost mentioned this pull request Jun 19, 2024

kernel: tpm_crb MSFT0101:00: can't request region for resource [mem 0xdc795000-0xdc795fff] #33412

Open

foolstrong mentioned this pull request Nov 7, 2024

hangtask in reboot when dm device has been suspended #35061

Open

vchandap mentioned this pull request Jan 26, 2025

There is a memory leak in systemctl #36178

Closed

jurekb mentioned this pull request Feb 2, 2025

systemd[703]: Assertion 'path_is_absolute(p)' failed at src/basic/chase.c:648, function chase(). Aborting. #36242

Closed

syedire mentioned this pull request Sep 16, 2025

Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected #38945

Closed

Vogtinator mentioned this pull request Oct 27, 2025

systemd status output causes logind to not start autovt@ttyX #39462

Closed

This was referenced Apr 8, 2026

systemd crashed with SIGABRT in bus_node_gc() #41550

Closed

systemd crashed with SIGSEGV in message_append_basic() #41551

Closed

vinorom mentioned this pull request Jun 11, 2026

libnss_systemd: thread_local recursion guard may trigger fatal process _exit(127) on dynamic TLS allocation failure #42559

Closed

ardbiesheuvel mentioned this pull request Aug 1, 2026

TEST-70-TPM2.pcrlock is flaky #41948

Open

Navigation Menu

Repository navigation

zsh-completion: a more style/tag aware _systemctl - #5

zsh-completion: a more style/tag aware _systemctl#5
zonque merged 1 commit into
masterfrom
unknown repository

llua commented Jun 1, 2015

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

llua commented Jun 1, 2015

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants