Re: [systemd-devel] [PATCH] python-systemd: Reader return special fields and _Reader changes
On Sun, Apr 14, 2013 at 08:55:08PM +0100, Steven Hiscocks wrote:
From: Steven Hiscocks ste...@hiscocks.me.uk
Changes to _Reader make it match closer to C API, by removing `get_next`
and `get_previous`. A `get_all` method added, which returns dictionary
of fields using C API SD_JOURNAL_FOREACH_DATA macro, which can be used
in conjunction with `next`.
_Reader `get`, `next`, `get_{realtime,monotonic,cursor}` and new
`previous` methods are made private. This is so the traversal and
getting of journal fields can be made transparent in the python
interface.
Reader now solely implements `get_next` and `get_previous`, returning a
standard dictionary (future: other mapping types?) with all standard and
special fields through the converters. This makes the output the same as
journalctl json/export format output.
Iterator methods also moved to Reader, as they do not function as intend
with changes to _Reader.
These changes also mean that more optimised journal interfaces can be
made more easily from _Reader, by avoiding getting of unrequired fields
by using the `_get` method, and avoiding field conversions.
Applied. Thanks!
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Lid close event delivered delayed
Hi, something I observed with systemd-195 is that the LidClose event is delivered when switching from X to console while the lid is closed. This is unexpected, and what I expected is instead that nothing occurs. Approximate steps to reproduce, IIRC: 1. Plug in external monitor 2. Boot machine. By way of KMS, output will be cloned to the big screen. 3. When the X desktop is finally running, close laptop lid. (Because the picture is also cloned in this case) In XFCE's power settings, I have set that LidClose does not do anything - for obvious reason. let any amount of time pass 4. Switch to tty1 5. systemd does an S2RAM. So in other words, if you worked for an hour in X and then switch, you get a suspend event out of nowhere without warning notice. # journalctl -n ... Apr 17 06:41:30 nakamura.inai.de systemd-logind[502]: Suspending... Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Sleep. Apr 17 06:41:30 nakamura.inai.de systemd[1]: Reached target Sleep. Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Suspend... Apr 17 06:41:30 nakamura.inai.de systemd-sleep[5315]: Suspending system... (Now I also need to find the knob to turn off suspend in systemd; this was not here before in systemd-44.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] system shutdown: what unit is taking so long?
Hi, I have some hosts with Xen VMs running, and on shutdown, the classic LSB script /etc/init.d/xendomains is used to start and stop the service on openSUSE. There is intricate logic in there to stop/migrate/suspend these VMs according to user preferences. In any case, the shutdown process may take considerably longer than your usual signalling-killing of a process. Under sysvinit, the LSB script would output a status line and update it every second to show it was waiting for the VM to complete shutdown. In systemd, this is no longer the case because LSB output is suppressed and written to the journal instead. That in itself would be fine, but the problem is that on _system_ shutdown, since any login processes will have already be stopped by systemd, there is no way for the admin to check what is going on, and the system just practically sits there as though it would hang. I think systemd should print some status message -- like Shutdown of xendomains.service still running every 5sec, maybe? -- when shutting down some service takes longer than expected. If a login shell on console was not killed until the really last moment (right before umount), that would be even better. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] system shutdown: what unit is taking so long?
On Wed, Apr 17, 2013 at 9:17 AM, Jan Engelhardt jeng...@inai.de wrote: I think systemd should print some status message -- like Shutdown of xendomains.service still running every 5sec, maybe? -- when shutting down some service takes longer than expected. If a login shell on console was not killed until the really last moment (right before umount), that would be even better. Does this commit work for you? http://cgit.freedesktop.org/systemd/systemd/commit/?id=03b717a3c4f9348807fc56e7a7d711d72d4ec0cb ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add one more level on top with AND
Am 12.04.2013 09:29, schrieb har...@redhat.com: From: Harald Hoyer har...@redhat.com When using -p and -b in combination with -u, the output is not what you would expect. The reason is the sd_journal_add_disjunction() call in add_matches_for_unit() and add_matches_for_user_unit(), which adds two ORs without taking the other conditions to every OR. Adding another level on top with AND and sd_journal_add_conjunction() solves the problem. Output before: $ journalctl -o short-monotonic -ab -p 0 -u sshd.service -- Reboot -- [3.216305] lenovo systemd[1]: Starting OpenSSH server daemon... -- Reboot -- [3.168666] lenovo systemd[1]: Starting OpenSSH server daemon... [3.169639] lenovo systemd[1]: Started OpenSSH server daemon. [36285.635389] lenovo systemd[1]: Stopped OpenSSH server daemon. -- Reboot -- [ 10.838657] lenovo systemd[1]: Starting OpenSSH server daemon... [ 10.913698] lenovo systemd[1]: Started OpenSSH server daemon. [ 6881.035183] lenovo systemd[1]: Stopped OpenSSH server daemon. -- Reboot -- [6.636228] lenovo systemd[1]: Starting OpenSSH server daemon... [6.662573] lenovo systemd[1]: Started OpenSSH server daemon. [6.681148] lenovo sshd[397]: Server listening on 0.0.0.0 port 22. [6.681379] lenovo sshd[397]: Server listening on :: port 22. As we see, the output is from _every_ boot and priority 0 is not taken into account. Output after patch: $ journalctl -o short-monotonic -ab -p 0 -u sshd.service -- Logs begin at Sun 2013-02-24 20:54:44 CET, end at Tue 2013-03-19 14:58:21 CET. -- Increasing the priority: $ journalctl -o short-monotonic -ab -p 6 -u sshd.service -- Logs begin at Sun 2013-02-24 20:54:44 CET, end at Tue 2013-03-19 14:59:12 CET. -- [6.636228] lenovo systemd[1]: Starting OpenSSH server daemon... [6.662573] lenovo systemd[1]: Started OpenSSH server daemon. [6.681148] lenovo sshd[397]: Server listening on 0.0.0.0 port 22. [6.681379] lenovo sshd[397]: Server listening on :: port 22. --- src/journal/journal-internal.h | 2 +- src/journal/journalctl.c | 17 +++-- src/journal/sd-journal.c | 80 ++-- src/journal/test-journal-match.c | 16 +++- src/systemd/sd-journal.h | 1 + 5 files changed, 83 insertions(+), 33 deletions(-) pushed ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: clarify usage of --all versus list-unit-files
Am 10.04.2013 14:35, schrieb Zbigniew Jędrzejewski-Szmek: On Wed, Apr 10, 2013 at 12:34:43PM +0200, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com Novice users might think, that $ systemctl --all is equal to $ systemctl list-unit-files https://bugzilla.redhat.com/show_bug.cgi?id=748512 Makes sense. Zbyszek pushed ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] typo? path-util: unify code for detecting OS trees
while reading random patches in cgit I saw
(in commit 6606089752df90f3eeb4924af109046f1c73554c)
...
diff --git a/src/shared/util.h b/src/shared/util.h
index 3aac165..cfb5493 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -684,3 +684,15 @@ int unlink_noerrno(const char *path);
_new_ = alloca(_len_); \
(void *) memset(_new_, 0, _len_); \
})
+
+#define strappenda(a, b) \
+ ({ \
+ const char *_a_ = (a), *_b_ = (b); \
+ char *_c_; \
+ size_t _x_, _y_; \
+ _x_ = strlen(_a_); \
+ _y_ = strlen(_b_); \
+ _c_ = alloca(_x_ + _y_ + 1); \
+ strcpy(stpcpy(_c_, _a_), _b_); \
shouldn't this be more like:
strcat(strcpy(_c_, _a_), _b_);
+ _c_; \
+ })
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V4] core/execute.c: debug log final execve() with argv[]
Am 10.04.2013 11:51, schrieb har...@redhat.com:
From: Harald Hoyer har...@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
src/core/execute.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..fabd38e 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,18 @@ int exec_spawn(ExecCommand *command,
final_env = strv_env_clean(final_env);
+if (_unlikely_(log_get_max_level() = LOG_PRI(LOG_DEBUG))) {
+char _cleanup_free_ *argvs = NULL;
+log_open();
+argvs = strv_join(final_argv[1], );
+log_struct_unit(LOG_DEBUG,
+unit_id,
+EXECUTABLE=%s, command-path,
+MESSAGE=Executing: %s %s,
+command-path, argvs,
+NULL);
+log_close();
+}
execve(command-path, final_argv, final_env);
err = -errno;
r = EXIT_EXEC;
pushed slightly modified
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] typo? path-util: unify code for detecting OS trees
On Wed, Apr 17, 2013 at 09:33:35AM +0200, Peeters Simon wrote:
while reading random patches in cgit I saw
(in commit 6606089752df90f3eeb4924af109046f1c73554c)
...
diff --git a/src/shared/util.h b/src/shared/util.h
index 3aac165..cfb5493 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -684,3 +684,15 @@ int unlink_noerrno(const char *path);
_new_ = alloca(_len_); \
(void *) memset(_new_, 0, _len_); \
})
+
+#define strappenda(a, b) \
+ ({ \
+ const char *_a_ = (a), *_b_ = (b); \
+ char *_c_; \
+ size_t _x_, _y_; \
+ _x_ = strlen(_a_); \
+ _y_ = strlen(_b_); \
+ _c_ = alloca(_x_ + _y_ + 1); \
+ strcpy(stpcpy(_c_, _a_), _b_); \
stpcpy returns the end of the copy, and then strcpy appends
to this end.
Zbyszek
shouldn't this be more like:
strcat(strcpy(_c_, _a_), _b_);
+ _c_; \
+ })
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] login/sd-login.c: make use of _cleanup_free_ and friends
From: Harald Hoyer har...@redhat.com
---
Due to the heavy modification, I send this to the list for review.
src/login/sd-login.c | 200 ---
1 file changed, 61 insertions(+), 139 deletions(-)
diff --git a/src/login/sd-login.c b/src/login/sd-login.c
index c97d75c..9e3e596 100644
--- a/src/login/sd-login.c
+++ b/src/login/sd-login.c
@@ -74,7 +74,7 @@ _public_ int sd_pid_get_machine_name(pid_t pid, char **name) {
_public_ int sd_pid_get_owner_uid(pid_t pid, uid_t *uid) {
int r;
-char *root, *cgroup, *p, *cc;
+char _cleanup_free_ *root = NULL, *cgroup = NULL, *p = NULL, *cc =
NULL;
struct stat st;
if (pid 0)
@@ -87,31 +87,23 @@ _public_ int sd_pid_get_owner_uid(pid_t pid, uid_t *uid) {
if (r 0)
return r;
-if (!startswith(cgroup, /user/)) {
-free(cgroup);
-free(root);
+if (!startswith(cgroup, /user/))
return -ENOENT;
-}
p = strchr(cgroup + 6, '/');
-if (!p) {
-free(cgroup);
+if (!p)
return -ENOENT;
-}
p++;
p += strcspn(p, /);
*p = 0;
r = cg_get_path(SYSTEMD_CGROUP_CONTROLLER, root, cgroup, cc);
-free(root);
-free(cgroup);
if (r 0)
return -ENOMEM;
r = lstat(cc, st);
-free(cc);
if (r 0)
return -errno;
@@ -155,7 +147,8 @@ _public_ int sd_uid_get_state(uid_t uid, char**state) {
}
_public_ int sd_uid_is_on_seat(uid_t uid, int require_active, const char
*seat) {
-char *p, *w, *t, *state, *s = NULL;
+char *w, *state;
+char _cleanup_free_ *t = NULL, *s = NULL, *p = NULL;
size_t l;
int r;
const char *variable;
@@ -170,38 +163,26 @@ _public_ int sd_uid_is_on_seat(uid_t uid, int
require_active, const char *seat)
return -ENOMEM;
r = parse_env_file(p, NEWLINE, variable, s, NULL);
-free(p);
-if (r 0) {
-free(s);
+if (r 0)
return r;
-}
if (!s)
return -EIO;
-if (asprintf(t, %lu, (unsigned long) uid) 0) {
-free(s);
+if (asprintf(t, %lu, (unsigned long) uid) 0)
return -ENOMEM;
-}
FOREACH_WORD(w, l, s, state) {
-if (strneq(t, w, l)) {
-free(s);
-free(t);
-
+if (strneq(t, w, l))
return 1;
-}
}
-free(s);
-free(t);
-
return 0;
}
static int uid_get_array(uid_t uid, const char *variable, char ***array) {
-char *p, *s = NULL;
+char _cleanup_free_ *p = NULL, *s = NULL;
char **a;
int r;
@@ -211,11 +192,7 @@ static int uid_get_array(uid_t uid, const char *variable,
char ***array) {
r = parse_env_file(p, NEWLINE,
variable, s,
NULL);
-free(p);
-
if (r 0) {
-free(s);
-
if (r == -ENOENT) {
if (array)
*array = NULL;
@@ -232,7 +209,6 @@ static int uid_get_array(uid_t uid, const char *variable,
char ***array) {
}
a = strv_split(s, );
-free(s);
if (!a)
return -ENOMEM;
@@ -294,31 +270,27 @@ static int file_of_session(const char *session, char
**_p) {
_public_ int sd_session_is_active(const char *session) {
int r;
-char *p, *s = NULL;
+char _cleanup_free_ *p = NULL, *s = NULL;
r = file_of_session(session, p);
if (r 0)
return r;
r = parse_env_file(p, NEWLINE, ACTIVE, s, NULL);
-free(p);
-if (r 0) {
-free(s);
+if (r 0)
return r;
-}
if (!s)
return -EIO;
r = parse_boolean(s);
-free(s);
return r;
}
_public_ int sd_session_get_state(const char *session, char **state) {
-char *p, *s = NULL;
+char _cleanup_free_ *p = NULL, *s = NULL;
int r;
if (!state)
@@ -329,21 +301,21 @@ _public_ int sd_session_get_state(const char *session,
char **state) {
return r;
r = parse_env_file(p, NEWLINE, STATE, s, NULL);
-free(p);
-if (r 0) {
-free(s);
+if (r 0)
return r;
-} else if (!s)
+else if (!s)
return -EIO;
*state = s;
+s = NULL;
+
return 0;
}
_public_ int sd_session_get_uid(const char *session, uid_t *uid) {
int r;
-char *p, *s = NULL;
+char _cleanup_free_ *p = NULL, *s = NULL;
Re: [systemd-devel] [PATCH] login/sd-login.c: make use of _cleanup_free_ and friends
On Wed, 17.04.13 16:12, har...@redhat.com (har...@redhat.com) wrote: -char *root, *cgroup, *p, *cc; +char _cleanup_free_ *root = NULL, *cgroup = NULL, *p = NULL, *cc = NULL; Hmm, can we agree on a common syntax for this? I tend to put the _cleanup_free_ before the type, and Zbigniew and Harald after. I kinda prefer putting it first, since it puts the emphasis on the cleanup logic, which I think is a good thing, since that's really important to grok the code. i.e. the cleanup stuff is not unessential decoration, but really important, so putting it first sounds good to me. _cleanup_free_ char *s = NULL; char _cleanup_free_ char *t = NULL; I much prefer the first syntax... Opinions? Patch looks good otherwise. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On Wed, 17.04.13 09:46, Mark Hounschell (ma...@compro.net) wrote: I have been using systemd to boot into a very basic target. That target basically executes a script. In that script we execute an su -m -c command user. The last version of systemd I have where this worked is version 37. I'm using opensuse dist and that was in version 12.2 from about a year ago. I've upgraded to opensuse-12.3 and that systemd version is 195. The su -m -c command user now appears to be ignored. I there a particular service I now need to include in my target that will enable the su command to work? I can post my target and service files if required. Have you checked the logs for anything interesting? That's a good way to start figuring out what's going on... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] typo? path-util: unify code for detecting OS trees
On Wed, 17.04.13 09:33, Peeters Simon (peeters.si...@gmail.com) wrote:
while reading random patches in cgit I saw
(in commit 6606089752df90f3eeb4924af109046f1c73554c)
...
diff --git a/src/shared/util.h b/src/shared/util.h
index 3aac165..cfb5493 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -684,3 +684,15 @@ int unlink_noerrno(const char *path);
_new_ = alloca(_len_); \
(void *) memset(_new_, 0, _len_); \
})
+
+#define strappenda(a, b) \
+ ({ \
+ const char *_a_ = (a), *_b_ = (b); \
+ char *_c_; \
+ size_t _x_, _y_; \
+ _x_ = strlen(_a_); \
+ _y_ = strlen(_b_); \
+ _c_ = alloca(_x_ + _y_ + 1); \
+ strcpy(stpcpy(_c_, _a_), _b_); \
shouldn't this be more like:
strcat(strcpy(_c_, _a_), _b_);
Nah, stpcpy() is the best thing since sliced bread for concatenating
strings. Together with mempcpy() and mempset() it's really useful, and a
ton more efficient than strcat().
strcat() always iterates through the first string to find the end,
before appending, and stpcpy() doesn't need that at all anymore.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] login/sd-login.c: make use of _cleanup_free_ and friends
On Wed, Apr 17, 2013 at 04:25:40PM +0200, Lennart Poettering wrote: On Wed, 17.04.13 16:12, har...@redhat.com (har...@redhat.com) wrote: -char *root, *cgroup, *p, *cc; +char _cleanup_free_ *root = NULL, *cgroup = NULL, *p = NULL, *cc = NULL; Hmm, can we agree on a common syntax for this? I tend to put the _cleanup_free_ before the type, and Zbigniew and Harald after. I kinda prefer putting it first, since it puts the emphasis on the cleanup logic, which I think is a good thing, since that's really important to grok the code. i.e. the cleanup stuff is not unessential decoration, but really important, so putting it first sounds good to me. _cleanup_free_ char *s = NULL; char _cleanup_free_ char *t = NULL; I much prefer the first syntax... I don't care strongly, so I'm fine with putting it in front. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] system shutdown: what unit is taking so long?
On Wed, 17.04.13 10:37, Andrey Borzenkov (arvidj...@gmail.com) wrote: On Wed, Apr 17, 2013 at 9:17 AM, Jan Engelhardt jeng...@inai.de wrote: I think systemd should print some status message -- like Shutdown of xendomains.service still running every 5sec, maybe? -- when shutting down some service takes longer than expected. If a login shell on console was not killed until the really last moment (right before umount), that would be even better. Does this commit work for you? http://cgit.freedesktop.org/systemd/systemd/commit/?id=03b717a3c4f9348807fc56e7a7d711d72d4ec0cb This is part of 198 btw. Just update your systemd and you get some beautiful boot-up and shutdown animations on stalled services, hacked up by Michal up. It's so pretty in fact, that it almost makes me want to add sleep(30) or so to all my daemons' startup and shutdown code just to see it. It's like KITT, but in ASCII! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Hi, something I observed with systemd-195 is that the LidClose event is delivered when switching from X to console while the lid is closed. This is unexpected, and what I expected is instead that nothing occurs. Approximate steps to reproduce, IIRC: 1. Plug in external monitor 2. Boot machine. By way of KMS, output will be cloned to the big screen. 3. When the X desktop is finally running, close laptop lid. (Because the picture is also cloned in this case) In XFCE's power settings, I have set that LidClose does not do anything - for obvious reason. let any amount of time pass 4. Switch to tty1 5. systemd does an S2RAM. Well, the current logic is that we suspend when the lid is closed, and no lid switch inhibitor lock is taken. Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME. Which so far sounded like the right thing to do, since GNOME wouldn't get any kbd events anymore if it's not in the fg, so couldn't hande the event anyway, and as soon as you have multiple sessions running at the same time they'd even start fighting for it. So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Report about syntax error in extended format
On Wed, 17.04.13 06:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: If we do this, I am not entirely sure about the name issue though. If we do this I'd like a good name that expresses that this requires resolving by the admin, and sufficiently makes clear that this is not logging but more of a list of current problems, todo checklist or so... Ideas? Any native speakers? I still think that 'issues' sounds nicest. Yeah, I couldn't come up with a different name either, so let's call this issues. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd release agent
On 04/16/2013 07:45 PM, Kevin Wilson wrote: No I moved /usr/lib/systemd/systemd-cgroups-agent to some backup. and made sure that: ls /usr/lib/systemd/systemd-cgroups-agent ls: cannot access /usr/lib/systemd/systemd-cgroups-agent: No such file or directory Now I tried killing two services that I know are under systemd cgroups: cat /sys/fs/cgroup/systemd/system/bluetooth.service/tasks 671 Apr 16 20:40:05 localhost systemd[1]: bluetooth.service: main process exited, code=killed, status=9/KILL Apr 16 20:40:05 localhost systemd[1]: Unit bluetooth.service entered failed state And with mcelog it was the same: ... Apr 16 20:33:46 localhost systemd[1]: mcelog.service: main process exited, code=killed, status=9/KILL Apr 16 20:33:46 localhost systemd[1]: Unit mcelog.service entered failed state ... both folders, bluetooth.service and mcelog.service (under /sys/fs/cgroup/systemd/system/) were removed. How come ? could it be that the messages to the DBus are not sent by systemd-cgroups-agent? In these two cases it was sufficient for systemd to receive the SIGCHLD signal to detect the death of the service. But this won't work for every service. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd release agent
On Tue, 16.04.13 20:45, Kevin Wilson (wkev...@gmail.com) wrote: cat /sys/fs/cgroup/systemd/system/bluetooth.service/tasks 671 Apr 16 20:40:05 localhost systemd[1]: bluetooth.service: main process exited, code=killed, status=9/KILL Apr 16 20:40:05 localhost systemd[1]: Unit bluetooth.service entered failed state And with mcelog it was the same: ... Apr 16 20:33:46 localhost systemd[1]: mcelog.service: main process exited, code=killed, status=9/KILL Apr 16 20:33:46 localhost systemd[1]: Unit mcelog.service entered failed state ... both folders, bluetooth.service and mcelog.service (under /sys/fs/cgroup/systemd/system/) were removed. How come ? could it be that the messages to the DBus are not sent by systemd-cgroups-agent? systemd gets both SIGCHLD for its children and cgroup events for the cgroups they are running in. What you are seening above is the SIGCHLD working. SIGCHLD we only get for the processes we ourselves started, but usually not for processes started by them. SIGCHLD contains exit status information, such as return code, or signal information. The cgroup events we get when the cgroup runs empty, when all our grandchildren are dead, too. It doesn't contain any exist status information, so is not as nice. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: --property support
On Tue, 16.04.13 13:48, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
+__systemd_properties() {
+local mode=$1; shift 1
+{ __systemctl $mode show;
You probaly want to add -a here, since systemctl show normally
suppresses 'empty' properties.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: --property support
On Wed, Apr 17, 2013 at 04:50:19PM +0200, Lennart Poettering wrote:
On Tue, 16.04.13 13:48, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
+__systemd_properties() {
+local mode=$1; shift 1
+{ __systemctl $mode show;
You probaly want to add -a here, since systemctl show normally
suppresses 'empty' properties.
Thanks, fixed.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] system shutdown: what unit is taking so long?
On 04/17/2013 04:33 PM, Lennart Poettering wrote: It's so pretty in fact, that it almost makes me want to add sleep(30) or so to all my daemons' startup and shutdown code just to see it. It's like KITT, but in ASCII! No, no, you're not supposed to like it. You should tremble in fear! It's not a cute KITT, it's a scary Cylon's eye! Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] system shutdown: what unit is taking so long?
On Wed, Apr 17, 2013 at 4:55 PM, Michal Schmidt mschm...@redhat.com wrote: On 04/17/2013 04:33 PM, Lennart Poettering wrote: It's so pretty in fact, that it almost makes me want to add sleep(30) or so to all my daemons' startup and shutdown code just to see it. It's like KITT, but in ASCII! No, no, you're not supposed to like it. You should tremble in fear! It's not a cute KITT, it's a scary Cylon's eye! In a silent environment you can hear it hum. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
On Tue, 16.04.13 09:11, Koen Kooi (k...@dominion.thruhere.net) wrote:
Hi,
To help with flashing the onboard eMMC of a 10 boards I'm using
systemd-nspawn to run package postinstall scripts that generate UUIDs and
some other things and it's working great for that! Every board now has a
unique value in /etc/machine-id instead it being empty and systemd
randomizing it on startup.
What doesn't work however is something like this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone
Europe/Paris
or this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname
BeagleBoneBlack
I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the
name into /etc/hostname, but I'd like to use the *ctl commands because they
work and have error handling built-in.
it looks like I would need -b to get the *ctl commands to work, but -b
doesn't support running single commands and exiting.
timedatectl is just a frontend to timedated. So, without running
timedated inside of the container this is not going to be easy to do.
systemctl enable OTOH also can do the unit file changes on the client
side, since we really needed that for chroot(), and the bits it does are
more than just a creating a symlink here or there...
Now, I am not totally against making some timedatectl comamnds work
without timedated, but let's just say that it's not really that high on
the top of my list...
I see the use of it, but OTOH ln is not thaaat bad to use, and writing
these files with something that isn't timedatectl is absolutely OK the
files are supported stable ABI.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
On Tue, 16.04.13 20:59, Koen Kooi (k...@dominion.thruhere.net) wrote:
Op 16 apr. 2013, om 20:14 heeft Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl het volgende geschreven:
On Tue, Apr 16, 2013 at 09:11:51AM +0200, Koen Kooi wrote:
Hi,
To help with flashing the onboard eMMC of a 10 boards I'm using
systemd-nspawn to run package postinstall scripts that generate UUIDs and
some other things and it's working great for that! Every board now has a
unique value in /etc/machine-id instead it being empty and systemd
randomizing it on startup.
What doesn't work however is something like this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone
Europe/Paris
or this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname
BeagleBoneBlack
I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo
the name into /etc/hostname, but I'd like to use the *ctl commands because
they work and have error handling built-in.
it looks like I would need -b to get the *ctl commands to work, but -b
doesn't support running single commands and exiting.
My goal is to be able to drop in a rootfs tarball and change timezone and
hostname settings in a config file for the flasher script and avoid
generating N different tarballs. For use in the office lab I use something
like [1] to generate the hostnames based on board revision and serial
number.
So, is there a way to *ctl command using systemd-nspawn in a rootfs that
wasn't specially prepared (e.g. helper units/targets) for that?
With very recent systemd just run:
PID=$(head -n1 /sys/fs/cgroup/systemd/machine/$NAME/system/tasks)
nsenter -m -u -i -n -p -t $PID /usr/bin/timedatectl set-timezone
Europe/Paris
...
nsenter -m -u -i -n -p -t $PID systemctl halt
where NAME is either speicified with -M or the name of the tree root.
I'll update my util-linux to get nsenter and give that a try, thanks!
Well, you wouldn't known when the right time is to enter the
machine... After all you#d have to do that after the dbus socket is
established, otherwise your timedatectl will still fail...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd release agent
Hello,
Thanks a lot for your answer and micahl schmidt.
I made several more tests and I wonder whether there are at all
any such tasks with which systemd uses the release agents.
Most of the services uses one process (this is at least what I see when
running cat task from most systemd service folders).
So I assume probably most of them indeed send SIGCHLD to systemd
which is their parent process. (unless someone will pop up and say
that are there any known exceptions to this; I would like to hear
about such exceptions)
There are some exceptions.
Specifically I tried with rsyslog.services and polkit.service.
These two services has each several services in tasks.
with rsyslog.service:
[root@h rsyslog.service]# pstree -p 530
rsyslogd(530)─┬─{rsyslogd}(582)
├─{rsyslogd}(583)
└─{rsyslogd}(584)
ann kill -9 584
gives:
Apr 17 17:59:11 localhost rsyslogd: [origin software=rsyslogd
swVersion=7.2.5 x-pid=8065 x-info=http://www.rsyslog.com;] start
Apr 17 17:59:11 localhost systemd[1]: rsyslog.service: main process
exited, code=killed, status=9/KILL
Apr 17 17:59:11 localhost systemd[1]: Unit rsyslog.service entered failed state
Apr 17 17:59:11 localhost systemd[1]: Starting System Logging Service...
Apr 17 17:59:11 localhost systemd[1]: Started System Logging Service.
The same for polkit:
pstree -p 600
polkitd(600)─┬─{polkitd}(608)
├─{polkitd}(611)
├─{polkitd}(614)
└─{polkitd}(615)
but kill -9 698 did trigger a KILL signal in /var/log/messages:
(and from the ps command we can see that 608 was created by 600).
this is what I see in kernel log:
...
Apr 17 18:02:48 localhost systemd[1]: polkit.service: main process
exited, code=killed, status=9/KILL
Apr 17 18:02:48 localhost systemd[1]: Unit polkit.service entered failed state
...
and of course that systemd-cgroups-agent is missing:
ls /usr/lib/systemd/systemd-cgroups-agent
ls: cannot access /usr/lib/systemd/systemd-cgroups-agent: No such file
or directory
It could be that this threads do send SIGCHLD to systemd. (probably
this is the case).
I wonder if someone knows about a service when a SIGCHLD is not sent?
Or maybe the releas agent is only good for the case when the cgroup
runs empty, when all the grandchildren are dead (as the case
Lennart mentioned).
rgs
Kevin
On Wed, Apr 17, 2013 at 5:48 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 16.04.13 20:45, Kevin Wilson (wkev...@gmail.com) wrote:
cat /sys/fs/cgroup/systemd/system/bluetooth.service/tasks
671
Apr 16 20:40:05 localhost systemd[1]: bluetooth.service: main process
exited, code=killed, status=9/KILL
Apr 16 20:40:05 localhost systemd[1]: Unit bluetooth.service entered
failed state
And with mcelog it was the same:
...
Apr 16 20:33:46 localhost systemd[1]: mcelog.service: main process
exited, code=killed, status=9/KILL
Apr 16 20:33:46 localhost systemd[1]: Unit mcelog.service entered failed
state
...
both folders, bluetooth.service and mcelog.service (under
/sys/fs/cgroup/systemd/system/) were removed.
How come ? could it be that the messages to the DBus are not sent
by systemd-cgroups-agent?
systemd gets both SIGCHLD for its children and cgroup events for the
cgroups they are running in. What you are seening above is the SIGCHLD
working.
SIGCHLD we only get for the processes we ourselves started, but usually
not for processes started by them. SIGCHLD contains exit status
information, such as return code, or signal information.
The cgroup events we get when the cgroup runs empty, when all our
grandchildren are dead, too. It doesn't contain any exist status
information, so is not as nice.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
On Wednesday 2013-04-17 16:42, Lennart Poettering wrote: On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Well, the current logic is that we suspend when the lid is closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME.[...] So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. That reasoning is perfectly fine; the problem is that logind acts upon a physical lid state change from the distant past. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
On Wed, 17.04.13 17:09, Lennart Poettering (lenn...@poettering.net) wrote:
On Tue, 16.04.13 09:11, Koen Kooi (k...@dominion.thruhere.net) wrote:
Hi,
To help with flashing the onboard eMMC of a 10 boards I'm using
systemd-nspawn to run package postinstall scripts that generate UUIDs and
some other things and it's working great for that! Every board now has a
unique value in /etc/machine-id instead it being empty and systemd
randomizing it on startup.
What doesn't work however is something like this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone
Europe/Paris
or this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname
BeagleBoneBlack
I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the
name into /etc/hostname, but I'd like to use the *ctl commands because they
work and have error handling built-in.
it looks like I would need -b to get the *ctl commands to work, but -b
doesn't support running single commands and exiting.
timedatectl is just a frontend to timedated. So, without running
timedated inside of the container this is not going to be easy to do.
Ah, I missed that you'd actually be OK with booting up the whole thing
for this command... You'd just need a nice way to run something after
boot-up is complete, and that immeidately shuts down the container
afterwards, right?
Hmm, here's an idea:
we could add a generator to systemd which looks for systemd.run= or so
on the kernel cmdline and simply generates throw-away unit files from
that, that runs the specified command(s) and triggers a shutdown
afterwards... Would that work for you?
i.e. you'd then call:
systemd-nspawn -bD /srv/foobar \
systemd.run='/usr/bin/timedatectl set-timezone Europe/Paris' \
systemd.run='/usr/bin/timedatectl set-hostname BeagleBoneBlack'
and so on...
I think that would be reasonably pretty?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] login/sd-login.c: make use of _cleanup_free_ and friends
On Wed, 17.04.13 16:30, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Apr 17, 2013 at 04:25:40PM +0200, Lennart Poettering wrote: On Wed, 17.04.13 16:12, har...@redhat.com (har...@redhat.com) wrote: -char *root, *cgroup, *p, *cc; +char _cleanup_free_ *root = NULL, *cgroup = NULL, *p = NULL, *cc = NULL; Hmm, can we agree on a common syntax for this? I tend to put the _cleanup_free_ before the type, and Zbigniew and Harald after. I kinda prefer putting it first, since it puts the emphasis on the cleanup logic, which I think is a good thing, since that's really important to grok the code. i.e. the cleanup stuff is not unessential decoration, but really important, so putting it first sounds good to me. _cleanup_free_ char *s = NULL; char _cleanup_free_ char *t = NULL; I much prefer the first syntax... I don't care strongly, so I'm fine with putting it in front. Cool. So Harald, please move the _cleanup_free_ to the front, and then commit! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd release agent
On Wed, 17.04.13 18:17, Kevin Wilson (wkev...@gmail.com) wrote: Hello, Thanks a lot for your answer and micahl schmidt. I made several more tests and I wonder whether there are at all any such tasks with which systemd uses the release agents. Well, many many services fork of porcesses. Apache does, CUPS does, udev does, cron does, avahi does, libvrit does, upower does, NetworkManager does, accounts-daemon does, atd does, gdm, dbus does, ... Substantially more services that I have running on my system fork off processes than do not. There are some exceptions. Specifically I tried with rsyslog.services and polkit.service. These two services has each several services in tasks. These processes have threads, and the tasks files shows normal processes as well as processes. Threads of course are weird things, and die together with a process. I wonder if someone knows about a service when a SIGCHLD is not sent? Or maybe the releas agent is only good for the case when the cgroup runs empty, when all the grandchildren are dead (as the case Lennart mentioned). Well, look for processes that actually fork off real processes rather than just contain threads... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
On Wed, 17.04.13 17:20, Jan Engelhardt (jeng...@inai.de) wrote: On Wednesday 2013-04-17 16:42, Lennart Poettering wrote: On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Well, the current logic is that we suspend when the lid is closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME.[...] So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. That reasoning is perfectly fine; the problem is that logind acts upon a physical lid state change from the distant past. Well, it is level-triggered, not edge-triggered. If the lid is closed and a lock released we immediately act and suspend. That's the only reliable and safe way to do that. Or are you saying that you had an X session running which took the lock, then closed and reopened the lid, and when you then switched to a VT the machine was suspended? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
On Mon, 15.04.13 20:48, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Apr 15, 2013 at 08:36:33PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 15, 2013 at 02:31:56PM -0300, Chir0n wrote: # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal # systemd-nspawn -bD /srv/mycontainer sudo nsenter -t $PID -m -u -i -n -p /bin/bash Hm, if I say 'halt' in this bash window, I see bash-4.2# halt bash-4.2# [1] + 14306 suspended (signal) sudo nsenter -t 13221 -m -u -i -n -p /bin/bash and the container's init hangs after 'All filesystems unmounted.'. Only when I do 'fg', halt resume and systemd-nspawn quits. Apparrently only happens rarely (1/5 so far). What's going on? When we go on a killing spree on shutdown we first SIGSTOP everything so that processes are terminated out of the blue sky, and don't generate confusing messages that their children died, because we also killed them. We kinda fake an atomic killing of all system process. (This is something sysvinit, did too btw...). Now, the SIGSTOP will be reported to your host's bash, since your host's bash probably stays the parent of the container bash. That's why you get the weird job control thing... (i wonder though what is actually reported as PPID for your container shell inside the container?). Now, somehow this weird parent/child relationship breaks SIGCONT, and hence your nsenter process won't work? I still wonder if we shouldn't try to be more careful when entering a namespace. i.e. inheriting half of the process settings from the host, and half from the container sounds semi-ugly... Maybe we enter the namespace with an external process, but then use that to get PID 1 to somehow start something for us, and then pass STDIN/STDOUT to that... So instead of entering plus exec()ing internal code, we'd just enter, and run external code... If you follow what I mean? Hmm, or maybe like this: enter the container, allocate a pty, instantiate getty@.service for that pty, pass pty fd back to host, exit in namespace, and process pty on the host as long as we don't get EOF. The pty handling we have in nspawn anyway, so this could be pretty straightforward to hack up. Of course, this would only work if PID1 in the container is systemd, but that should be OK. People can always use nsenter by hand if they have different init systems in the container... (BTW, we now can name containers in the system, so maybe we want to use that in nspawn anyway, to introduce a new switch that gets you a getty on an existing container, identified by its name...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. --- Makefile.am | 13 + configure.ac |5 + 2 files changed, 18 insertions(+) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..1b51967 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1063,6 +1063,7 @@ CLEANFILES += \ src/core/org.freedesktop.systemd1.policy.in # -- +if ENABLE_TESTS noinst_PROGRAMS += \ test-engine \ test-ns \ @@ -1331,6 +1332,8 @@ test_sched_prio_LDADD = \ libsystemd-core.la \ libsystemd-daemon.la +endif # ENABLE_TESTS + # -- systemd_initctl_SOURCES = \ src/initctl/initctl.c @@ -1726,6 +1729,7 @@ libsystemd_bus_la_LIBADD = \ noinst_LTLIBRARIES += \ libsystemd-bus.la +if ENABLE_TESTS noinst_tests += \ test-bus-marshal \ test-bus-signature \ @@ -1733,6 +1737,7 @@ noinst_tests += \ test-bus-server \ test-bus-match \ test-bus-kernel +endif noinst_PROGRAMS += \ busctl @@ -2070,6 +2075,7 @@ hwdb-remove-hook: -test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin # -- +if ENABLE_TESTS TESTS += \ test/udev-test.pl \ test/rules-test.sh @@ -2077,6 +2083,7 @@ TESTS += \ noinst_PROGRAMS += \ test-libudev \ test-udev +endif test_libudev_SOURCES = \ src/test/test-libudev.c @@ -2527,8 +2534,10 @@ test_id128_LDADD = \ libsystemd-shared.la \ libsystemd-id128-internal.la +if ENABLE_TESTS noinst_tests += \ test-id128 +endif pkginclude_HEADERS += \ src/systemd/sd-id128.h @@ -2835,6 +2844,7 @@ catalog-remove-hook: UNINSTALL_DATA_HOOKS += \ catalog-remove-hook +if ENABLE_TESTS noinst_PROGRAMS += \ test-journal-enum @@ -2847,6 +2857,7 @@ noinst_tests += \ test-journal-verify \ test-mmap-cache \ test-catalog +endif pkginclude_HEADERS += \ src/systemd/sd-journal.h \ @@ -3536,9 +3547,11 @@ test_inhibit_CFLAGS = \ $(AM_CFLAGS) \ $(DBUS_CFLAGS) +if ENABLE_TESTS noinst_PROGRAMS += \ test-login \ test-inhibit +endif libsystemd_login_la_SOURCES = \ src/login/sd-login.c diff --git a/configure.ac b/configure.ac index 519f1a9..fbc07c2 100644 --- a/configure.ac +++ b/configure.ac @@ -880,6 +880,11 @@ AS_IF([test x$0 != x./configure], [ AC_SUBST([INTLTOOL_UPDATE], [/bin/true]) ]) +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [build tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + AC_SUBST([dbuspolicydir], [$with_dbuspolicydir]) AC_SUBST([dbussessionservicedir], [$with_dbussessionservicedir]) AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir]) -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
Use features.h and _GNU_SOURCE to determine if _ISOC11_SOURCE is
available, and with that, aligned_alloc().
---
src/libsystemd-bus/bus-kernel.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
index 086877e..bb63a4e 100644
--- a/src/libsystemd-bus/bus-kernel.c
+++ b/src/libsystemd-bus/bus-kernel.c
@@ -19,11 +19,17 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#define _GNU_SOURCE
+#include features.h
+
#ifdef HAVE_VALGRIND_MEMCHECK_H
#include valgrind/memcheck.h
#endif
#include fcntl.h
+#ifndef _ISOC11_SOURCE
+# include malloc.h /* For memalign(), if needed. */
+#endif
#include util.h
@@ -39,6 +45,15 @@
(uint8_t *)(item) (uint8_t *)(head) + (head)-size;
\
item = KDBUS_ITEM_NEXT(item))
+static void *align(size_t alignment, size_t size)
+{
+#ifdef _ISOC11_SOURCE
+return aligned_alloc(alignment, size);
+#else
+return memalign(alignment, size);
+#endif
+}
+
static int parse_unique_name(const char *s, uint64_t *id) {
int r;
@@ -199,7 +214,7 @@ static int bus_message_setup_kmsg(sd_bus *b, sd_bus_message
*m) {
sz += ALIGN8(offsetof(struct kdbus_msg_item, str) + dl + 1);
}
-m-kdbus = aligned_alloc(8, sz);
+m-kdbus = align(8, sz);
if (!m-kdbus)
return -ENOMEM;
@@ -500,7 +515,7 @@ int bus_kernel_read_message(sd_bus *bus, sd_bus_message
**m) {
for (;;) {
void *q;
-q = aligned_alloc(8, sz);
+q = align(8, sz);
if (!q)
return -errno;
--
1.7.10.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: Remove unnecessary typedef
ExecContext isn't used in this header file, and everything seems to build just fine without this typedef. The typedef doesn't really belong here, and at least my gcc-4.4.6 gives an error on type redefined. --- src/core/namespace.h |2 -- 1 file changed, 2 deletions(-) diff --git a/src/core/namespace.h b/src/core/namespace.h index 7b886b8..ddb5794 100644 --- a/src/core/namespace.h +++ b/src/core/namespace.h @@ -23,8 +23,6 @@ #include stdbool.h -typedef struct ExecContext ExecContext; - int setup_tmpdirs(char **tmp_dir, char **var_tmp_dir); int setup_namespace(char **read_write_dirs, char **read_only_dirs, -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. Can't the tests get its own variables, and we assign these variablse conditionally to the original variables to take effect, instead of nesting even more ifdefs? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
On Wed, Apr 17, 2013 at 6:09 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: Use features.h and _GNU_SOURCE to determine if _ISOC11_SOURCE is available, and with that, aligned_alloc(). Can't you just define the missing function in missing.h to the one we use, instead of directly blowing up the code with compat stuff and ifdefs? Sure I can. Didn't know about missing.h. Will fix. Yeah, the idea of missing.h is to make stuff look like it is there. We usually just decide on one option, and cover older stuff from there. :) Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] bus: Include missing.h to get redefinition of aligned_access if necessary
--- src/libsystemd-bus/bus-kernel.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c index 086877e..c144f69 100644 --- a/src/libsystemd-bus/bus-kernel.c +++ b/src/libsystemd-bus/bus-kernel.c @@ -26,6 +26,7 @@ #include fcntl.h #include util.h +#include missing.h #include bus-internal.h #include bus-message.h -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On 04/17/2013 10:27 AM, Lennart Poettering wrote: On Wed, 17.04.13 09:46, Mark Hounschell (ma...@compro.net) wrote: I have been using systemd to boot into a very basic target. That target basically executes a script. In that script we execute an su -m -c command user. The last version of systemd I have where this worked is version 37. I'm using opensuse dist and that was in version 12.2 from about a year ago. I've upgraded to opensuse-12.3 and that systemd version is 195. The su -m -c command user now appears to be ignored. I there a particular service I now need to include in my target that will enable the su command to work? I can post my target and service files if required. Have you checked the logs for anything interesting? That's a good way to start figuring out what's going on... The only thing I see in /var/log/messages is: 2013-04-17T11:36:51.667308-04:00 utils-linux su: (to lcrs) root on /dev/ttyS0 2013-04-17T11:36:51.668896-04:00 utils-linux systemd-logind[1731]: New session c4 of user lcrs. 2013-04-17T11:36:51.705945-04:00 utils-linux systemd-logind[1731]: Removed session c4. And as I just told Andry, when I include my service in the normal runlevel5 target all is fine. I only get the first line shown above and it works just fine. So I am just assuming there is some service missing from my target that I NOW need?? Thanks Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
On 17/04/13 16:57, Lennart Poettering wrote: Hmm, or maybe like this: enter the container, allocate a pty, instantiate getty@.service for that pty, pass pty fd back to host, exit in namespace, and process pty on the host as long as we don't get EOF. This is probably a good idea for interactive use (a lighter-weight version of ssh'ing into the container): Unix semantics guarantee some rather surprising interactions between signals, process groups, process parents and terminals, without which shell job control wouldn't work. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Remove unnecessary typedef
On Wed, Apr 17, 2013 at 6:08 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: ExecContext isn't used in this header file, and everything seems to build just fine without this typedef. The typedef doesn't really belong here, and at least my gcc-4.4.6 gives an error on type redefined. Weird, this type of forward-declaration is a common pattern. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
On Mon, 15.04.13 14:31, Chir0n (io.chi...@gmail.com) wrote: Please do not send HTML mails to this mailing list, thank you. I'm trying to execute the Example 1 of the following tutorial and I can't log with any user. I get an authentication error. This is probably fixed with this recent commit: http://cgit.freedesktop.org/systemd/systemd/commit/src?id=9a3ef988b8442360500e7df4db3ff27d2f13de10 Will be in the next release. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Remove unnecessary typedef
Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 6:08 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: ExecContext isn't used in this header file, and everything seems to build just fine without this typedef. The typedef doesn't really belong here, and at least my gcc-4.4.6 gives an error on type redefined. Weird, this type of forward-declaration is a common pattern. A closer look reveals that gcc warns in gcc-4.4, but not in gcc-4.7. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
On Wed, 17.04.13 17:49, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: Use features.h and _GNU_SOURCE to determine if _ISOC11_SOURCE is available, and with that, aligned_alloc(). Hmm, we probably should just use memalign() everywhere. It's available on all GNU systems and Solaris, which is more than enough for us. Also, it doesn't put any restriction on whether the size passed needs to be aligned, unlike aligned_alloc(). In this regard aligned_alloc() seems to be less useful and less widely adopted, so let's just stop using it. +#define _GNU_SOURCE We define that implicitly for all our sources anyway, btw. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
On Wed, 17.04.13 18:12, Kay Sievers (k...@vrfy.org) wrote: On Wed, Apr 17, 2013 at 6:09 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: Use features.h and _GNU_SOURCE to determine if _ISOC11_SOURCE is available, and with that, aligned_alloc(). Can't you just define the missing function in missing.h to the one we use, instead of directly blowing up the code with compat stuff and ifdefs? Sure I can. Didn't know about missing.h. Will fix. Yeah, the idea of missing.h is to make stuff look like it is there. We usually just decide on one option, and cover older stuff from there. :) Well, our current usage of aligned_alloc() is not even calling it correctly... We really should sotp using that. Let's use memalign() everywhere. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. Can't the tests get its own variables, and we assign these variablse conditionally to the original variables to take effect, instead of nesting even more ifdefs? I notice that some tests are added to noinst_PROGRAMS, while others are added to noinst_tests. I'm not sure what the difference between the two are. An alternative (and simpler) patch would be to add all tests to noinst_tests (unconditionally), and then add noinst_tests to noinst_PROGRAMS only if ENABLE_TESTS is true. I can send an alternative patch. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Remove unnecessary typedef
On 17/04/13 17:25, Kay Sievers wrote: On Wed, Apr 17, 2013 at 6:08 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: ExecContext isn't used in this header file, and everything seems to build just fine without this typedef. The typedef doesn't really belong here, and at least my gcc-4.4.6 gives an error on type redefined. Weird, this type of forward-declaration is a common pattern. We had this bug in telepathy-glib too: typedef struct Xyz Xyz;, seen once per translation unit, is fine. typedef struct Xyz Xyz; typedef struct Xyz Xyz; was an error in C89 and C99, but is allowed in C11. The portable thing to do is to have the typedef in exactly one header file (which doesn't necessarily have to be the same one that declares the contents of a struct Xyz), and have everything else that mentions Xyz include that header. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
On Wed, 17.04.13 18:38, Lennart Poettering (lenn...@poettering.net) wrote: Yeah, the idea of missing.h is to make stuff look like it is there. We usually just decide on one option, and cover older stuff from there. :) Well, our current usage of aligned_alloc() is not even calling it correctly... We really should sotp using that. Let's use memalign() everywhere. I commited a fix for this now. aligned_alloc() is gone now. Such a stupid interface... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
В Wed, 17 Apr 2013 06:58:20 +0200 (CEST) Jan Engelhardt jeng...@inai.de пишет: Hi, something I observed with systemd-195 is that the LidClose event is delivered when switching from X to console while the lid is closed. This is unexpected, and what I expected is instead that nothing occurs. Approximate steps to reproduce, IIRC: 1. Plug in external monitor 2. Boot machine. By way of KMS, output will be cloned to the big screen. 3. When the X desktop is finally running, close laptop lid. (Because the picture is also cloned in this case) In XFCE's power settings, I have set that LidClose does not do anything - for obvious reason. let any amount of time pass 4. Switch to tty1 5. systemd does an S2RAM. So in other words, if you worked for an hour in X and then switch, you get a suspend event out of nowhere without warning notice. # journalctl -n ... Apr 17 06:41:30 nakamura.inai.de systemd-logind[502]: Suspending... Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Sleep. Apr 17 06:41:30 nakamura.inai.de systemd[1]: Reached target Sleep. Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Suspend... Apr 17 06:41:30 nakamura.inai.de systemd-sleep[5315]: Suspending system... (Now I also need to find the knob to turn off suspend in systemd; this was not here before in systemd-44.) /etc/systemd/logind.conf: HandleSuspendKey=ignore ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
Henrik Grindal Bakken h...@ifi.uio.no writes: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. This is the alternative approach. I'm not sure what the distinction between noinst_PROGRAMS and noinst_tests are (or were), so this might be completely Wrong... Perhaps the commit message should be updated to reflect this change. I can do that if you wish. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. --- Makefile.am | 21 +++-- configure.ac |5 + 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..82bd4f6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -125,8 +125,13 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= +if ENABLE_TESTS noinst_PROGRAMS = $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = AM_CPPFLAGS = \ @@ -1063,7 +1068,7 @@ CLEANFILES += \ src/core/org.freedesktop.systemd1.policy.in # -- -noinst_PROGRAMS += \ +noinst_tests += \ test-engine \ test-ns \ test-loopback \ @@ -1072,9 +1077,7 @@ noinst_PROGRAMS += \ test-cgroup \ test-install \ test-watchdog \ - test-log - -noinst_tests += \ + test-log \ test-job-type \ test-env-replace \ test-strbuf \ @@ -1145,7 +1148,7 @@ test_hostname_LDADD = \ libsystemd-core.la if ENABLE_EFI -noinst_PROGRAMS += \ +noinst_tests += \ test-efivars test_efivars_SOURCES = \ @@ -2074,7 +2077,7 @@ TESTS += \ test/udev-test.pl \ test/rules-test.sh -noinst_PROGRAMS += \ +noinst_tests += \ test-libudev \ test-udev @@ -2835,10 +2838,8 @@ catalog-remove-hook: UNINSTALL_DATA_HOOKS += \ catalog-remove-hook -noinst_PROGRAMS += \ - test-journal-enum - noinst_tests += \ + test-journal-enum test-journal \ test-journal-send \ test-journal-syslog \ @@ -3536,7 +3537,7 @@ test_inhibit_CFLAGS = \ $(AM_CFLAGS) \ $(DBUS_CFLAGS) -noinst_PROGRAMS += \ +noinst_tests += \ test-login \ test-inhibit diff --git a/configure.ac b/configure.ac index 519f1a9..fbc07c2 100644 --- a/configure.ac +++ b/configure.ac @@ -880,6 +880,11 @@ AS_IF([test x$0 != x./configure], [ AC_SUBST([INTLTOOL_UPDATE], [/bin/true]) ]) +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [build tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + AC_SUBST([dbuspolicydir], [$with_dbuspolicydir]) AC_SUBST([dbussessionservicedir], [$with_dbussessionservicedir]) AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir]) -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
В Wed, 17 Apr 2013 17:31:14 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 17.04.13 17:20, Jan Engelhardt (jeng...@inai.de) wrote: On Wednesday 2013-04-17 16:42, Lennart Poettering wrote: On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Well, the current logic is that we suspend when the lid is closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME.[...] So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. That reasoning is perfectly fine; the problem is that logind acts upon a physical lid state change from the distant past. Well, it is level-triggered, not edge-triggered. If the lid is closed and a lock released we immediately act and suspend. That's the only reliable and safe way to do that. One problem is, it breaks existing behavior and quite badly. How users are supposed to start inhibitors on ttyX the very moment they switch to it? It probably needs to be more compatible with exiting behavior by default. I remember something very similar recently ... ah, here it is http://lists.freedesktop.org/archives/systemd-devel/2013-March/009988.html Or are you saying that you had an X session running which took the lock, then closed and reopened the lid, and when you then switched to a VT the machine was suspended? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
On Wed, 17.04.13 17:36, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: we could add a generator to systemd which looks for systemd.run= or so on the kernel cmdline and simply generates throw-away unit files from that, that runs the specified command(s) and triggers a shutdown afterwards... Would that work for you? i.e. you'd then call: systemd-nspawn -bD /srv/foobar \ systemd.run='/usr/bin/timedatectl set-timezone Europe/Paris' \ systemd.run='/usr/bin/timedatectl set-hostname BeagleBoneBlack' and so on... I think that would be reasonably pretty? An alternative idea: let's a tool which waits until startup is finished. (Unless I'm mistaken, there's dbus support with StartupFinished, but not a ready tool which waits.) well, but watching dus from the outside is kinda hard, since we don't know when the socket is up. THis would become easier with kdbus, (where the bus would be created very early on in PID1 and would be visible outside), but there still would be a small window, where dbus wouldn't be accessible... Then one would inject into the container, wait for it to return, and then inject other commands. The advantage would be in better error handling and scriptability. But you'd have a process in the container that would be kinda foreign, wouldn't even be in the container's cgroup, would inherit all kind of weird stuff from the outside... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
On Wed, 17.04.13 18:38, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. Can't the tests get its own variables, and we assign these variablse conditionally to the original variables to take effect, instead of nesting even more ifdefs? I notice that some tests are added to noinst_PROGRAMS, while others are added to noinst_tests. I'm not sure what the difference between the two are. An alternative (and simpler) patch would be to add all tests to noinst_tests (unconditionally), and then add noinst_tests to noinst_PROGRAMS only if ENABLE_TESTS is true. noinst_PROGRAMS is for tests that cannot really be run automatically during make check, since they need some kind of interaction, priviliges and so on. These tests are much less useful, but for some low level stuff we need this. noinst_tests otoh is for tests that run during make check. They are your classic unit tests... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lid close event delivered delayed
On Wed, 17.04.13 21:01, Andrey Borzenkov (arvidj...@gmail.com) wrote: В Wed, 17 Apr 2013 17:31:14 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 17.04.13 17:20, Jan Engelhardt (jeng...@inai.de) wrote: On Wednesday 2013-04-17 16:42, Lennart Poettering wrote: On Wed, 17.04.13 06:58, Jan Engelhardt (jeng...@inai.de) wrote: Well, the current logic is that we suspend when the lid is closed,[...] Lid switch inhibitor locks are currently per-VT, i.e. a lock taken by GNOME is considered irrelevant if you switch away from GNOME.[...] So in order to make sure the lid switch suspend works fine even when you happen to switch away from GNOME logind will handle it then. That reasoning is perfectly fine; the problem is that logind acts upon a physical lid state change from the distant past. Well, it is level-triggered, not edge-triggered. If the lid is closed and a lock released we immediately act and suspend. That's the only reliable and safe way to do that. One problem is, it breaks existing behavior and quite badly. How users are supposed to start inhibitors on ttyX the very moment they switch to it? Well, I am not saying this shouldnt be fixed, I am just pointing out why it is how it is. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
Lennart Poettering lenn...@poettering.net writes: noinst_PROGRAMS is for tests that cannot really be run automatically during make check, since they need some kind of interaction, priviliges and so on. These tests are much less useful, but for some low level stuff we need this. noinst_tests otoh is for tests that run during make check. They are your classic unit tests... So the first attempt at --disable-tests, then, if any... -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Use memalign() if aligned_alloc() isn't available
Kay Sievers k...@vrfy.org writes: On Wed, Apr 17, 2013 at 5:49 PM, Henrik Grindal Bakken h...@ifi.uio.no wrote: Use features.h and _GNU_SOURCE to determine if _ISOC11_SOURCE is available, and with that, aligned_alloc(). Can't you just define the missing function in missing.h to the one we use, instead of directly blowing up the code with compat stuff and ifdefs? Sure I can. Didn't know about missing.h. Will fix. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On Wed, 17.04.13 12:22, Mark Hounschell (ma...@compro.net) wrote: On 04/17/2013 10:27 AM, Lennart Poettering wrote: On Wed, 17.04.13 09:46, Mark Hounschell (ma...@compro.net) wrote: I have been using systemd to boot into a very basic target. That target basically executes a script. In that script we execute an su -m -c command user. The last version of systemd I have where this worked is version 37. I'm using opensuse dist and that was in version 12.2 from about a year ago. I've upgraded to opensuse-12.3 and that systemd version is 195. The su -m -c command user now appears to be ignored. I there a particular service I now need to include in my target that will enable the su command to work? I can post my target and service files if required. Have you checked the logs for anything interesting? That's a good way to start figuring out what's going on... The only thing I see in /var/log/messages is: 2013-04-17T11:36:51.667308-04:00 utils-linux su: (to lcrs) root on /dev/ttyS0 Bu that's run on ttyS0? Is that really script? How do spawn that script? 2013-04-17T11:36:51.668896-04:00 utils-linux systemd-logind[1731]: New session c4 of user lcrs. 2013-04-17T11:36:51.705945-04:00 utils-linux systemd-logind[1731]: Removed session c4. if you invoke logger test via su here, do you see it logging something? Maybe your implementation of su is borked? Some older implementations misused PAM and immediately closed the PAM session after creating it... Which implementation do you use? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
On Wed, 17.04.13 18:48, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: @@ -125,8 +125,13 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= +if ENABLE_TESTS noinst_PROGRAMS = $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = There must be two different vars for these, you cannot collapse them (see other mail for explanation). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
Op 17 apr. 2013, om 17:20 heeft Lennart Poettering lenn...@poettering.net het
volgende geschreven:
On Wed, 17.04.13 17:09, Lennart Poettering (lenn...@poettering.net) wrote:
On Tue, 16.04.13 09:11, Koen Kooi (k...@dominion.thruhere.net) wrote:
Hi,
To help with flashing the onboard eMMC of a 10 boards I'm using
systemd-nspawn to run package postinstall scripts that generate UUIDs and
some other things and it's working great for that! Every board now has a
unique value in /etc/machine-id instead it being empty and systemd
randomizing it on startup.
What doesn't work however is something like this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone
Europe/Paris
or this:
systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname
BeagleBoneBlack
I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the
name into /etc/hostname, but I'd like to use the *ctl commands because they
work and have error handling built-in.
it looks like I would need -b to get the *ctl commands to work, but -b
doesn't support running single commands and exiting.
timedatectl is just a frontend to timedated. So, without running
timedated inside of the container this is not going to be easy to do.
Ah, I missed that you'd actually be OK with booting up the whole thing
for this command... You'd just need a nice way to run something after
boot-up is complete, and that immeidately shuts down the container
afterwards, right?
Exactly!
Hmm, here's an idea:
we could add a generator to systemd which looks for systemd.run= or so
on the kernel cmdline and simply generates throw-away unit files from
that, that runs the specified command(s) and triggers a shutdown
afterwards... Would that work for you?
i.e. you'd then call:
systemd-nspawn -bD /srv/foobar \
systemd.run='/usr/bin/timedatectl set-timezone Europe/Paris' \
systemd.run='/usr/bin/timedatectl set-hostname BeagleBoneBlack'
and so on...
I think that would be reasonably pretty?
And it totally works for my usecase as well!
regards,
Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On 04/17/2013 01:12 PM, Lennart Poettering wrote: On Wed, 17.04.13 12:22, Mark Hounschell (ma...@compro.net) wrote: On 04/17/2013 10:27 AM, Lennart Poettering wrote: On Wed, 17.04.13 09:46, Mark Hounschell (ma...@compro.net) wrote: I have been using systemd to boot into a very basic target. That target basically executes a script. In that script we execute an su -m -c command user. The last version of systemd I have where this worked is version 37. I'm using opensuse dist and that was in version 12.2 from about a year ago. I've upgraded to opensuse-12.3 and that systemd version is 195. The su -m -c command user now appears to be ignored. I there a particular service I now need to include in my target that will enable the su command to work? I can post my target and service files if required. Have you checked the logs for anything interesting? That's a good way to start figuring out what's going on... The only thing I see in /var/log/messages is: 2013-04-17T11:36:51.667308-04:00 utils-linux su: (to lcrs) root on /dev/ttyS0 Bu that's run on ttyS0? Is that really script? How do spawn that script? From the service file: ExecStart=/sbin/qlogin /dev/ttyS0 root --homedir=/lcrs --noutmp --command=/bin/bash --login -c /lcrs/sh.lcrs Then in the sh.lcrs script ANY su command is borked. 2013-04-17T11:36:51.668896-04:00 utils-linux systemd-logind[1731]: New session c4 of user lcrs. 2013-04-17T11:36:51.705945-04:00 utils-linux systemd-logind[1731]: Removed session c4. if you invoke logger test via su here, do you see it logging something? Maybe your implementation of su is borked? Some older implementations misused PAM and immediately closed the PAM session after creating it... Which implementation do you use? # rpm -qf /usr/bin/su coreutils-8.17-6.2.1.i586 Thanks Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
Lennart Poettering lenn...@poettering.net writes: On Wed, 17.04.13 18:48, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: @@ -125,8 +125,13 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= +if ENABLE_TESTS noinst_PROGRAMS = $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = There must be two different vars for these, you cannot collapse them (see other mail for explanation). Yeah, so then my first patch is back to the number one candidate. Or I can make a new one, similar to this, with two variable. Perhaps that's prettier? -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] typo? path-util: unify code for detecting OS trees
while reading random patches in cgit I saw
(in commit 6606089752df90f3eeb4924af109046f1c73554c)
...
diff --git a/src/shared/util.h b/src/shared/util.h
index 3aac165..cfb5493 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -684,3 +684,15 @@ int unlink_noerrno(const char *path);
_new_ = alloca(_len_); \
(void *) memset(_new_, 0, _len_); \
})
+
+#define strappenda(a, b) \
+ ({ \
+ const char *_a_ = (a), *_b_ = (b); \
+ char *_c_; \
+ size_t _x_, _y_; \
+ _x_ = strlen(_a_); \
+ _y_ = strlen(_b_); \
+ _c_ = alloca(_x_ + _y_ + 1); \
+ strcpy(stpcpy(_c_, _a_), _b_); \
shouldn't this be more like:
strcat(strcpy(_c_, _a_), _b_);
Nah, stpcpy() is the best thing since sliced bread for concatenating
strings. Together with mempcpy() and mempset() it's really useful, and a
ton more efficient than strcat().
oh, did no know about that one, it indeed seems to be the best thing
since sliced bread then.
My apologies for the noise.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On Wed, 17.04.13 13:21, Mark Hounschell (ma...@compro.net) wrote: The only thing I see in /var/log/messages is: 2013-04-17T11:36:51.667308-04:00 utils-linux su: (to lcrs) root on /dev/ttyS0 Bu that's run on ttyS0? Is that really script? How do spawn that script? From the service file: ExecStart=/sbin/qlogin /dev/ttyS0 root --homedir=/lcrs --noutmp --command=/bin/bash --login -c /lcrs/sh.lcrs Then in the sh.lcrs script ANY su command is borked. 2013-04-17T11:36:51.668896-04:00 utils-linux systemd-logind[1731]: New session c4 of user lcrs. 2013-04-17T11:36:51.705945-04:00 utils-linux systemd-logind[1731]: Removed session c4. if you invoke logger test via su here, do you see it logging something? Maybe your implementation of su is borked? Some older implementations misused PAM and immediately closed the PAM session after creating it... Which implementation do you use? # rpm -qf /usr/bin/su coreutils-8.17-6.2.1.i586 That looks OK. Can you try the logger thing I suggested? That should tell us if the transition works at all... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
On Wed, 17.04.13 19:25, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: Lennart Poettering lenn...@poettering.net writes: On Wed, 17.04.13 18:48, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: @@ -125,8 +125,13 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= +if ENABLE_TESTS noinst_PROGRAMS = $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = There must be two different vars for these, you cannot collapse them (see other mail for explanation). Yeah, so then my first patch is back to the number one candidate. Or I can make a new one, similar to this, with two variable. Perhaps that's prettier? Hmm, why do you bother with the tests only appearing on noinst_PROGRAMS= anyway? Those are never run automatically, so they shouldn't matter to you? To me it sounds that all that should be done assing the empty string to TESTS when tests are supposed to be turned off. Of course, there are currently two places where TESTS= is directly modified, but that should be easily fixed.. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] buildsys: Add --disable-tests to avoid building tests
This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. The patch adds a new Makefile variable -- noinst_test_programs -- and uses that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true, the former is added to the latter. --- Makefile.am | 18 -- configure.ac |5 + 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..89b95ba 100644 --- a/Makefile.am +++ b/Makefile.am @@ -125,8 +125,14 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= -noinst_PROGRAMS = $(noinst_tests) +noinst_test_programs = +if ENABLE_TESTS +noinst_PROGRAMS = $(noinst_test_programs) $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = AM_CPPFLAGS = \ @@ -1063,7 +1069,7 @@ CLEANFILES += \ src/core/org.freedesktop.systemd1.policy.in # -- -noinst_PROGRAMS += \ +noinst_test_programs += \ test-engine \ test-ns \ test-loopback \ @@ -1145,7 +1151,7 @@ test_hostname_LDADD = \ libsystemd-core.la if ENABLE_EFI -noinst_PROGRAMS += \ +noinst_test_programs += \ test-efivars test_efivars_SOURCES = \ @@ -2074,7 +2080,7 @@ TESTS += \ test/udev-test.pl \ test/rules-test.sh -noinst_PROGRAMS += \ +noinst_test_programs += \ test-libudev \ test-udev @@ -2835,7 +2841,7 @@ catalog-remove-hook: UNINSTALL_DATA_HOOKS += \ catalog-remove-hook -noinst_PROGRAMS += \ +noinst_test_programs += \ test-journal-enum noinst_tests += \ @@ -3536,7 +3542,7 @@ test_inhibit_CFLAGS = \ $(AM_CFLAGS) \ $(DBUS_CFLAGS) -noinst_PROGRAMS += \ +noinst_test_programs += \ test-login \ test-inhibit diff --git a/configure.ac b/configure.ac index 519f1a9..fbc07c2 100644 --- a/configure.ac +++ b/configure.ac @@ -880,6 +880,11 @@ AS_IF([test x$0 != x./configure], [ AC_SUBST([INTLTOOL_UPDATE], [/bin/true]) ]) +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [build tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + AC_SUBST([dbuspolicydir], [$with_dbuspolicydir]) AC_SUBST([dbussessionservicedir], [$with_dbussessionservicedir]) AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir]) -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: Add --disable-tests to avoid building tests
Lennart Poettering lenn...@poettering.net writes: Hmm, why do you bother with the tests only appearing on noinst_PROGRAMS= anyway? Those are never run automatically, so they shouldn't matter to you? Well, at the moment, one of them (test-bus-marshal) fails to link due to (seemingly) a problem with glib linking. To me it sounds that all that should be done assing the empty string to TESTS when tests are supposed to be turned off. Of course, there are currently two places where TESTS= is directly modified, but that should be easily fixed.. Perhaps that's good enough. I'll try. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] RFC: stack_size_guess() and LINE_MAX limitation for MESSAGE
On Mon, 15.04.13 16:12, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Introduce stack_size_guess() and alloca_maybe_safe() and get rid of the LINE_MAX limitation for MESSAGE in sd_journal_printv*() tbh I don't really see the benefit of this. This is about logging, you really want to avoid too much magic in there with differing results depending how deep in you are. We should stay predictable here, and that also means that we fail predictably and that we generate the very same messages regardless in which context you call us... I mean, the original comment in that source file suggested to do a VLA loop there, but that'd only be an optimization, we'd still have to enforce a fixed limit on the resulting string, to avoid DoS attacks... Now, turning this into something entirely dynamic sounds dangerous too me at little benefit... Also, the those functions are slow enough, not sure how I feel about adding yet another syscall into each invocation... What's the precise issue you are trying to fix here? Are there reports of the limit actually being a real-life issue? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] buildsys: Add --disable-tests to avoid building tests
On Wed, Apr 17, 2013 at 07:36:47PM +0200, Henrik Grindal Bakken wrote: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. The patch adds a new Makefile variable -- noinst_test_programs -- and uses that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true, the former is added to the latter. --- Makefile.am | 18 -- configure.ac |5 + 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..89b95ba 100644 --- a/Makefile.am +++ b/Makefile.am @@ -125,8 +125,14 @@ dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = noinst_tests= -noinst_PROGRAMS = $(noinst_tests) +noinst_test_programs = +if ENABLE_TESTS +noinst_PROGRAMS = $(noinst_test_programs) $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = Hm, maybe rename noinst_test_programs to 'manual_tests', and noinst_tests to just 'tests'. noinst_ is just for automake. This way it'll be clearer that 'manual_tests' are tests that are not run automatically. +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [build tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + Are you sure that this is enabled by default? The docstring seems to be opposite of the actual meaning. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] RFC for avoid dynamic allocation in?journald
On Mon, 08.04.13 19:53, Holger Hans Peter Freyther (hol...@freyther.de) wrote: On Mon, Apr 08, 2013 at 07:06:44PM +0200, Lennart Poettering wrote: Is it really needed to determine the cgroup of /proc/1 on every message? Couldn't journald keep the variables for its identity around? a) use gcc's __thread support, i.e. have one static cache var per thread. Since all stuff in systemd's repo is essentially single threaded this should give you the desired effect and should be a pretty simple way to have caches without having to think about concurrency. Of course, this only really works for small fixed-size data that needs no destructors (i.e. no free()). b) Only provide the caching in the main thread, and be un-cached expensive in all others. This is slightly less nice, but effectively gives you the same properties for systemd's own code. We have a call in util.c to detect if we are running in the main thread: is_main_thread(). I understand the constraints. My hardware (like most older ARM cores) doesn't have a dedicated HW register for TLS. So I would like to avoid any usage of threading. What is the argument against caching it inside the application layer? E.g. is it fair to assume that journald will be launched once systemd has created the cgroup? Well, certainly, we can always cache things in the Server structure. In fact we should certainly cache the machine ID and boot ID string there, instea dof regenerating it all the time. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add ARCH parameter to /etc/os-release
On Mon, 08.04.13 22:09, Askar Safin (safinas...@mail.ru) wrote: I'm not sure what problem the proposal is trying to solve. Maybe it'd be clearer if that was provided. I want to know what is the arches of the systems on my computer. I. e. I want to do the following: for DISK in /dev/sd*; do mount $DISK /mnt source /mnt/etc/os-release echo Arch of $DISK is $ARCH done And I want to use this $ARCH to do setarch, i. e.: mount /dev/some-dev /mnt source /mnt/etc/os-release setarch $ARCH chroot /mnt So, this /mnt system will see uname -m output which is meaningful for the system. My suggestion would be to write a little tool that does the equivalent to this: readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq This will list you the architectures for which you have dynamic loaders installed. Since the dynamic loaders are hardcoded in all dynamic ELF binaries this list will tell you binaries of which archs you can execute on your system. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] buildsys: Add --disable-tests to avoid building tests
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: On Wed, Apr 17, 2013 at 07:36:47PM +0200, Henrik Grindal Bakken wrote: This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. The patch adds a new Makefile variable -- noinst_test_programs -- and uses that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true, the former is added to the latter. +noinst_PROGRAMS = $(noinst_test_programs) $(noinst_tests) TESTS = $(noinst_tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = Hm, maybe rename noinst_test_programs to 'manual_tests', and noinst_tests to just 'tests'. noinst_ is just for automake. This way it'll be clearer that 'manual_tests' are tests that are not run automatically. Good point. I'll do that. +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [build tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + Are you sure that this is enabled by default? The docstring seems to be opposite of the actual meaning. Yeah, it's enabled (or, at least, it builds the tests for me without --disable-tests), but as you point out, the help text is all wrong. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On Wed, 10.04.13 19:03, Koen Kooi (k...@dominion.thruhere.net) wrote: Hi, I have a bit of a heisenbug where dropbear.socket will just die and needs a systemctl restart dropbear.socket. I can't tell why it's dying, just that it does within 3 days of uptime. After restarting it it seems to be rock solid again for at least some weeks. The real way to fix this is to find out why it dies, but till someone figures that out I'm looking to a way to automatically restart the socket when it fails, kinda like Restart=Always for services. Is such a thing possible? This is with 195 and 196, haven't tried 201 yet. So, two things: When a service continuously dies we'll put the listening socket into fail state eventually. But you can see these ones easily in systemctl status, since they have a specific result service-failed-permanent. (results are shown next to the Active: field if a unit failed). And if the somebody invokes shutdown() on the listening socket (not the connection socket), but that's a really weird thing to do. But people do weird things, and this has occured before. Otherwise I have no idea what could have happened. Any chance you can reproduce this with strace attached to PID 1 or so? Is dropbear forked off one instance per connection, or one instance for all? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sat, 13.04.13 13:27, Reindl Harald (h.rei...@thelounge.net) wrote: Hi as far as i understand systemd-readahead is catching what is loaded directly due boot and 10 seconds after, well that's fine I changed this to 30 now, btw, since 10s turned out to be too short on many systems. but is there a possibility to feed it with additional applications? example of the real life here: * the machine get powered on in the morning * due this sitting in the kitchen with a coffee * after that login in KDE, plasma and kopete are started * finally Thunderbird and Firefox are started * mostly Eclipse is the next * the machine has 16 GB RAM it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login As mentioned you can change the time readahead keeps running. In the long run I think the right approach for the desktops is to simply re-login after a reboot everybody who was logged in before it, and then activate the screen lock by default for them. The other thing I'd like to make happen is that we can collect username/password when we prompt for the HDD key, and use that first for decrypting the harddisk and then for authenticating the user. THis would require us to keep HDD passphrase and user passphrase in sync, but that should be totally doable and is probably deseriable anyway... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On 04/17/2013 01:32 PM, Lennart Poettering wrote: On Wed, 17.04.13 13:21, Mark Hounschell (ma...@compro.net) wrote: The only thing I see in /var/log/messages is: 2013-04-17T11:36:51.667308-04:00 utils-linux su: (to lcrs) root on /dev/ttyS0 Bu that's run on ttyS0? Is that really script? How do spawn that script? From the service file: ExecStart=/sbin/qlogin /dev/ttyS0 root --homedir=/lcrs --noutmp --command=/bin/bash --login -c /lcrs/sh.lcrs Then in the sh.lcrs script ANY su command is borked. 2013-04-17T11:36:51.668896-04:00 utils-linux systemd-logind[1731]: New session c4 of user lcrs. 2013-04-17T11:36:51.705945-04:00 utils-linux systemd-logind[1731]: Removed session c4. if you invoke logger test via su here, do you see it logging something? Maybe your implementation of su is borked? Some older implementations misused PAM and immediately closed the PAM session after creating it... Which implementation do you use? # rpm -qf /usr/bin/su coreutils-8.17-6.2.1.i586 That looks OK. Can you try the logger thing I suggested? That should tell us if the transition works at all... Sorry, I had a dentist Apt. Uh, I put this as the first command in the /lcrs/sh.lcrs script: /bin/su -m -c logger test lcrs This comes out in the log: 2013-04-17T15:41:29.754272-04:00 utils-linux systemd-logind[1722]: New session c1 of user lcrs. 2013-04-17T15:41:29.829129-04:00 utils-linux logger: test 2013-04-17T15:41:29.831565-04:00 utils-linux systemd-logind[1722]: Removed session c1. A couple of strange things now. The rest of the script works fine now??? I removed the logger test and rebooted. The script is still working Is there something being cached somewhere? I swear anything I used su for was borked until I added that extra line??? Thanks Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On Wed, 17.04.13 16:08, Mark Hounschell (ma...@compro.net) wrote: That looks OK. Can you try the logger thing I suggested? That should tell us if the transition works at all... Sorry, I had a dentist Apt. Uh, I put this as the first command in the /lcrs/sh.lcrs script: /bin/su -m -c logger test lcrs This comes out in the log: 2013-04-17T15:41:29.754272-04:00 utils-linux systemd-logind[1722]: New session c1 of user lcrs. 2013-04-17T15:41:29.829129-04:00 utils-linux logger: test 2013-04-17T15:41:29.831565-04:00 utils-linux systemd-logind[1722]: Removed session c1. A couple of strange things now. The rest of the script works fine now??? I removed the logger test and rebooted. The script is still working Is there something being cached somewhere? I swear anything I used su for was borked until I added that extra line??? Hmm, no clue. If the logger thing worked, then maybe the next thing would be to patch the script you start via su and add a logger line to the beginning and to the end of it it, and check if that still is generated. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On Wed, 17.04.13 22:16, Lennart Poettering (lenn...@poettering.net) wrote: On Wed, 17.04.13 16:08, Mark Hounschell (ma...@compro.net) wrote: That looks OK. Can you try the logger thing I suggested? That should tell us if the transition works at all... Sorry, I had a dentist Apt. Uh, I put this as the first command in the /lcrs/sh.lcrs script: /bin/su -m -c logger test lcrs This comes out in the log: 2013-04-17T15:41:29.754272-04:00 utils-linux systemd-logind[1722]: New session c1 of user lcrs. 2013-04-17T15:41:29.829129-04:00 utils-linux logger: test 2013-04-17T15:41:29.831565-04:00 utils-linux systemd-logind[1722]: Removed session c1. A couple of strange things now. The rest of the script works fine now??? I removed the logger test and rebooted. The script is still working Is there something being cached somewhere? I swear anything I used su for was borked until I added that extra line??? Hmm, no clue. If the logger thing worked, then maybe the next thing would be to patch the script you start via su and add a logger line to the beginning and to the end of it it, and check if that still is generated. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: ask for password, if key file cannot be accessed
On Thu, 11.04.13 13:08, har...@redhat.com (har...@redhat.com) wrote:
From: Harald Hoyer har...@redhat.com
If the key file cannot be accessed, we can at least ask for the
password.
I like the general idea, but not the patch.
This code is racy. We shouldn't even start with things like this. We
should try to open the file, and if that fails fallback to a prompt, but
not in two steps wher we check first, and open then. The race might not
result in any security issues in the general case, but it's still
dirty. And we try to avoid dirty in systemd.
+/* We can't access the key_file, so ask for the
password */
+if (access(key_file, R_OK)) {
+log_error(Can't access key file '%s': %m,
key_file);
+key_file = NULL;
+}
+
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: timer unit generation
--- TODO |1 + 1 file changed, 1 insertion(+) diff --git a/TODO b/TODO index 48e5d2e..eb482d0 100644 --- a/TODO +++ b/TODO @@ -320,6 +320,7 @@ Features: o CLOCK_REALTIME makes jumps (TFD_TIMER_CANCEL_ON_SET) o DST changes - Support 2012-02~4 as syntax for specifying the fourth to last day of the month. + - unit generator for compatibility with crontab and cron.d * update the kernel's TZ (sys_tz) when DST changes -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: add various journal enhancements
--- TODO |7 +++ 1 file changed, 7 insertions(+) diff --git a/TODO b/TODO index 88be72d..48e5d2e 100644 --- a/TODO +++ b/TODO @@ -272,6 +272,13 @@ Features: - journal: store euid in journal if it differs from uid - journal: sanely deal with entries which are larger than the individual file size, but where the components would fit - journalctl: make journalctl smarter, and actually check groups that have access to /var/log/journal before printing message about recomming group membership for journal access + - Replace utmp, wtmp, btmp, and lastlog completely with journal + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly +- Provide decoded text logs in /var/log + - Port upower to use the journal for historical power information used in future calculations + - Support optional database-style indexes for frequent or performance-critical queries * document: - document unit_name_mangle() -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: passwd.d, group.d
--- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. + Regularly: * look for close() vs. close_nointr() vs. close_nointr_nofail() -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. We will likely never cover user cron, and would just leave all that ancient stuff to the real cron implementation. As always, there is no final decision, but this is how it looks like today. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Replace utmp, wtmp, btmp, and lastlog completely with journal We should definitely add the data needed to constuct this information, if they are not already there. The tools could just use the journal directly, but there is the glibc api. + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly Coredump are really not consumed by any legacy thing that would need a file system. What do you have in mind here. Specialized apps that need that should just use the native API, not expect a file system, I think. +- Provide decoded text logs in /var/log I really don't think these plain text streams make much sense today. If people want them, they should install syslog. Or some other project can do that, I'm confident we do not want that code in systemd. + - Port upower to use the journal for historical power information used in future calculations Yeah, that would be useful. + - Support optional database-style indexes for frequent or performance-critical queries Well, it is not a database, it's a pretty specialized format based on bisection lists. What specific thing do you have in mind? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. Not really, we cannot or don't want to cover all of cron, so cron stays around anyway for the grey beards, or existing things out there. We decided to convert the common stuff right away, just like the init scripts are gone today, and not bother with too much glue here. At the moment, I would not expect such a patch to get merged, but hey we never know ... :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Replace utmp, wtmp, btmp, and lastlog completely with journal We should definitely add the data needed to constuct this information, if they are not already there. The tools could just use the journal directly, but there is the glibc api. Exactly; barring a compatibility library that provides the same functions as glibc, which seems hazardous, I'd like to support tools that only know how to read and write those files directly. + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly Coredump are really not consumed by any legacy thing that would need a file system. What do you have in mind here. Specialized apps that need that should just use the native API, not expect a file system, I think. Just an idea for how to better satisfy user expectations. Approximately zero cost, mounted on demand, gives a view into the journal. +- Provide decoded text logs in /var/log I really don't think these plain text streams make much sense today. If people want them, they should install syslog. Or some other project can do that, I'm confident we do not want that code in systemd. Maintaining a separate copy of log messages seems like overkill; I want the data stored solely in the journal. And I agree that the code doesn't belong in the journal itself; I'm suggesting that a standalone FUSE filesystem based on the journal library would prove useful for compatibility with both tools that want to consume the log format and users used to /var/log. Seems pretty trivial to write, as well. + - Port upower to use the journal for historical power information used in future calculations Yeah, that would be useful. + - Support optional database-style indexes for frequent or performance-critical queries Well, it is not a database, it's a pretty specialized format based on bisection lists. What specific thing do you have in mind? Telling the journal in advance that you'd like to make a lot of queries for PROPERTY, or for PROPERTY=value, and having it maintain an index that makes such queries faster than a linear scan and filter. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:15:22AM +0200, Kay Sievers wrote: On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. Not really, we cannot or don't want to cover all of cron, so cron stays around anyway for the grey beards, or existing things out there. As far as I can tell, timer units already support almost everything crontabs do; the problem then just becomes a format parser and unit generator. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: timer unit generation
On Thu, Apr 18, 2013 at 12:30 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:15:22AM +0200, Kay Sievers wrote: On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: + - unit generator for compatibility with crontab and cron.d We kind of decided to port the 40-60 things that use the .d/ dirs to native units right away, and leave cron as it is, and not parse its config files from systemd. If people want cron, they should install it; new or common stuff should just not pull it in anymore. The default install should not require it. I figured this fell in the general area of wouldn't do it ourselves, but would probably take a clean patch, which seemed like a good use of TODO. Not really, we cannot or don't want to cover all of cron, so cron stays around anyway for the grey beards, or existing things out there. As far as I can tell, timer units already support almost everything crontabs do; the problem then just becomes a format parser and unit generator. Yeah, if you have a hammer ... :) The thing is that there are cron features we cannot support at the moment, and then there are ones the we do not want to support, so we cannot really fully replace it. Hence we decided to get it out of the common use, leave it as it is, instead of pretending we can take it over. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Thu, Apr 18, 2013 at 12:28 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Replace utmp, wtmp, btmp, and lastlog completely with journal We should definitely add the data needed to constuct this information, if they are not already there. The tools could just use the journal directly, but there is the glibc api. Exactly; barring a compatibility library that provides the same functions as glibc, which seems hazardous, I'd like to support tools that only know how to read and write those files directly. Hmm, from system's side I would consider the current state as sufficient, and future work should probably focus on getting rid of all that on systems that do not care, and not pimp up these crazy text files. + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. I don't know what *forever* means here, I kind of doubt that. It's pure legacy stuff that needs that, and that works with current systemd. Most systems out there should not need these silly files at all, and the use will surely not grow in the future. +- Provide /var/spool/crash or equivalent, exposing an index of coredumps directly Coredump are really not consumed by any legacy thing that would need a file system. What do you have in mind here. Specialized apps that need that should just use the native API, not expect a file system, I think. Just an idea for how to better satisfy user expectations. Approximately zero cost, mounted on demand, gives a view into the journal. Yeah, but it does come with a lot of costs, code, ressources, and all just for one or two custom tools to consume that. I would avoid that. +- Provide decoded text logs in /var/log I really don't think these plain text streams make much sense today. If people want them, they should install syslog. Or some other project can do that, I'm confident we do not want that code in systemd. Maintaining a separate copy of log messages seems like overkill; I want the data stored solely in the journal. And I agree that the code doesn't belong in the journal itself; I'm suggesting that a standalone FUSE filesystem based on the journal library would prove useful for compatibility with both tools that want to consume the log format and users used to /var/log. Seems pretty trivial to write, as well. Yeah, sounds like a nice feature, but I'm not sure it belongs in systemd. I don't want to manage logrotate on top of that fuse filesystem, and all the other wild things that will happen then. Some other project should open that can of worms. :) + - Port upower to use the journal for historical power information used in future calculations Yeah, that would be useful. + - Support optional database-style indexes for frequent or performance-critical queries Well, it is not a database, it's a pretty specialized format based on bisection lists. What specific thing do you have in mind? Telling the journal in advance that you'd like to make a lot of queries for PROPERTY, or for PROPERTY=value, and having it maintain an index that makes such queries faster than a linear scan and filter. Hmm, I guess that works already just fine for the most common cases. You've seen any real-world problems? The managed data with the cursor support in the journal allow easy live-export to real databases if such flexibility is required. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: clarify usage of --all versus list-unit-files
On Wed, 10.04.13 12:34, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Novice users might think, that $ systemctl --all is equal to $ systemctl list-unit-files Note that systemctl will already clarify this this in the quick summary it shows at the end of the list. - paraWhen listing units, show all units, regardless of + paraWhen listing units, show all internally loaded units, regardless of their state, including inactive units. When showing unit/job/manager properties, show all properties regardless whether they are set or not./para + paraTo list all units installed on disk, use the command + commandlist-unit-files/command instead./para I just did a minor modification to the text in git: I dropped the internally, since I wouldn't know what this is supposed to mean, and we shouldn't introduce new terminology here we use nowhere else. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: set the timeout to 0 by default
On Fri, 12.04.13 09:45, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com cryptsetup itself has no timeout as default from the beginning. So the default timeout has been 0 from the beginning. Makes sense I guess. Applied. Also added a comment to crypttab(5) to mention that this is the default. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per-instance override with foobar.service.d
On Mon, 08.04.13 20:08, John Lane (syst...@jelmail.com) wrote: I'm trying out the new foobar.service.d way of overriding unit files. I thought that I'd be able to have a number of service instances that were overridden differently but that does not seem to be the case (or, at least, I can't get it to work). I first updated to systemd 200 and tried foobar.service.d with foobar.service.d/custom.conf; this works as described on the man page and release notes. I've also tried: foobar@.service and foobar@.service.d/myinstance.conf foobar@.service and foobar@myinstance.service.d/myinstance.conf This should definitely work, and if it doesn't this sounds like oversight. I have added to the TODO list to fix this. which don't work so I guess this isn't implemented. If so, would something like that be a reasonable request to be considered ? I was thinking... foobar@.service foobar@.service.d/myfirstinstance.conf foobar@.service.d/mysecondinstance.conf where the relevant .conf would be selected based on the instance name. This sounds redundant and confusing, no? I mean, if we'd implement that you only could have exctly one drop-in file pre instance, and that wold be a serious limitation, no? I was also wondering why the need for a separate sub-directory when there's only one file inside it. Could a file like foobar.service.conf be considered as an alternative (and, perhaps, foo...@myinstance.service.conf) ? I'd prefer not adding to much redundancy here. Also, the .d/ scheme for multiple drop-ins is also kinda known vocabulary on Unix already, so we thought to stick to it, and have things a bit uniform... I mean, I can be conviced to add something if it really makes sense. But for that it better not add redundancy, or if it does then you need a really strong case for it... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
On Wed, 10.04.13 16:53, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com This patch adds environment variable substition for PIDFile=. To read the environment files only once, ExecContext holds a copy of the environment gathered. RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260 I am really not convinced about this one. The final environment is only put together right before we execute a binary, and resolving this much earlier sounds like the wrong thing to do, because it would necessarily not be in sync with the environment we pass to the binary. Also, we currently do not resolve environment variables in any directive except ExecXYZ=. If we begin doing this here, then people want it everywhere, and things become really messy... This makes it particularly hard for people to write sane external parsers for this, since suddenly to understand unit files you actually need to resolve env vars, it is no longer sufficient to resolve env vars only when executing things, i.e. to leave that to systemd... Then, the whole PID file story looks like a mess to me anyway, modern daemons should not use PID files anyway... Even more, making them configurable sounds really wrong. If this is about allowing instantiation, then people can use %i in the PID file name, and be done with it, but otherwise this sounds like a completely ridiculous configuration option in sysconfig, like the first one to get rid of... So the usecase already sounds really wrong to me, to start with. This really sounds like a bug to me we should close WONTFIX with a nice explanation. I know Tom won't like that, but well, sometimes we have to say No to wishes. I know I though different about this in January (and commented so in the bug), but in retrospect I must disagree with myself on this... Sorry, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V2] cryptsetup-generator: add support for rd.luks.key=
On Thu, 11.04.13 15:44, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Also clarify rd.luks.uuid and luks.uuid in the manual. https://bugzilla.redhat.com/show_bug.cgi?id=905683 Sounds good. Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Move bus_error to dbus-common and remove bus_error_message_or_strerror
On Thu, 11.04.13 00:39, Simon Peeters (peeters.si...@gmail.com) wrote: bus_error and bus_error_message_or_strerror dit almost exactly the same, so use only one of them and place it in dbus-common. Looks good! Fixed a compilation issue and commited! Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
