[systemd-devel] libsystemd-bus and libdbus
Good morning, I'm very interested in systemd's DBUS client library. As far as I understand it brings significant performance improvements over the standard libdbus library. It has actually been designed to one day talk to the kernel-based DBUS implementation, but can also be used to communicate with current non-kernel-based DBUS busses. My questions on this matter are the following: - is libsystemd-bus a straight replacement for libdbus? E.g. can applications currently using libdbus be ported easily to run libsystemd-bus? Or are the APIs provided by libsystemd-bus totally different? - can libsystemd-bus actually be used without using systemd? E.g. is it a standalone library? Thanks for your help. Karoline___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logind: put correct user object paths in introspection data
Sync with user_bus_path() in logind-user-dbus.c
---
src/login/logind-dbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index ec590c0..e76381b 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -2256,7 +2256,7 @@ static DBusHandlerResult manager_message_handler(
}
HASHMAP_FOREACH(user, m-users, i)
-fprintf(f, node name=\user/%llu\/, (unsigned
long long) user-uid);
+fprintf(f, node name=\user/_%llu\/, (unsigned
long long) user-uid);
HASHMAP_FOREACH(session, m-sessions, i) {
p = bus_path_escape(session-id);
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A small issue with user@.service
Dear developers, I had post-poned systemd updates for a long time, because update from 204 to 206 breaks systemd --user. Now start systemd --user manually fails with: Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-46.scope. Failed to create root cgroup hierarchy: Permission denied Failed to allocate manager object: Permission denied Then I learned it seems that systemd --user is supposed to be started by user@.service. So I messed with it for a couple of days. Now I seem to have got everything settled, but there's still a small problem. The thing is, the user@.service is not corresponding to any session. loginctl list-sessions doesn't show it. And because of that, programs started by systemd --user gets access denied when trying to make some dbus method calls. I tried adding pam_systemd.so to the corresponding pam config file, and the result is systemd --user stops working, fails with the same error as mentioned above. Is there a way to solve this? Or is that impossible by design? Regards, Yuxuan Shui. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A small issue with user@.service
Hi Yuxuan, On Fri, 2013-09-20 at 23:36 +0800, Yuxuan Shui wrote: Dear developers, I had post-poned systemd updates for a long time, because update from 204 to 206 breaks systemd --user. Now start systemd --user manually fails with: See previous threads: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012392.html http://lists.freedesktop.org/archives/systemd-devel/2013-August/012517.html I have some patches for things here: https://people.gnome.org/~walters/user-session-patches/README https://people.gnome.org/~walters/user-session-patches/ but it needs a lot more design thought. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: put correct user object paths in introspection data
On Fri, 2013-09-20 at 18:14 +0300, Mantas Mikulėnas wrote: Sync with user_bus_path() in logind-user-dbus.c Right, looks like this was missed with 9444b1f2. Applied, thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] Resolve /dev/console to the active tty instead of just tty0
When resolving /dev/console one would often get tty0 meaning the active VT.
Resolving to the actual tty (e.g. tty1) will notably help on boot when
determining whether or not PID1 can output to the console.
---
src/shared/util.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 9a075fa..391bc1d 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3621,6 +3621,16 @@ char *resolve_dev_console(char **active) {
else
tty = *active;
+if (streq(tty, tty0)) {
+free(*active);
+
+/* Get the active VC (e.g. tty1) */
+if (read_one_line_file(/sys/class/tty/tty0/active, active)
0)
+*active = strdup(tty0);
+
+tty = *active;
+}
+
return tty;
}
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix timeout when stopping Type=notify service
Since 41efeaec a call to service_unwatch_main_pid() is done from
service_set_main_pid(), which is called upon receiving message MAINPID=
This had the side effect of not watching pid anymore, and would result in a
useless timeout when stopping the service, as the unit wouldn't be identified
from the pid, so not marked stopped which would result in systemd thinking this
was a timeout.
---
I'm not exactly familiar with systemd's internals, so this might not be the
correct way to fix this, please correct me if it isn't.
src/core/service.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/core/service.c b/src/core/service.c
index 246a86e..1dccdff 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -3388,9 +3388,17 @@ static void service_notify_message(Unit *u, pid_t pid,
char **tags) {
log_warning_unit(u-id,
Failed to parse notification message
%s, e);
else {
+int r;
+
log_debug_unit(u-id,
%s: got %s, u-id, e);
service_set_main_pid(s, pid);
+r = unit_watch_pid(u, pid);
+if (r 0)
+/* FIXME: we need to do something here */
+log_warning_unit(u-id,
+ Failed to watch PID %lu from
service %s,
+ (unsigned long) pid, u-id);
}
}
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] Fix issues re: visibility of status messages
Hi, I'm running Arch Linux, have been using systemd-204, and recently tried the new 207 release, and I have been having some issues with it. One was that status messages would just stop at some point near the end of the boot process, and also that I wouldn't get any during a shutdown/reboot. It might be useful to note that I don't start a getty on tty1, which is why I expect to see all status messages until default target is reached, even after the getty/login has been started (which happens on tty2). After looking into it, I came up with the following patches to fix the issue. The reason status messages would stop was that the getty was started, and systemd then stopped using the console to avoid collisions w/ gettys. However, as I said I don't have a getty started on tty1 so for me that is a bug, as there's no reason not to keep printing status messages on tty1. The lack of messages on shutdown/reboot was also linked to this, because if no_console_output was set to true during boot, it'd stay there and prevent messages to show up on shutdown. To fix this (in the event it was set to true on boot) a patch simply resets it to false on job_shutdown_magic(), but I'm not exactly sure if that's the right way to do this. FYI I should add that in a similar setup as the one I described, this will not be enough to keep messages on tty1, since fsck's units are now RemainAfterExit (see https://bugs.freedesktop.org/show_bug.cgi?id=66784), which means they're seen by systemd as owning the console (as far as outputing messages there is concerned I mean), and it will therefore stop printing status messages. I'm not sure you want to fix this, as it might be only a cosmetic issue for a small usecase hence not worth the trouble, so I've simply undone it using a .conf file on my end, figured I should mention it though. -jjacky Olivier Brunel (3): Resolve /dev/console to the active tty instead of just tty0 Only disable output on console during boot if needed Fix possible lack of status messages on shutdown/reboot src/core/job.c | 3 +++ src/core/manager.c | 2 +- src/shared/util.c | 10 ++ 3 files changed, 14 insertions(+), 1 deletion(-) -- 1.8.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] Only disable output on console during boot if needed
If there are no more jobs on console, no need/we shouldn't disable output.
---
src/core/manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 669af15..a48d711 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1757,7 +1757,7 @@ static int process_event(Manager *m, struct epoll_event
*ev) {
}
case WATCH_IDLE_PIPE: {
-m-no_console_output = true;
+m-no_console_output = m-n_on_console 0;
manager_unwatch_idle_pipe(m);
close_idle_pipe(m);
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] Fix possible lack of status messages on shutdown/reboot
Since 31a7eb86 the output on console can be disabled to avoid colliding with
gettys. However, it could also lead to a lack of messages during
shutdown/reboot.
---
src/core/job.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/core/job.c b/src/core/job.c
index 85f77e8..fd22184 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -1100,6 +1100,9 @@ void job_shutdown_magic(Job *j) {
if (detect_container(NULL) 0)
return;
+/* In case messages on console has been disabled on boot */
+j-unit-manager-no_console_output = false;
+
asynchronous_sync();
}
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] util, utf8: make ellipsize and ellipsize_mem take into account multi-byte characters
rename old versions to ascii_*
Do not take into account zerowidth characters, but do consider double-wide
characters.
Import needed utf8 helper code from glib.
v3: rebase ontop of utf8 restructuring work
---
TODO | 4 --
src/shared/utf8.c | 120 ++
src/shared/utf8.h | 100 +
src/shared/util.c | 70 ++-
src/shared/util.h | 3 ++
5 files changed, 292 insertions(+), 5 deletions(-)
diff --git a/TODO b/TODO
index 01bc993..c54e986 100644
--- a/TODO
+++ b/TODO
@@ -19,10 +19,6 @@ Bugfixes:
* properly handle .mount unit state tracking when two mount points are stacked
one on top of another on the exact same mount point.
-* ellipsize_mem must take into account multi-byte unicode characters, and
- - make the resulting line the requested number of *characters*, not *bytes*,
- - avoid truncuating multi-byte sequences in the middle.
-
* When we detect invalid UTF-8, we cant't use it in an error message:
log...(Path is not UTF-8 clean, ignoring assignment: %s, rvalue);
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index c3d97cc..2b07265 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -22,6 +22,11 @@
/* This file is based on the GLIB utf8 validation functions. The
* original license text follows. */
+/* gunicode.h - Unicode manipulation functions
+ *
+ * Copyright (C) 1999, 2000 Tom Tromey
+ * Copyright 2000, 2005 Red Hat, Inc.
+ */
/* gutf8.c - Operations on UTF-8 strings.
*
* Copyright (C) 1999 Tom Tromey
@@ -285,3 +290,118 @@ int utf8_encoded_valid_unichar(const char *str) {
return len;
}
+
+/**
+ * g_utf8_prev_char:
+ * @p: a pointer to a position within a UTF-8 encoded string
+ *
+ * Finds the previous UTF-8 character in the string before @p.
+ *
+ * @p does not have to be at the beginning of a UTF-8 character. No check
+ * is made to see if the character found is actually valid other than
+ * it starts with an appropriate byte. If @p might be the first
+ * character of the string, you must use g_utf8_find_prev_char() instead.
+ *
+ * Return value: a pointer to the found character.
+ **/
+char *
+utf8_prev_char (const char *p)
+{
+ while (1)
+{
+ p--;
+ if ((*p 0xc0) != 0x80)
+return (char *)p;
+}
+}
+
+/**
+ * g_utf8_get_char:
+ * @p: a pointer to Unicode character encoded as UTF-8
+ *
+ * Converts a sequence of bytes encoded as UTF-8 to a Unicode character.
+ * If @p does not point to a valid UTF-8 encoded character, results are
+ * undefined. If you are not sure that the bytes are complete
+ * valid Unicode characters, you should use g_utf8_get_char_validated()
+ * instead.
+ *
+ * Return value: the resulting character
+ **/
+unichar
+utf8_get_char (const char *p)
+{
+ int i, mask = 0, len;
+ unichar result;
+ unsigned char c = (unsigned char) *p;
+
+ UTF8_COMPUTE (c, mask, len);
+ if (len == -1)
+return (unichar)-1;
+ UTF8_GET (result, p, i, mask, len);
+
+ return result;
+}
+
+struct Interval
+{
+ unichar start, end;
+};
+
+static int
+interval_compare (const void *key, const void *elt)
+{
+ unichar c = (unichar) (long) (key);
+ struct Interval *interval = (struct Interval *)elt;
+
+ if (c interval-start)
+return -1;
+ if (c interval-end)
+return +1;
+
+ return 0;
+}
+
+/*
+ * NOTE:
+ *
+ * The tables for g_unichar_iswide() and g_unichar_iswide_cjk() are
+ * generated from the Unicode Character Database's file
+ * extracted/DerivedEastAsianWidth.txt using the gen-iswide-table.py
+ * in this way:
+ *
+ * ./gen-iswide-table.py path/to/ucd/extracted/DerivedEastAsianWidth.txt |
fmt
+ *
+ * Last update for Unicode 6.0.
+ */
+
+/**
+ * g_unichar_iswide:
+ * @c: a Unicode character
+ *
+ * Determines if a character is typically rendered in a double-width
+ * cell.
+ *
+ * Return value: %TRUE if the character is wide
+ **/
+bool
+unichar_iswide (unichar c)
+{
+ /* See NOTE earlier for how to update this table. */
+ static const struct Interval wide[] = {
+{0x1100, 0x115F}, {0x2329, 0x232A}, {0x2E80, 0x2E99}, {0x2E9B, 0x2EF3},
+{0x2F00, 0x2FD5}, {0x2FF0, 0x2FFB}, {0x3000, 0x303E}, {0x3041, 0x3096},
+{0x3099, 0x30FF}, {0x3105, 0x312D}, {0x3131, 0x318E}, {0x3190, 0x31BA},
+{0x31C0, 0x31E3}, {0x31F0, 0x321E}, {0x3220, 0x3247}, {0x3250, 0x32FE},
+{0x3300, 0x4DBF}, {0x4E00, 0xA48C}, {0xA490, 0xA4C6}, {0xA960, 0xA97C},
+{0xAC00, 0xD7A3}, {0xF900, 0xFAFF}, {0xFE10, 0xFE19}, {0xFE30, 0xFE52},
+{0xFE54, 0xFE66}, {0xFE68, 0xFE6B}, {0xFF01, 0xFF60}, {0xFFE0, 0xFFE6},
+{0x1B000, 0x1B001}, {0x1F200, 0x1F202}, {0x1F210, 0x1F23A}, {0x1F240,
+0x1F248}, {0x1F250, 0x1F251}, {0x2, 0x2FFFD}, {0x3, 0x3FFFD}
+ };
+
+ if (bsearch ((long *)c, wide, (sizeof (wide) / sizeof ((wide)[0])), sizeof
wide[0],
+ interval_compare))
+return true;
+
+ return false;
+}
diff --git a/src/shared/utf8.h b/src/shared/utf8.h
index
[systemd-devel] [PATCH 2/2] test: test for ellipsize (manual)
---
Makefile.am | 7 +++
src/test/test-ellipsize.c | 42 ++
2 files changed, 49 insertions(+)
create mode 100644 src/test/test-ellipsize.c
diff --git a/Makefile.am b/Makefile.am
index 89a5c86..802f6eb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1114,6 +1114,7 @@ manual_tests += \
test-cgroup \
test-install \
test-watchdog \
+ test-ellipsize \
test-log
tests += \
@@ -1319,6 +1320,12 @@ test_log_SOURCES = \
test_log_LDADD = \
libsystemd-core.la
+test_ellipsize_SOURCES = \
+ src/test/test-ellipsize.c
+
+test_ellipsize_LDADD = \
+ libsystemd-core.la
+
test_date_SOURCES = \
src/test/test-date.c
diff --git a/src/test/test-ellipsize.c b/src/test/test-ellipsize.c
new file mode 100644
index 000..fab5e4b
--- /dev/null
+++ b/src/test/test-ellipsize.c
@@ -0,0 +1,42 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2013 Shawn Landden
+
+ 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 stdio.h
+
+#include util.h
+#include utf8.h
+
+static void test_one(const char *p) {
+_cleanup_free_ char *t = NULL;
+t = ellipsize(p, 80, 70);
+puts(t);
+}
+
+int main(int argc, char *argv[]) {
+
test_one(??);
+
test_one(-?);
+
test_one(-??);
+test_one(s??st??md s??st??md s??st??md s??st??md s??st??md s??st??md
s??st??md s??st??md s??st??md s??st??md s??st??md s??st??md s??st??md);
+
test_one();
+test_one(Lorem ipsum dolor sit amet, consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit
esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.);
+
+return 0;
+}
--
1.8.4.rc3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A small issue with user@.service
Hi, On Sat, Sep 21, 2013 at 1:47 AM, Colin Walters walt...@verbum.org wrote: Hi Yuxuan, On Fri, 2013-09-20 at 23:36 +0800, Yuxuan Shui wrote: Dear developers, I had post-poned systemd updates for a long time, because update from 204 to 206 breaks systemd --user. Now start systemd --user manually fails with: See previous threads: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012392.html http://lists.freedesktop.org/archives/systemd-devel/2013-August/012517.html I have some patches for things here: https://people.gnome.org/~walters/user-session-patches/README https://people.gnome.org/~walters/user-session-patches/ but it needs a lot more design thought. I've thought about it for a while. I still want the ability of running a single systemd per session back. And I think that's possible, we just need to give systemd the ability to start services under a given session.scope. Regards, Yuxuan Shui. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
