Re: [systemd-devel] [PATCH 0/7] kdbus related libsystemd-bus patches
On 11/15/2013 07:32 PM, Daniel Mack wrote: Hi! What's missing and still under development is a service that provides org.freedesktop.DBus on kdbus, and which translates the native interface to calls in libsystemd-bus. This almost works now, but there are some missing pieces in libsystemd-bus which need to be done first. Is your development version of org.freedesktop.DBus daeamon available somewhere? We would like to take a look if we can make our kdbus-glib bindings[1] work with it (and if not - make it work together). [1] https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg14385.html Cheers Karol ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] tests: Add test-bus-kernel-monitor
test-bus-kernel-monitor is very simple program used to monitor all
messages/signals going through a kdbus message bus. It allows
monitor an arbitrary kernel bus given at --bus_path parameter and
also monitor system and session kernel bus (implemented but disabled
at this moment).
---
Makefile.am | 12 ++
src/libsystemd-bus/test-bus-kernel-monitor.c | 179 +++
2 files changed, 191 insertions(+)
create mode 100644 src/libsystemd-bus/test-bus-kernel-monitor.c
diff --git a/Makefile.am b/Makefile.am
index 7c62414..a4752a2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2058,6 +2058,7 @@ tests += \
test-bus-kernel \
test-bus-kernel-bloom \
test-bus-kernel-benchmark \
+ test-bus-kernel-monitor \
test-bus-memfd \
test-bus-zero-copy \
test-bus-introspect \
@@ -2202,6 +2203,17 @@ test_bus_kernel_benchmark_LDADD = \
libsystemd-daemon-internal.la \
libsystemd-shared.la
+test_bus_kernel_monitor_SOURCES = \
+ src/libsystemd-bus/test-bus-kernel-monitor.c
+
+test_bus_kernel_monitor_LDADD = \
+ libsystemd-bus-internal.la \
+ libsystemd-id128-internal.la \
+ libsystemd-daemon-internal.la \
+ libsystemd-shared.la \
+ libsystemd-bus-dump.la \
+ libsystemd-capability.la
+
test_bus_memfd_SOURCES = \
src/libsystemd-bus/test-bus-memfd.c
diff --git a/src/libsystemd-bus/test-bus-kernel-monitor.c
b/src/libsystemd-bus/test-bus-kernel-monitor.c
new file mode 100644
index 000..27642d2
--- /dev/null
+++ b/src/libsystemd-bus/test-bus-kernel-monitor.c
@@ -0,0 +1,179 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2013 Lukasz Skalski
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include getopt.h
+#include signal.h
+
+#include log.h
+#include sd-bus.h
+#include bus-message.h
+#include bus-kernel.h
+#include bus-util.h
+#include bus-dump.h
+
+#define DEFAULT_BUS_KERNEL_PATH kernel:path=/dev/kdbus/deine-mutter/bus
+
+sd_bus *bus = NULL;
+sd_bus_message *msg = NULL;
+const char *arg_address = DEFAULT_BUS_KERNEL_PATH;
+//static bool arg_user = false;
+
+
+static int help(void) {
+
+printf(%s [OPTIONS...]\n\n
+ Monitor the kernel bus.\n\n
+--help Show this help\n
+--bus_path=PATH Path to the kernel bus (default:
%s)\n,
+ // --system Connect to system bus\n
+ // --user Connect to user bus\n
+ program_invocation_short_name, DEFAULT_BUS_KERNEL_PATH);
+
+return 0;
+}
+
+static int parse_argv(int argc, char *argv[]) {
+
+enum {
+ARG_ADDRESS,
+ARG_SYSTEM,
+ARG_USER,
+};
+
+static const struct option options[] = {
+{ help, no_argument, NULL, 'h'},
+{ bus_path, required_argument, NULL, ARG_ADDRESS},
+{ system, no_argument, NULL, ARG_SYSTEM },
+{ user, no_argument, NULL, ARG_USER },
+{},
+};
+
+int c;
+
+assert(argc = 0);
+assert(argv);
+
+while ((c = getopt_long(argc, argv, , options, NULL)) = 0) {
+
+switch (c) {
+
+case 'h':
+return help();
+
+case ARG_ADDRESS:
+arg_address = optarg;
+break;
+
+/*
+case ARG_USER:
+arg_user = true;
+break;
+
+case ARG_SYSTEM:
+arg_user = false;
+break;
+*/
+
+case '?':
+return -EINVAL;
+
+default:
+assert_not_reached(Unhandled option);
+}
+}
+
+return 1;
+}
+
+static void do_exit(int sig_no) {
+
+sd_bus_unref(bus);
+exit (EXIT_SUCCESS);
+}
+
+int main(int argc, char *argv[]) {
+
+int r;
+
+log_set_max_level(LOG_DEBUG);
+
+if (signal(SIGINT, do_exit) == SIG_ERR)
+return EXIT_TEST_SKIP;
+
+r =
[systemd-devel] [PATCH 1/2] bus: Add bus_kernel_monitor function
---
src/libsystemd-bus/bus-kernel.c | 16
src/libsystemd-bus/bus-kernel.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
index ca36eb8..603aa97 100644
--- a/src/libsystemd-bus/bus-kernel.c
+++ b/src/libsystemd-bus/bus-kernel.c
@@ -1196,3 +1196,19 @@ int bus_kernel_create_namespace(const char *name, char
**s) {
return fd;
}
+
+int bus_kernel_monitor(sd_bus *bus) {
+struct kdbus_cmd_monitor cmd_monitor;
+int r;
+
+assert(bus);
+
+cmd_monitor.id = 0;
+cmd_monitor.flags = KDBUS_MONITOR_ENABLE;
+
+r = ioctl(bus-input_fd, KDBUS_CMD_MONITOR, cmd_monitor);
+if (r 0)
+return -errno;
+
+return 1;
+}
diff --git a/src/libsystemd-bus/bus-kernel.h b/src/libsystemd-bus/bus-kernel.h
index a9dddc2..7ad49a5 100644
--- a/src/libsystemd-bus/bus-kernel.h
+++ b/src/libsystemd-bus/bus-kernel.h
@@ -73,3 +73,5 @@ int bus_kernel_parse_unique_name(const char *s, uint64_t *id);
int kdbus_translate_request_name_flags(uint64_t sd_bus_flags, uint64_t
*kdbus_flags);
int kdbus_translate_attach_flags(uint64_t sd_bus_flags, uint64_t *kdbus_flags);
+
+int bus_kernel_monitor(sd_bus *bus);
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] nspawn: --populate to run static binaries on empty target directory
On Mon, Dec 2, 2013 at 9:41 AM, Shawn Landden sh...@churchofgit.com wrote:
On Mon, Dec 2, 2013 at 8:27 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Sat, 30.11.13 10:20, Shawn Landden (sh...@churchofgit.com) wrote:
nspawn has been called chroot on steroids.
Continue that tradition by supporting target directories that
are not root directories.
This patch handles the simple case: a static binary.
Hmm, I am not sure how I feel about this. This appears a bit too
specific for me, and given the requirement for static binaries this is
also so limited.
The next patch is the series adds support for dynamic libraries. This patch
also doesn't need bind mounts, and it executes through /proc/self/fd/%n, but
support for one-file scripts and dynamic libraries in the next patch does
require bind mounts. I feel you don't really understand my patch. :/
I'll sum up what I'm doing:
If --populate is passed, analyze the executable, which opens it and set the
exec path to /proc/self/fd/%n. If executable is static this is all you
have to do.
If it has a shebang, analyze that. If either the shebang or executable
is dynamic,
test if the linker is the GNU linker, and if it is have the linker
tell use what libraries the
executable needs. Then bind mount the linker, shebang (if there is one), and
libraries into the target.
Unmount these when the machine shuts down.
I wonder if we can find a different way to support this, without adding
high-level switches to nspawn itself.
For example, couldn't extending --bind= a bit to also support bind
mounting files (in contrast to just directories the way it currently
does) already gets us 90% of the way? And then do the rest 10% by adding
an example how to use this to bind mount static binaries from the host
into the container to the example in the man page? Allowing bind
mounting of files has been on the TODO list for a while anyway...
I'll add a bind mount file feature, and then rebase the second patch
on top of that.
Something like:
# systemd-nspawn -D /srv/mycontainer
--bind=/usr/bin/populate-container:/tmp/populate-container
/tmp/populate-container
This of course wouldn't check if the file executed is staticall linked,
but the user should quickly get an error about missing .sos if it isn't?
No, the linker would be missing, and the user would get execvpe()
failed: No such file or directory,
which is confusing.
assert_se(sigemptyset(mask) == 0);
@@ -1164,7 +1195,7 @@ int main(int argc, char *argv[]) {
gid_t gid = (gid_t) -1;
unsigned n_env = 2;
const char *envp[] = {
-
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin,
+DEFAULT_PATH_SPLIT_USR,
This bit looks like like something we really should do though. Could you
isolate this out and resubmit, please?
+#define DEFAULT_PATH_SPLIT_USR
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+
#ifdef HAVE_SPLIT_USR
-# define DEFAULT_PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+# define DEFAULT_PATH DEFAULT_PATH_SPLIT_USR
#else
# define DEFAULT_PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
#endif
@@ -51,6 +53,7 @@ int path_is_mount_point(const char *path, bool
allow_symlink);
int path_is_read_only_fs(const char *path);
int path_is_os_tree(const char *path);
And this too, of course...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
On Saturday 30 November 2013 19:30:12 you wrote: There are standard dbus PropertiesChanged signals sent out for ActiveState changes, which invalidate the properties when they change in released versions of systemd, and which carry the new values along in git. We probably should document which ones we generate this for in http://www.freedesktop.org/wiki/Software/systemd/dbus/ Lennart Thanks for your reply. I have now been playing around with the PropertiesChanged signal and found it quite useful for getting updates from systemd. By hooking it up with a Qt slot I can update the UI on any unit changes. The only drawback is that I am not able to get information about which unit had its properties changed from the signal, so I have to update the entire list of units. However, this is much better than querying for unit changes at certain time intervals. Another issue I noticed is that enabling/disabling a unit's files through the dbus methods (EnableUnitFiles/DisableUnitFiles) does not update the UnitFileState property for the unit. When enabling/disabling units using the systemctl tool, the systemd daemon gets reloaded so the property gets updated. Is this the intended behavior? Regards, Ragnar Thomsen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
Hi, - Original Message - On Saturday 30 November 2013 19:30:12 you wrote: There are standard dbus PropertiesChanged signals sent out for ActiveState changes, which invalidate the properties when they change in released versions of systemd, and which carry the new values along in git. We probably should document which ones we generate this for in http://www.freedesktop.org/wiki/Software/systemd/dbus/ Lennart Thanks for your reply. I have now been playing around with the PropertiesChanged signal and found it quite useful for getting updates from systemd. By hooking it up with a Qt slot I can update the UI on any unit changes. The only drawback is that I am not able to get information about which unit had its properties changed from the signal, so I have to update the entire list of units. However, this is much better than querying for unit changes at certain time intervals. If I read Lennart's answer correctly, the newer version in git already tells you what have changed: and which carry the new values along in git Is this right? -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
On Tuesday 03 December 2013 17:34:06 Holger Winkelmann wrote: If I read Lennart's answer correctly, the newer version in git already tells you what have changed: and which carry the new values along in git Is this right? Yes, the properties and their new values can be retrieved, but not which unit had its properties changed. Regards, Ragnar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
On Tue, 03.12.13 17:26, Ragnar Thomsen (rthoms...@gmail.com) wrote: On Saturday 30 November 2013 19:30:12 you wrote: There are standard dbus PropertiesChanged signals sent out for ActiveState changes, which invalidate the properties when they change in released versions of systemd, and which carry the new values along in git. We probably should document which ones we generate this for in http://www.freedesktop.org/wiki/Software/systemd/dbus/ Lennart Thanks for your reply. I have now been playing around with the PropertiesChanged signal and found it quite useful for getting updates from systemd. By hooking it up with a Qt slot I can update the UI on any unit changes. The only drawback is that I am not able to get information about which unit had its properties changed from the signal, so I have to update the entire list of units. However, this is much better than querying for unit changes at certain time intervals. Hmm? In D-Bus signals are sent out by an object which is identified by its object path. In this case we sent out the PropertiesChanged signals from the unit objects, sind those are the ones that change... ListUnits() will include the object paths of all unit it lists and PopertiesChanged is sent from the same objects paths, so you have got everything you need... Another issue I noticed is that enabling/disabling a unit's files through the dbus methods (EnableUnitFiles/DisableUnitFiles) does not update the UnitFileState property for the unit. When enabling/disabling units using the systemctl tool, the systemd daemon gets reloaded so the property gets updated. Is this the intended behavior? Yes, we do not reload status on disk, unless the whole daemon is reloaded. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with a systemd/mdadm interaction.
On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov arvidj...@gmail.com
wrote:
В Tue, 12 Nov 2013 21:17:19 +1100
NeilBrown ne...@suse.de пишет:
On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
Alternately, is there some all devices have been probed, nothing
new will
appear unless it is hot-plugged event. That would be equally
useful (and
probably mirrors what hardware-RAID cards do).
No, there's no way to ever know this in a hotplug world, sorry.
Especially with USB devices, they show up when they show up, there's
no
oh look, the bus is all scanned now and all devices currently plugged
in are found type knowledge at all.
Then there are hotplug PCI systems where people slam in PCI cards
whenever they feel like it (remember, thunderbolt is PCI express...)
Sorry,
greg k-h
Surely something must be possible.
For USB, nope, there isn't, sorry.
Clearly a physical hot-plug event will cause more devices to appear, but
there must come a point at which no more (non-virtual) devices will
appear
unless a physical event happens?
Not for USB, sorry.
The USB bus just announces devices when it finds them, there is no all
is quiet type signal or detection.
Same for PCI hotplug, devices can show up at any point in time, you
never know when, and you don't know when all devices are found.
sorry,
greg k-h
Hmmm... OK. USB doesn't bother me a lot, but PCI is important.
I guess I'll just have to settle for a timeout much like the current
device-discovery timeout that systemd has.
Still hoping someone can tell me how to plug into that though...
If information about array name or other identification is available in
udev rule (I see reference to device node only) what you can do is to
start timer with now+5second (pick your timeout) that simply fires off
mdadm -IRs for specific array. Something like
mdadm-last-resort@.timer
[Timer]
OnCalendar=+5s
mdadm-last-resort@.service
[Service]
Type=oneshot
ExecStart=/sbin/mdadm -IRs %n
udev rule
... SYSTEMD_WANTS=mdadm-last-resort@$ENV{SOMETHING_UNIQUE}.timer
Just wanted to let you know that I've gone ahead with this approach and it
seems to work OK. It took me a while to find DefaultDependencies=no which
I need to make it work, but otherwise it appears to work as advertise.
The relevant files will be in the next release of mdadm.
Thanks again,
NeilBrown
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/7] libsystemd-bus: bring definitions in sync with kdbus
On 2013-11-15, 19:32 +0100, Daniel Mack wrote:
In particular, KDBUS_ITEM_NEXT is now called KDBUS_PART_NEXT, and
KDBUS_ITEM_FOREACH was renamed to KDBUS_PART_FOREACH and takes one more
argument to make it more flexible.
[...]
---
src/libsystemd-bus/bus-control.c | 2 +-
src/libsystemd-bus/bus-kernel.c | 12 ++--
src/libsystemd-bus/bus-kernel.h | 14 +++---
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/libsystemd-bus/bus-control.c
b/src/libsystemd-bus/bus-control.c
index f217269..5c9e746 100644
--- a/src/libsystemd-bus/bus-control.c
+++ b/src/libsystemd-bus/bus-control.c
@@ -468,7 +468,7 @@ int bus_add_match_internal(
item-type = KDBUS_MATCH_BLOOM;
memcpy(item-data64, bloom, BLOOM_SIZE);
-item = KDBUS_ITEM_NEXT(item);
+item = KDBUS_PART_NEXT(item);
}
if (sender) {
diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
index bf8de04..3ea85d4 100644
--- a/src/libsystemd-bus/bus-kernel.c
+++ b/src/libsystemd-bus/bus-kernel.c
@@ -409,7 +409,7 @@ static void close_kdbus_msg(sd_bus *bus, struct kdbus_msg
*k) {
off = (uint8_t *)k - (uint8_t *)bus-kdbus_buffer;
ioctl(bus-input_fd, KDBUS_CMD_MSG_RELEASE, off);
-KDBUS_ITEM_FOREACH(d, k) {
+KDBUS_PART_FOREACH(d, k, items) {
if (d-type == KDBUS_MSG_FDS)
close_many(d-fds, (d-size - offsetof(struct
kdbus_item, fds)) / sizeof(int));
@@ -435,7 +435,7 @@ static int bus_kernel_make_message(sd_bus *bus, struct
kdbus_msg *k, sd_bus_mess
if (k-payload_type != KDBUS_PAYLOAD_DBUS1)
return 0;
-KDBUS_ITEM_FOREACH(d, k) {
+KDBUS_PART_FOREACH(d, k, items) {
size_t l;
l = d-size - offsetof(struct kdbus_item, data);
@@ -489,7 +489,7 @@ static int bus_kernel_make_message(sd_bus *bus, struct
kdbus_msg *k, sd_bus_mess
if (r 0)
return r;
-KDBUS_ITEM_FOREACH(d, k) {
+KDBUS_PART_FOREACH(d, k, items) {
size_t l;
l = d-size - offsetof(struct kdbus_item, data);
@@ -668,13 +668,13 @@ int bus_kernel_create(const char *name, char **s) {
l = strlen(name);
make = alloca0(offsetof(struct kdbus_cmd_bus_make, items) +
- KDBUS_ITEM_HEADER_SIZE + sizeof(uint64_t) +
- KDBUS_ITEM_HEADER_SIZE + DECIMAL_STR_MAX(uid_t) + 1 +
l + 1);
+ KDBUS_PART_HEADER_SIZE + sizeof(uint64_t) +
+ KDBUS_PART_HEADER_SIZE + DECIMAL_STR_MAX(uid_t) + 1 +
l + 1);
n = make-items;
n-type = KDBUS_MAKE_NAME;
sprintf(n-str, %lu-%s, (unsigned long) getuid(), name);
-n-size = KDBUS_ITEM_HEADER_SIZE + strlen(n-str) + 1;
+n-size = KDBUS_PART_HEADER_SIZE + strlen(n-str) + 1;
make-size = offsetof(struct kdbus_cmd_bus_make, items) + n-size;
make-flags = KDBUS_MAKE_POLICY_OPEN;
diff --git a/src/libsystemd-bus/bus-kernel.h b/src/libsystemd-bus/bus-kernel.h
index c4573c9..69df4f4 100644
--- a/src/libsystemd-bus/bus-kernel.h
+++ b/src/libsystemd-bus/bus-kernel.h
@@ -23,16 +23,16 @@
#include sd-bus.h
-#define KDBUS_ITEM_NEXT(item) \
+#define KDBUS_PART_NEXT(item) \
(typeof(item))(((uint8_t *)item) + ALIGN8((item)-size))
-#define KDBUS_ITEM_FOREACH(item, head)
\
-for (item = (head)-items;
\
- (uint8_t *)(item) (uint8_t *)(head) + (head)-size;
\
- item = KDBUS_ITEM_NEXT(item))
+#define KDBUS_PART_FOREACH(part, head, first) \
+for (part = (head)-first; \
+ (uint8_t *)(part) (uint8_t *)(head) + (head)-size; \
+ part = KDBUS_PART_NEXT(part))
-#define KDBUS_ITEM_HEADER_SIZE offsetof(struct kdbus_item, data)
-#define KDBUS_ITEM_SIZE(s) ALIGN8((s) + KDBUS_ITEM_HEADER_SIZE)
+#define KDBUS_PART_HEADER_SIZE offsetof(struct kdbus_item, data)
[...]
+#define KDBUS_ITEM_SIZE(s) ALIGN8((s) + KDBUS_PART_HEADER_SIZE)
We missed this one? KDBUS_ITEM_SIZE/KDBUS_PART_SIZE
Actually, I have a stupid question, do we have any particular reason
to use part/PART? giving the fact that we already have term item
everywhere in the code...
struct kdbus_item, items, kdbus_msg.items...
My opinion, on the contrary, we should replace all the KDBUS_PART_xxx
into KDBUS_ITEM_xxx, that seems more reasonable to me :)
[Same question to the kdbus code as well]
Thanks,
Kangkai
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
[systemd-devel] Occasion hang an reboot - related to user@0.service
Hi, I'm using openSUSE-13.1 which has systemd-208 (plus assorted patches, most from later releases I think) and Linux 3.11.6. I have a minimal install with no GUI - I just log in as root on the text console. Sometimes when I type reboot it takes 90 seconds before the reboot completes. This doesn't always happen, but happens often enough to be annoying. I haven't managed to find any pattern suggesting when it does or doesn't hang. If I enable debugging I find that user@0.service is responsible. e.g. I see: [ 24.628214] systemd[1]: user@0.service changed running - stop-sigterm and then after the 90 seconds: [ 114.628465] systemd[1]: user@0.service stopping timed out. Killing. [ 114.628961] systemd[1]: user@0.service changed stop-sigterm - stop-sigkill [ 114.629695] systemd[1]: Received SIGCHLD from PID 828 (systemd). [ 114.629742] systemd[1]: Got SIGCHLD for process 828 (systemd) [ 114.629819] systemd[1]: Child 828 died (code=killed, status=9/KILL) [ 114.629826] systemd[1]: Child 828 belongs to user@0.service [ 114.629842] systemd[1]: user@0.service: main process exited, code=killed, status=9/KILL [ 114.629858] systemd[1]: user@0.service changed stop-sigkill - failed [ 114.630223] systemd[1]: Job user@0.service/stop finished, result=done [ 114.630252] systemd[1]: Stopped User Manager for 0. It sounds similar to http://lists.freedesktop.org/archives/systemd-devel/2013-July/012309.html but the fix mentioned their appears to be present in 208. I added some extra tracing, and it is definitely sending SIGTERM (but not SIGHUP) to the /usr/lib/systemd/systemd --user but that process sometimes doesn't die until the SIGKILL is sent. Any idea what is happening, or how I can extract extra relevant tracing? Thanks, NeilBrown signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Occasion hang an reboot - related to user@0.service
On Dec 3, 2013, at 7:46 PM, NeilBrown ne...@suse.de wrote: It sounds similar to http://lists.freedesktop.org/archives/systemd-devel/2013-July/012309.html but the fix mentioned their appears to be present in 208. I added some extra tracing, and it is definitely sending SIGTERM (but not SIGHUP) to the /usr/lib/systemd/systemd --user but that process sometimes doesn't die until the SIGKILL is sent. Any idea what is happening, or how I can extract extra relevant tracing? The same issue is present in Fedora 20 during all/most of prerelease testing. I recently filed this which has debug logs recorded during shutdown. https://bugzilla.redhat.com/show_bug.cgi?id=1023820 Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] libsystemd-bus: trivial macro KDBUS_PART_HEADER_SIZE replace
It's a little bit cleaner(?) to replace offsetof(struct kdbus_item, data) with
KDBUS_PART_HEADER_SIZE.
---
src/libsystemd-bus/bus-control.c | 16
src/libsystemd-bus/bus-kernel.c | 41
src/libsystemd-bus/bus-kernel.h | 2 +-
3 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/src/libsystemd-bus/bus-control.c b/src/libsystemd-bus/bus-control.c
index 7a772ff..073e7aa 100644
--- a/src/libsystemd-bus/bus-control.c
+++ b/src/libsystemd-bus/bus-control.c
@@ -765,7 +765,7 @@ static int add_name_change_match(sd_bus *bus,
l = name ? strlen(name) : 0;
sz = ALIGN8(offsetof(struct kdbus_cmd_match, items) +
-offsetof(struct kdbus_item, name_change) +
+KDBUS_PART_HEADER_SIZE +
offsetof(struct kdbus_notify_name_change, name) +
l+1);
@@ -776,7 +776,7 @@ static int add_name_change_match(sd_bus *bus,
item = m-items;
item-size =
-offsetof(struct kdbus_item, name_change) +
+KDBUS_PART_HEADER_SIZE +
offsetof(struct kdbus_notify_name_change, name) +
l+1;
@@ -828,7 +828,7 @@ static int add_name_change_match(sd_bus *bus,
* for it */
sz = ALIGN8(offsetof(struct kdbus_cmd_match, items) +
-offsetof(struct kdbus_item, id_change) +
+KDBUS_PART_HEADER_SIZE +
sizeof(struct kdbus_notify_id_change));
m = alloca0(sz);
@@ -837,7 +837,7 @@ static int add_name_change_match(sd_bus *bus,
m-src_id = KDBUS_SRC_ID_KERNEL;
item = m-items;
-item-size = offsetof(struct kdbus_item, id_change) +
sizeof(struct kdbus_notify_id_change);
+item-size = KDBUS_PART_HEADER_SIZE + sizeof(struct
kdbus_notify_id_change);
item-id_change.id = name_id;
/* If the old name is unset or empty, then this can
@@ -907,7 +907,7 @@ static int bus_add_match_internal_kernel(
if (r 0) {
sender = c-value_str;
sender_length = strlen(sender);
-sz += ALIGN8(offsetof(struct kdbus_item, str)
+ sender_length + 1);
+sz += KDBUS_PART_SIZE(sender_length + 1);
}
break;
@@ -999,7 +999,7 @@ static int bus_add_match_internal_kernel(
}
if (using_bloom)
-sz += ALIGN8(offsetof(struct kdbus_item, data64) + BLOOM_SIZE);
+sz += KDBUS_PART_SIZE(BLOOM_SIZE);
m = alloca0(sz);
m-size = sz;
@@ -1009,7 +1009,7 @@ static int bus_add_match_internal_kernel(
item = m-items;
if (using_bloom) {
-item-size = offsetof(struct kdbus_item, data64) + BLOOM_SIZE;
+item-size = KDBUS_PART_HEADER_SIZE + BLOOM_SIZE;
item-type = KDBUS_MATCH_BLOOM;
memcpy(item-data64, bloom, BLOOM_SIZE);
@@ -1017,7 +1017,7 @@ static int bus_add_match_internal_kernel(
}
if (sender) {
-item-size = offsetof(struct kdbus_item, str) + sender_length
+ 1;
+item-size = KDBUS_PART_HEADER_SIZE + sender_length + 1;
item-type = KDBUS_MATCH_SRC_NAME;
memcpy(item-str, sender, sender_length + 1);
}
diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
index b85a10d..56259f5 100644
--- a/src/libsystemd-bus/bus-kernel.c
+++ b/src/libsystemd-bus/bus-kernel.c
@@ -63,7 +63,7 @@ static void append_payload_vec(struct kdbus_item **d, const
void *p, size_t sz)
* zeroes, which is useful to optimize certain padding
* conditions */
-(*d)-size = offsetof(struct kdbus_item, vec) + sizeof(struct
kdbus_vec);
+(*d)-size = KDBUS_PART_HEADER_SIZE + sizeof(struct kdbus_vec);
(*d)-type = KDBUS_ITEM_PAYLOAD_VEC;
(*d)-vec.address = PTR_TO_UINT64(p);
(*d)-vec.size = sz;
@@ -77,7 +77,7 @@ static void append_payload_memfd(struct kdbus_item **d, int
memfd, size_t sz) {
assert(sz 0);
*d = ALIGN8_PTR(*d);
-(*d)-size = offsetof(struct kdbus_item, memfd) + sizeof(struct
kdbus_memfd);
+(*d)-size = KDBUS_PART_HEADER_SIZE + sizeof(struct kdbus_memfd);
(*d)-type = KDBUS_ITEM_PAYLOAD_MEMFD;
(*d)-memfd.fd = memfd;
(*d)-memfd.size = sz;
@@ -91,7 +91,7 @@ static void append_destination(struct kdbus_item **d, const
char *s, size_t leng
*d = ALIGN8_PTR(*d);
-(*d)-size = offsetof(struct kdbus_item, str) + length + 1;
+(*d)-size = KDBUS_PART_HEADER_SIZE +
Re: [systemd-devel] [PATCH 1/7] libsystemd-bus: bring definitions in sync with kdbus
On 12/04/2013 03:31 AM, Yin Kangkai wrote: On 2013-11-15, 19:32 +0100, Daniel Mack wrote: diff --git a/src/libsystemd-bus/bus-kernel.h b/src/libsystemd-bus/bus-kernel.h index c4573c9..69df4f4 100644 --- a/src/libsystemd-bus/bus-kernel.h +++ b/src/libsystemd-bus/bus-kernel.h @@ -23,16 +23,16 @@ #include sd-bus.h -#define KDBUS_ITEM_NEXT(item) \ +#define KDBUS_PART_NEXT(item) \ (typeof(item))(((uint8_t *)item) + ALIGN8((item)-size)) -#define KDBUS_ITEM_FOREACH(item, head) \ -for (item = (head)-items; \ - (uint8_t *)(item) (uint8_t *)(head) + (head)-size; \ - item = KDBUS_ITEM_NEXT(item)) +#define KDBUS_PART_FOREACH(part, head, first) \ +for (part = (head)-first; \ + (uint8_t *)(part) (uint8_t *)(head) + (head)-size; \ + part = KDBUS_PART_NEXT(part)) -#define KDBUS_ITEM_HEADER_SIZE offsetof(struct kdbus_item, data) -#define KDBUS_ITEM_SIZE(s) ALIGN8((s) + KDBUS_ITEM_HEADER_SIZE) +#define KDBUS_PART_HEADER_SIZE offsetof(struct kdbus_item, data) [...] +#define KDBUS_ITEM_SIZE(s) ALIGN8((s) + KDBUS_PART_HEADER_SIZE) We missed this one? KDBUS_ITEM_SIZE/KDBUS_PART_SIZE Actually, I have a stupid question, do we have any particular reason to use part/PART? giving the fact that we already have term item everywhere in the code... struct kdbus_item, items, kdbus_msg.items... My opinion, on the contrary, we should replace all the KDBUS_PART_xxx into KDBUS_ITEM_xxx, that seems more reasonable to me :) Nope. A 'part' is more generic: anything that has size header and a dynamic length is a 'part' and can be iterated over with KDBUS_PART_FOREACH. Hence, an 'item' is a 'part', but not vice versa. See struct kdbus_name_list for example. HTH, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
