Re: [systemd-devel] [ANNOUNCE] systemd 199
On Tue, Mar 26, 2013 at 05:40:59PM +0100, Philip Müller wrote: systemd-199 build just fine on 64bit, but on 32bit it fails during check: PASS: test-sleep ./build-aux/test-driver: line 95: 18318 Segmentation fault (core dumped) $@ $log_file 21 Fixed as of 49e5de64e22ea4794092b91393545ab08e658e0a for me. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpJIoQMrYvOr.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture
]] Cristian Rodríguez El 26/03/13 15:17, Bill Nottingham escribió: Lukas Nykryn (lnyk...@redhat.com) said: --- TODO | 2 -- man/systemd.unit.xml.in | 8 src/core/condition.c | 16 src/core/condition.h | 1 + src/core/load-fragment-gperf.gperf.m4 | 1 + 5 files changed, 26 insertions(+), 2 deletions(-) Not that this seems wrong, but what is the usage case for this that can't be solved via package (de)installation? The patch looks fine to me, what it solves ? well.. there may be generic image deployments , who contain the same packages but one of them is only really useful in arch s390 or ppc.. etc.. I think it should be kernel architecture if so, since you might very well have multiple userland architectures enabled and working at the same time. (So it should be ConditionKernelArchitecture to make it clear.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] sd-bus: check c-path for null instead of path
---
src/libsystemd-bus/sd-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/sd-bus.c b/src/libsystemd-bus/sd-bus.c
index 5f2ede0..6acc59e 100644
--- a/src/libsystemd-bus/sd-bus.c
+++ b/src/libsystemd-bus/sd-bus.c
@@ -1944,7 +1944,7 @@ static int bus_add_object(
return -ENOMEM;
c-path = strdup(path);
-if (!path) {
+if (!c-path) {
free(c);
return -ENOMEM;
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] log: fix error codes handling in catalog_list_items
Previously r was set to zero and so if(r0) was never true. Also it does not
make sense to print error code from previous loop.
---
src/journal/catalog.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index dacf5c5..96854d7 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -616,9 +616,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
k = sd_id128_from_string(*item, id);
if (k 0) {
log_error(Failed to parse id128 '%s': %s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
@@ -626,9 +625,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
if (k 0) {
log_full(k == -ENOENT ? LOG_NOTICE : LOG_ERR,
Failed to retrieve catalog entry for '%s':
%s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 199
Here on this machine it still fails. It can also be an issue with this installation. I created a tarball out of git with followed commit as last one: 590888a0d0cb813714fa2a521e2ca711f75862fb http://cgit.freedesktop.org/systemd/systemd/commit/?id=590888a0d0cb813714fa2a521e2ca711f75862fb Still the same result: PASS: test-bus-signature ./build-aux/test-driver: Zeile 95: 20079 Speicherzugriffsfehler (Speicherabzug geschrieben) $@ $log_file 21 FAIL: test-bus-marshal Will test it on a different machine now. Am 27.03.2013 06:07, schrieb William Giokas: On Tue, Mar 26, 2013 at 05:40:59PM +0100, Philip Müller wrote: systemd-199 build just fine on 64bit, but on 32bit it fails during check: PASS: test-sleep ./build-aux/test-driver: line 95: 18318 Segmentation fault (core dumped) $@ $log_file 21 Fixed as of 49e5de64e22ea4794092b91393545ab08e658e0a for me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] support statically configured acls
Kay Sievers wrote: On Sat, Mar 23, 2013 at 1:57 PM, Kay Sievers k...@vrfy.org wrote: On Sat, Mar 23, 2013 at 12:16 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.03.13 17:36, Ludwig Nussel (ludwig.nus...@suse.de) wrote: useful to get ACLs on files, sockets etc not known to udev Can't say I like this one. Sounds like an awful lot of code to me to support evil closed source drivers. Kay, what do you say? If we could find a simpler way (for example, a list setting in logind.conf) and emphasize that this is for any file, for example sockets/fifos, this might be more palatable to me, but I still don't like it. If possible, I would avoid another setting. We should rather look into making the dead device nodes exported by the kernel in: /lib/modules/$(uname -r)/modules.devname work with ACLs. This does not only solve the problems with proprietary modules, they would just ship their device node info in the module itself. But would also apply the ACL to things like: /dev/snd/seq where ordinary users cannot trigger the on-demand module-load. The ACL will only be applied after the module is loaded. It's all not that trivial, but solvable I guess. The config for the ACLs and the permissions is stored in udev rules, and we would need to export that somehow to the uaccess code. This seems to apply the ACL to /dev/snd/seq: http://people.freedesktop.org/~kay/0001-udev-export-dead-device-nodes-to-run-udev-devnode-ua.patch Works fine AFAICT and with some creative tricks can be (ab)used get ACLs on arbitrary device nodes. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Optimizing systemd binaries for small deployments
Hi there, We are in the process of creating a very small image for devices with a maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB using Systemd we are currently getting images sizes of ~10MB. At first glance the systemd binaries seem quite large. Before diving into lots of optimization I wanted to ask whether anybody has pointers we should follow or even experience using systemd for bare minimum images. Cheers Tino ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Sun, Mar 24, 2013 at 3:38 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: I don't see anything in udev code setting IOPRIO... perhaps elevating the few calls doing bklid and mount might be helpful? Maybe that really makes a difference, we should definitely try that. The blkid calls are really limited to a few bytes here and there, and will never loop for a long time, so that should be fine. Do you have a box, where you could you give it a quick try to bump the prio for the libblkid calls: ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...) in: src/udev/udev-builtin-blkid.c ? I left my non-ssd dev box in the office, so it'll be monday - but I'll absolutely give it a good test run. Could you still give that a simple try with current git and the chunking in place, so that we have some idea if the blkid calls would benefit from a higher priority? Even if we decide against doing that in the end, it would be nice to know ... Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture
On Wed, Mar 27, 2013 at 08:22:14AM +0100, Tollef Fog Heen wrote: ]] Cristian Rodríguez El 26/03/13 15:17, Bill Nottingham escribió: Lukas Nykryn (lnyk...@redhat.com) said: --- TODO | 2 -- man/systemd.unit.xml.in | 8 src/core/condition.c | 16 src/core/condition.h | 1 + src/core/load-fragment-gperf.gperf.m4 | 1 + 5 files changed, 26 insertions(+), 2 deletions(-) Not that this seems wrong, but what is the usage case for this that can't be solved via package (de)installation? The patch looks fine to me, what it solves ? well.. there may be generic image deployments , who contain the same packages but one of them is only really useful in arch s390 or ppc.. etc.. I think it should be kernel architecture if so, since you might very well have multiple userland architectures enabled and working at the same time. (So it should be ConditionKernelArchitecture to make it clear.) Shouldn't this be a glob, like ConditionHost=? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-sysctl: Handle missing /etc/sysctl.conf properly
Since fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda, systemd-sysctl returns
a non-zero exit code if /etc/sysctl.conf does not exist, due to a
broken ENOENT check.
---
src/sysctl/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 2d43660..79f3f77 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -125,7 +125,7 @@ static int parse_file(Hashmap *sysctl_options, const char
*path, bool ignore_eno
r = search_and_fopen_nulstr(path, re, conf_file_dirs, f);
if (r 0) {
-if (ignore_enoent errno == -ENOENT)
+if (ignore_enoent r == -ENOENT)
return 0;
log_error(Failed to open file '%s', ignoring: %s, path,
strerror(-r));
--
1.8.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture
St 27. březen 2013, 13:21:28 CET, Zbigniew Jędrzejewski-Szmek napsal: On Wed, Mar 27, 2013 at 08:22:14AM +0100, Tollef Fog Heen wrote: ]] Cristian Rodríguez El 26/03/13 15:17, Bill Nottingham escribió: Lukas Nykryn (lnyk...@redhat.com) said: --- TODO | 2 -- man/systemd.unit.xml.in | 8 src/core/condition.c | 16 src/core/condition.h | 1 + src/core/load-fragment-gperf.gperf.m4 | 1 + 5 files changed, 26 insertions(+), 2 deletions(-) Not that this seems wrong, but what is the usage case for this that can't be solved via package (de)installation? The patch looks fine to me, what it solves ? well.. there may be generic image deployments , who contain the same packages but one of them is only really useful in arch s390 or ppc.. etc.. I think it should be kernel architecture if so, since you might very well have multiple userland architectures enabled and working at the same time. (So it should be ConditionKernelArchitecture to make it clear.) Shouldn't this be a glob, like ConditionHost=? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I don't think that is necessary, the set of all architectures is quite small. But it would just mean to replace ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible race condition for setting cgroup sticky bit
I just tested it with systemd 199 and the problem still occurs. However it now fails with Failed at step CGROUP spawning /etc/init.d/rc: No such file or directory just like in 197 and not with a segfault as I saw (at least sometimes) with 198. /Anders -Original Message- From: systemd-devel- bounces+anders.olofsson=axis@lists.freedesktop.org [mailto:systemd- devel-bounces+anders.olofsson=axis@lists.freedesktop.org] On Behalf Of Anders Olofsson Sent: den 26 mars 2013 13:43 To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] Possible race condition for setting cgroup sticky bit I'm seeing a problem with a service sometimes failing to start due to a missing cgroup. After some debugging I've made the following observations: After exec_spawn() forks, the child will set the sticky bit for the cgroup (in cg_set_task_access) but sometimes, the cgroup is missing (lstat returns No such file or directory). The cgroup is always created, but the main process will call cg_trim (from cgroup_bonding_trim - cgroup_bonding_trim_list - cgroup_notify_empty - private_bus_message_filter ...) which will remove the cgroup if the sticky bit isn't set. This seems to be a race condition. If the child sets the sticky bit first, the parent will leave the cgroup alone. But if the main process gets to cg_trim first, the cgroup is removed and the child fails. We're using systemd 197. I've tried using 198, but there the child dies with SIGSEGV so it's harder to debug what's happening. The problem appeared when we switched from Linux 3.4 to 3.7, but as this looks like a race in systemd so I'm not sure if our local kernel tree is to blame or if the version bump just changed the timing to trigger the race in systemd. Since I'm not familiar with the systemd internals and cgroups I would appreciate some help to resolve this. I can reproduce this pretty easy, usually within 5-10 boots. It's always the same service that fails and the services before it never fails. /Anders ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Optimizing systemd binaries for small deployments
On Wed, Mar 27, 2013 at 11:49:44AM +0100, Tino Breddin wrote: Hi there, We are in the process of creating a very small image for devices with a maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB using Systemd we are currently getting images sizes of ~10MB. At first glance the systemd binaries seem quite large. Before diving into lots of optimization I wanted to ask whether anybody has pointers we should follow or even experience using systemd for bare minimum images. I'm assuming that you're compiling without -g and such. Please remember that systemd stuff replaces quite a few other binaries, rather than just /sbin/init, so you should compare that against the sum of replaced things. One thing you could try, is the shared library approach. Currently we use a static convinience library, but it could be changed to a shared libsystemd-private.so, and more code would be shared. There was a thread a while back. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Optimizing systemd binaries for small deployments
I figured the next step would be to dive in and remove duplicate or unneeded functionality. I couldn't find information about a shared library approach yet, which should naturally be a great improvement. Guess I should check the ML archives a little more. Tino - Original Message - From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl To: Tino Breddin tbred...@tpip.net Cc: systemd-devel@lists.freedesktop.org Sent: Wednesday, March 27, 2013 2:09:05 PM Subject: Re: [systemd-devel] Optimizing systemd binaries for small deployments On Wed, Mar 27, 2013 at 11:49:44AM +0100, Tino Breddin wrote: Hi there, We are in the process of creating a very small image for devices with a maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB using Systemd we are currently getting images sizes of ~10MB. At first glance the systemd binaries seem quite large. Before diving into lots of optimization I wanted to ask whether anybody has pointers we should follow or even experience using systemd for bare minimum images. I'm assuming that you're compiling without -g and such. Please remember that systemd stuff replaces quite a few other binaries, rather than just /sbin/init, so you should compare that against the sum of replaced things. One thing you could try, is the shared library approach. Currently we use a static convinience library, but it could be changed to a shared libsystemd-private.so, and more code would be shared. There was a thread a while back. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] core: check return value of rm_rf_dangerous and warn if it fails
From: Václav Pavlín vpav...@redhat.com
---
src/core/execute.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/core/execute.c b/src/core/execute.c
index bc876a3..936e7d8 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1559,10 +1559,16 @@ void exec_context_tmp_dirs_done(ExecContext *c) {
for(dirp = dirs; *dirp; dirp++) {
char *dir;
-rm_rf_dangerous(*dirp, false, true, false);
+int r=0;
+r = rm_rf_dangerous(*dirp, false, true, false);
dir = dirname(*dirp);
-rmdir(dir);
+if (r0)
+log_warning(Failed to remove content of tmp_dir %s.,
dir);
+else {
+dir = dirname(*dirp);
+rmdir(dir);
+}
free(*dirp);
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] shared: free dt (temporary dir name) on fail
From: Václav Pavlín vpav...@redhat.com
---
src/shared/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 0444cf4..b724959 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5733,6 +5733,7 @@ int create_tmp_dir(char template[], char** dir_name) {
return 0;
fail1:
rmdir(dt);
+free(dt);
fail2:
rmdir(template);
return r;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] udev: check return value of uname.
On Wed, 27.03.13 15:16, Vaclav Pavlin (vpav...@redhat.com) wrote: From: Václav Pavlín vpav...@redhat.com --- src/udev/udevd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/udev/udevd.c b/src/udev/udevd.c index b30bedf..379168d 100644 --- a/src/udev/udevd.c +++ b/src/udev/udevd.c @@ -819,7 +819,9 @@ static void static_dev_create_from_modules(struct udev *udev) char buf[4096]; FILE *f; -uname(kernel); +if (uname(kernel) 0) +return; + I wouldn't mind enclosing this in assert_se(), since this specific system call cannot realistically 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] [PATCH 2/3] udev: check return value of uname.
On Wed, Mar 27, 2013 at 04:50:48PM +0100, Lennart Poettering wrote: On Wed, 27.03.13 15:16, Vaclav Pavlin (vpav...@redhat.com) wrote: From: Václav Pavlín vpav...@redhat.com --- src/udev/udevd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/udev/udevd.c b/src/udev/udevd.c index b30bedf..379168d 100644 --- a/src/udev/udevd.c +++ b/src/udev/udevd.c @@ -819,7 +819,9 @@ static void static_dev_create_from_modules(struct udev *udev) char buf[4096]; FILE *f; -uname(kernel); +if (uname(kernel) 0) +return; + I wouldn't mind enclosing this in assert_se(), since this specific system call cannot realistically fail. Hi, assert might not be nice, because of random selinux denials... Wouldn't it be better to continue if possible? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-sysctl: Handle missing /etc/sysctl.conf properly
On Wed, Mar 27, 2013 at 01:41:59PM +0100, Eelco Dolstra wrote: Since fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda, systemd-sysctl returns a non-zero exit code if /etc/sysctl.conf does not exist, due to a broken ENOENT check. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] log: fix error codes handling in catalog_list_items
On Wed, Mar 27, 2013 at 10:44:21AM +0100, Lukas Nykryn wrote:
Previously r was set to zero and so if(r0) was never true. Also it does not
make sense to print error code from previous loop.
Applied the first one and a half of this one. You're right that k should
be used instead of r, but this is in a loop, so r 0 is possible. The
convention is to return the *first* error.
Zbyszek
---
src/journal/catalog.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index dacf5c5..96854d7 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -616,9 +616,8 @@ int catalog_list_items(FILE *f, bool oneline, char
**items) {
k = sd_id128_from_string(*item, id);
if (k 0) {
log_error(Failed to parse id128 '%s': %s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
@@ -626,9 +625,8 @@ int catalog_list_items(FILE *f, bool oneline, char
**items) {
if (k 0) {
log_full(k == -ENOENT ? LOG_NOTICE : LOG_ERR,
Failed to retrieve catalog entry for '%s':
%s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] core: check return value of rm_rf_dangerous and warn if it fails
On Wed, Mar 27, 2013 at 03:16:35PM +0100, Vaclav Pavlin wrote:
From: Václav Pavlín vpav...@redhat.com
---
src/core/execute.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/core/execute.c b/src/core/execute.c
index bc876a3..936e7d8 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1559,10 +1559,16 @@ void exec_context_tmp_dirs_done(ExecContext *c) {
for(dirp = dirs; *dirp; dirp++) {
char *dir;
-rm_rf_dangerous(*dirp, false, true, false);
+int r=0;
+r = rm_rf_dangerous(*dirp, false, true, false);
dir = dirname(*dirp);
-rmdir(dir);
+if (r0)
+log_warning(Failed to remove content of tmp_dir
%s., dir);
+else {
+dir = dirname(*dirp);
+rmdir(dir);
+}
free(*dirp);
}
Applied this one with a tweak to check rmdir return value too.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] shared: free dt (temporary dir name) on fail
On Wed, Mar 27, 2013 at 03:16:37PM +0100, Vaclav Pavlin wrote:
From: Václav Pavlín vpav...@redhat.com
---
src/shared/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 0444cf4..b724959 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5733,6 +5733,7 @@ int create_tmp_dir(char template[], char** dir_name) {
return 0;
fail1:
rmdir(dt);
+free(dt);
fail2:
rmdir(template);
return r;
Applied this one with a tweak to not call rmdir() unless mkdir() succeeded.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] log: fix error codes handling in catalog_list_items
So if we want to return first error there should be
-if (r 0)
+if (r == 0)
r = k;
Am I right?
Lukas
St 27. březen 2013, 17:06:27 CET, Zbigniew Jędrzejewski-Szmek napsal:
On Wed, Mar 27, 2013 at 10:44:21AM +0100, Lukas Nykryn wrote:
Previously r was set to zero and so if(r0) was never true. Also it does not
make sense to print error code from previous loop.
Applied the first one and a half of this one. You're right that k should
be used instead of r, but this is in a loop, so r 0 is possible. The
convention is to return the *first* error.
Zbyszek
---
src/journal/catalog.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index dacf5c5..96854d7 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -616,9 +616,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
k = sd_id128_from_string(*item, id);
if (k 0) {
log_error(Failed to parse id128 '%s': %s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
@@ -626,9 +625,8 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
if (k 0) {
log_full(k == -ENOENT ? LOG_NOTICE : LOG_ERR,
Failed to retrieve catalog entry for '%s':
%s,
- *item, strerror(-r));
-if (r 0)
-r = k;
+ *item, strerror(-k));
+r = k;
continue;
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] catalog: fix error codes handling in catalog_list_items
Previously r was set to zero and so if(r0) was never true.
---
src/journal/catalog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index 6b195f6..7ae7b3e 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -617,7 +617,7 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
if (k 0) {
log_error(Failed to parse id128 '%s': %s,
*item, strerror(-k));
-if (r 0)
+if (r == 0)
r = k;
continue;
}
@@ -627,7 +627,7 @@ int catalog_list_items(FILE *f, bool oneline, char **items)
{
log_full(k == -ENOENT ? LOG_NOTICE : LOG_ERR,
Failed to retrieve catalog entry for '%s':
%s,
*item, strerror(-k));
-if (r 0)
+if (r == 0)
r = k;
continue;
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] catalog: fix error codes handling in catalog_list_items
On Wed, Mar 27, 2013 at 05:35:55PM +0100, Lukas Nykryn wrote: Previously r was set to zero and so if(r0) was never true. Applied. Thanks. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Optimizing systemd binaries for small deployments
El 27/03/13 07:49, Tino Breddin escribió: Hi there, We are in the process of creating a very small image for devices with a maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB using Systemd we are currently getting images sizes of ~10MB. At first glance the systemd binaries seem quite large. Before diving into lots of optimization I wanted to ask whether anybody has pointers we should follow or even experience using systemd for bare minimum images. Assuming you already disabled debug info and understood that systemd replaces more than init and has a lot of command line switches to disable functionality you may not need...then yes go ahead with ideas. However I think you are doing something wrong, openSUSE's fully featured systemd package is 4.4 MB in size including the rpm metadata. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture
On Wed, Mar 27, 2013 at 12:22 AM, Tollef Fog Heen tfh...@err.no wrote: ]] Cristian Rodríguez El 26/03/13 15:17, Bill Nottingham escribió: Lukas Nykryn (lnyk...@redhat.com) said: --- TODO | 2 -- man/systemd.unit.xml.in | 8 src/core/condition.c | 16 src/core/condition.h | 1 + src/core/load-fragment-gperf.gperf.m4 | 1 + 5 files changed, 26 insertions(+), 2 deletions(-) Not that this seems wrong, but what is the usage case for this that can't be solved via package (de)installation? The patch looks fine to me, what it solves ? well.. there may be generic image deployments , who contain the same packages but one of them is only really useful in arch s390 or ppc.. etc.. I think it should be kernel architecture if so, since you might very well have multiple userland architectures enabled and working at the same time. (So it should be ConditionKernelArchitecture to make it clear.) or should it? on x86_64 one could have a kernel architecture supporting both x86_64 and i586, and running `setarch i586` does not change the kernel... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] cryptsetup: RequiresMountsFor if source is a file
Fixes bug 60821 --- TODO | 1 - src/cryptsetup/cryptsetup-generator.c | 22 -- 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/TODO b/TODO index e54f84b..fc05317 100644 --- a/TODO +++ b/TODO @@ -354,7 +354,6 @@ Features: * cryptsetup: - cryptsetup-generator: warn if the password files are world-readable - - cryptsetup-generator: add RequiresMountsFor= to cryptseup service files referencing a file, similar for devices - cryptsetup-generator: allow specification of passwords in crypttab itself - move cryptsetup key caching into kernel keyctl? https://bugs.freedesktop.org/show_bug.cgi?id=54982 diff --git a/src/cryptsetup/cryptsetup-generator.c b/src/cryptsetup/cryptsetup-generator.c index 8959bf5..00e7f7d 100644 --- a/src/cryptsetup/cryptsetup-generator.c +++ b/src/cryptsetup/cryptsetup-generator.c @@ -102,18 +102,17 @@ static int create_disk( return -errno; } -fprintf(f, +fputs( # Automatically generated by systemd-cryptsetup-generator\n\n [Unit]\n -Description=Cryptography Setup for %%I\n +Description=Cryptography Setup for %I\n Documentation=man:systemd-cryptsetup@.service(8) man:crypttab(5)\n SourcePath=/etc/crypttab\n Conflicts=umount.target\n DefaultDependencies=no\n -BindsTo=%s dev-mapper-%%i.device\n -After=systemd-readahead-collect.service systemd-readahead-replay.service %s\n -Before=umount.target\n, -d, d); +BindsTo=dev-mapper-%i.device\n +After=systemd-readahead-collect.service systemd-readahead-replay.service\n, +f); if (!nofail) fprintf(f, @@ -126,6 +125,17 @@ static int create_disk( else fputs(Before=local-fs.target\n, f); +if (startswith(u, /dev/)) +fprintf(f, +BindsTo=%s\n +After=%s\n +Before=umount.target\n, +d, d); +else +fprintf(f, +RequiresMountsFor=%s\n, +u); + fprintf(f, \n[Service]\n Type=oneshot\n -- 1.8.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] cryptsetup: add RequiresMountsFor for passfile
Removed Before=local-fs.target because the respective mountpoint
already does this.
---
src/cryptsetup/cryptsetup-generator.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 00e7f7d..70703ae 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -118,12 +118,17 @@ static int create_disk(
fprintf(f,
Before=cryptsetup.target\n);
-if (password (streq(password, /dev/urandom) ||
- streq(password, /dev/random) ||
- streq(password, /dev/hw_random)))
-fputs(After=systemd-random-seed-load.service\n, f);
-else
-fputs(Before=local-fs.target\n, f);
+if (password) {
+if (streq(password, /dev/urandom) ||
+streq(password, /dev/random) ||
+streq(password, /dev/hw_random))
+fputs(After=systemd-random-seed-load.service\n, f);
+else if (!streq(password, -)
+ !streq(password, none))
+fprintf(f,
+RequiresMountsFor=%s\n,
+password);
+}
if (startswith(u, /dev/))
fprintf(f,
--
1.8.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] man/os-release: Add BUILD_ID field
On Mon, Mar 25, 2013 at 2:07 PM, William Douglas william.doug...@intel.com wrote: BUILD_ID is a fairly generic field used to identify the system image that was used to install the distribution. Signed-off-by: William Douglas william.doug...@intel.com --- man/os-release.xml | 22 ++ 1 file changed, 22 insertions(+) merged, thanks. I did remove the signed-off-by, which isn't needed. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-inhibit --what=handle-power-key broken with systemd 198
Hello, I'm using ArchLinux which currently uses systemd 198. I try to inhibit the power key to get sure systemd doesn't shut down if it is pressed. My testcase is as follows: # systemd-inhibit --what=handle-power-key --mode=block sleep 100 Now I switch to another shell to check if the inhibitor is listed: # systemd-inhibit --list Who: sleep 100 (UID 0, PID 222) What: handle-power-key Why: Unknown reason Mode: block 1 inhibitors listed. After doing so and getting sure the inhibitor really is listed, I hit the power key and... the system is shutting down... For me it seems like something caused this whole thing to get broken. Can someone reproduce or is this only broken on ArchLinux? Yours Manuel Reimer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-inhibit --what=handle-power-key broken with systemd 198
Just one more information: It seems like the inhibitors work if I'm on the same shell/virtual terminal where the inhibitor was created. So the inhibitors, created by KDE, only work if I'm on the KDE screen. If I switch to another VT, then the power button forcefully shuts down the system. Seems like I'm seeing the same effect with my code, but as I want to use an inhibitor in a daemon that gets started by systemd while the system boots, this doesn't make much sense for me. Manuel Reimer wrote: Hello, I'm using ArchLinux which currently uses systemd 198. I try to inhibit the power key to get sure systemd doesn't shut down if it is pressed. My testcase is as follows: # systemd-inhibit --what=handle-power-key --mode=block sleep 100 Now I switch to another shell to check if the inhibitor is listed: # systemd-inhibit --list Who: sleep 100 (UID 0, PID 222) What: handle-power-key Why: Unknown reason Mode: block 1 inhibitors listed. After doing so and getting sure the inhibitor really is listed, I hit the power key and... the system is shutting down... For me it seems like something caused this whole thing to get broken. Can someone reproduce or is this only broken on ArchLinux? Yours Manuel Reimer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Wed, Mar 27, 2013 at 10:50 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wed, Mar 27, 2013 at 4:55 AM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 24, 2013 at 3:38 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: I don't see anything in udev code setting IOPRIO... perhaps elevating the few calls doing bklid and mount might be helpful? Maybe that really makes a difference, we should definitely try that. The blkid calls are really limited to a few bytes here and there, and will never loop for a long time, so that should be fine. Do you have a box, where you could you give it a quick try to bump the prio for the libblkid calls: ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...) in: src/udev/udev-builtin-blkid.c ? I left my non-ssd dev box in the office, so it'll be monday - but I'll absolutely give it a good test run. Could you still give that a simple try with current git and the chunking in place, so that we have some idea if the blkid calls would benefit from a higher priority? Even if we decide against doing that in the end, it would be nice to know ... I'm pretty sure it'll make a big dent, and I started looking at it already... So, I just spent an hour or so playing around with some stuff, and here are my thoughts: First off, it seems making the blkid parts run at RT,0 prio (highest possible) does absolutely nothing, which suggests that Lennart was right that almost all parts are already cached. However, while looking at the bootcharts I'm noticing `fsck` and `systemd-fsck` is taking considerable time to complete: before: - all fsck's done around 5.5sec total (measured after kernel done booting) - systemd-fsck's take ~ 2.4 secs - fsck children run for 2.2-2.8 seconds I then added RT,0 prio to systemd-fsck just before it forks it's children: after: - all fsck's done around 3.5secs total - systemd-fsck's take ~0.8 secs - fsck children run for 0.4-0.7 secs All in all that's a big gain, and it immediately exposes that `lvm` also is crazy slow (this is a vanilla fc18 install). So, I'd be interested in making this the default. Maybe not RT,0 which is a bit of a whammer, but certainly BE,0 or even RT,5 or something like that. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
