[systemd-devel] [PATCH] bootctl: fix help text
It currently says 'time settings', change that to 'boot settings'.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
src/boot/bootctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c
index a920277..af694fd 100644
--- a/src/boot/bootctl.c
+++ b/src/boot/bootctl.c
@@ -38,7 +38,7 @@ static int help(void) {
-h --help Show this help\n
--version Show package version\n
Commands:\n
- status Show current time settings\n,
+ status Show current boot settings\n,
program_invocation_short_name);
return 0;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persistent changes to the serial console
В Wed, 27 Mar 2013 08:40:00 -0500 David A. Marlin dmar...@redhat.com пишет: moving to the mailing list: On 03/26/2013 09:04 PM, Lennart Poettering wrote: On 26.03.2013 19:21, David Marlin wrote: I am trying to make the serial console automatically log in a user on boot. I tried modifying: /lib/systemd/system/serial-getty@.service /lib/ is package manager territory, you should never edit files there, the package manager will otherwise override your changes without hehow to correct thissitation. Instead, copy /lib/systemd/system/serial-getty@.service to /etc/systemd/system/serial-getty@.service -- /etc is administrator territory, and unit files stored there will automatically override unit files by the same name in /lib. I had actually tried this (or several variations on this), but it was not producing the desired results. I tried again using exactly what you suggested. For this example, I just used 'root' user for testing. Below are snippets of the steps I performed: -- cp /lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty@.service vi /etc/systemd/system/serial-getty@.service diff -u /lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty@.service --- [Service] -ExecStart=-/sbin/agetty -s %I 115200,38400,9600 vt102 +ExecStart=-/sbin/agetty -s --noclear --autologin root %I 115200,38400,9600 vt102 --- [root@localhost ~]# systemctl daemon-reload [root@localhost ~]# exit logout Fedora release 18 (Spherical Cow) Kernel 3.6.10-8.fc18.armv7hl.tegra on an armv7l (ttyS0) localhost login: ( note: still prompts for login ) [root@localhost ~]# reboot : Fedora release 18 (Spherical Cow) Kernel 3.6.10-8.fc18.armv7hl.tegra on an armv7l (ttyS0) localhost login: ( note: again, after reboot, prompts for login ) serial-getty@.service is used only as template, and it looks like getty-generator always links to (/usr)/lib/systemd: from = strappend(SYSTEM_DATA_UNIT_PATH /, fservice); to = strjoin(arg_dest,/getty.target.wants/, tservice, NULL); It probably should use real unit path for fservice. [root@localhost ~]# cp /etc/systemd/system/serial-getty@.service /lib/systemd/system/serial-getty@.service [root@localhost ~]# systemctl daemon-reload [root@localhost ~]# exit logout Fedora release 18 (Spherical Cow) Kernel 3.6.10-8.fc18.armv7hl.tegra on an armv7l (ttyS0) localhost login: root (automatic login) ( note: works as expected, autologin ) [root@localhost ~]# reboot : Fedora release 18 (Spherical Cow) Kernel 3.6.10-8.fc18.armv7hl.tegra on an armv7l (ttyS0) localhost login: root (automatic login) ( note: works as expected, autologin. also, note that the change is persistent; survives reboot. ) -- So if I make the change only in /etc it does not seem to work. If I make the change only in /lib it works, but does not survive reboot. If I make the change in both, it works and survives reboot. I assume I am making some mistake in the process, but it is not obvious to me what I'm doing wrong. This is a headless system, so I only have a serial console for access. I do pass console=ttyS0,115200n8 on the kernel command line. I am running systemd-195-15.fc18. Please let me know what I'm missing. Thank you, d.marlin = Also see: http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions Question #4 on that list. Lennart ___ 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] How to get log_debug from logind?
Hello, I want to find out why inhibiting the power button doesn't work system wide. As first step, I want to compare debug messages, logged by logind. But unfortunately I don't manage to get them logged to somewhere. Enabling debug output for systemd seems to not enable debug output for logind. Currently, I use both, the kernel parameter systemd.log_level=debug and the setting LogLevel=debug in /etc/systemd/system.conf. Yours Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get log_debug from logind?
On Fri, 29.03.13 11:13, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote: Hello, I want to find out why inhibiting the power button doesn't work system wide. As first step, I want to compare debug messages, logged by logind. But unfortunately I don't manage to get them logged to somewhere. Enabling debug output for systemd seems to not enable debug output for logind. Currently, I use both, the kernel parameter systemd.log_level=debug and the setting LogLevel=debug in /etc/systemd/system.conf. That only enables debug logging for systemd itself, i.e. PID 1. To enable debug logging for logind, please copy /usr/lib/systemd/system/systemd-logind.service to /etc/systemd/system/systemd-logind.service and then edit it there. Add Environment=SYSTEMD_LOG_LEVEL=debug to the [Service] section. 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] cgtop --help: default depth is 3 not 2
use default depth from variable for --help
Signed-off-by: Maksim Melnikau maxpose...@gmail.com
---
src/cgtop/cgtop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index f80d51e..eebebf0 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -522,8 +522,8 @@ static void help(void) {
-d --delay=DELAYSpecify delay\n
-n --iterations=N Run for N iterations before exiting\n
-b --batch Run in batch mode, accepting no input\n
---depth=DEPTHMaximum traversal depth (default: 2)\n,
- program_invocation_short_name);
+--depth=DEPTHMaximum traversal depth (default: %d)\n,
+ program_invocation_short_name, arg_depth);
}
static void version(void) {
--
1.8.1.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH]: fix doc generation with python3.x in non utf-8 locales
On Tue, Mar 26, 2013 at 05:00:23PM -0600, Kelly Anderson wrote: Hi, Here is a patch that fixed documentation with python 3.x in non utf-8 locales. Specifically in my locale latin-1 is the default setting for output going to stdout, which causes it to fail. By writing directly to file we are able to set the locale to utf-8. This also eliminates a call to tree.dump which has been deprecated and was intended for debug use only. Hi, that's a good fix. Unfortunately the patch is garbled. Could you resend the patch so that it applies cleanly? Thanks, Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add test coverage and generate report with lcov
On Thu, Mar 28, 2013 at 02:54:06PM +0100, Thomas H.P. Andersen wrote: On Wed, Feb 13, 2013 at 4:16 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 05.02.13 23:56, Thomas H.P. Andersen (pho...@gmail.com) wrote: Adds test coverage and generates html reports. Configure with --enable-coverage and run make lcov. make lcov-upload exists but it currently just rsyncs the report to ~/coverage. Perhaps we can set up a host for it and automate it later? We could probably upload that to fdo... I have temporarily uploaded an example to look at here: http://people.gnome.org/~thomashpa/coverage/ Neat! Assuming that this is only useful for the core developers/buildbots I have not cluttered the code with workarounds for old versions for libtool, checks for non-gcc compilers, etc. I can add it you find it worth the extra lines in configure (or split it out to a m4 like gstreamer). Note that this requires lcov 1.10. (rawhide is still at 1.9). The older versions have bugs that we hit with systemd. 1.10 also has the --no-external option that avoids including things from /usr in the report. Hmm, given that this isn't even in rawhide, it might make sense to at least check for lcov version in autoconf, as only test? I forgot about this. lcov 1.10 is now in rawhide, but here is an updated patch with the version check anyway. It would be nice to start making use of this. I gave it a spin today: % make -C build lcov-run make: Entering directory `/home/zbyszek/systemd/build' lcov --directory . --zerocounters Deleting all .da files in . and subdirectories Done. make check make[1]: Entering directory `/home/zbyszek/systemd/build' make --no-print-directory check-recursive Making check in . make --no-print-directory test/sys make[4]: `test/sys' is up to date. make --no-print-directory check-TESTS PASS: test-job-type ... % make -C build lcov-report make: Entering directory `/home/zbyszek/systemd/build' mkdir lcov lcov --compat-libtool --base-directory . --directory . --no-external --capture --output-file lcov/lcov.info Capturing coverage data from . Found gcov version: 4.7.2 Scanning . for .gcda files ... geninfo: ERROR: no .gcda files found in .! make: *** [lcov-report] Error 255 make: Leaving directory `/home/zbyszek/systemd/build' No support for separate build dir? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shared root fs by default
On Thu, 28.03.13 16:47, Tvrtko Ursulin (tvrtko.ursu...@onelan.co.uk) wrote: Hi all, As a bit of a feedback, the change in systemd to mark root fs as recursively shared by default has the potential to bite hard anyone who builds chroot-ed environments on their system. When you build your chroot fs and then bind mount bits of the outside world into it, you are up for a nasty surprise when you tear those mounts down. You will then find your original mount points gone and system potentially in a seriously broken state. Well, not really. chroot()s and mount propagation are orthogonal, so we didn't really change much there. i.e. mounts you do from within chroots will also show up in the host (though shifted by the chroot's root dir of course), and if you drop them in the chroot they will disappear in the host too (also shifted by the chroot's root dir). So nothing really changed here. Depending what bits from the outside have been bind mounted into chroot and your filesystem setup you can lose /home, /dev, /proc, etc. You get the picture. :/ Nah, not true. You cannot umount the host's /home, /dev, /proc from inside the chroot, since you cannot even see them, and if you did bind mount them, then you will lose only the bind mounts, not the originals. The only place where things change is that if you bind mounted /home into the chroot's root dir's /home, and then create a another submount below that and assumed it wouldn't also affect the hosts's original /home. 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-inhibit --what=handle-power-key broken with systemd 198
On Wed, 27.03.13 23:17, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote: Just one more information: It seems like the inhibitors work if I'm on the same shell/virtual terminal where the inhibitor was created. Yes, that's correct. Key handling for this is per-VT. Generally on Linux only the X session in the fg will get the keypresses. If you switch away with from it, the new one in the bg will get it instead. logind will get active hence only if there's nobody on that specific VT who wants to take the events. 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. Correct. 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. Well, note that these specific inhibitors are about inhibiting key presses, not actions. i.e. the inhibitor for logind's suspend key (i.e. the handling of the key) is independent of the inhibiting for the suspend (i.e. the action code can ask for). See: http://www.freedesktop.org/wiki/Software/systemd/inhibit 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] cryptsetup: RequiresMountsFor if source is a file
On Wed, 27.03.13 17:52, Thomas Weißschuh (tho...@t-8ch.de) wrote: +if (startswith(u, /dev/)) Looks like we want is_device_path for this? +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 Oh, and could you add a full http URL path to the bug in the commit msg? otherwise it's not clear if that's fdobz or rhbz or any other. 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/2] cryptsetup: add RequiresMountsFor for passfile
On Wed, 27.03.13 17:52, Thomas Weißschuh (tho...@t-8ch.de) wrote:
Removed Before=local-fs.target because the respective mountpoint
already does this.
I don't grok this comment.
(Not saying the patch was bad, just not following the explanation
here. I mean, I do wonder myself why we are ordering
Before=local-fs.target here anyway, given that we have cryptsetup.target
anyway...)
---
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,
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] cryptsetup: RequiresMountsFor if source is a file
Le vendredi 29 mars 2013 à 16:07 +0100, Lennart Poettering a écrit : On Wed, 27.03.13 17:52, Thomas Weißschuh (tho...@t-8ch.de) wrote: +if (startswith(u, /dev/)) Looks like we want is_device_path for this? +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 Oh, and could you add a full http URL path to the bug in the commit msg? otherwise it's not clear if that's fdobz or rhbz or any other. You can use https://bugzilla.novell.com/show_bug.cgi?id=730496 for instance (I have similar patch I had on my list to upstream again, since I sent a early version before RequiresMountsFor was written but forgot). -- Frederic Crozat fcro...@suse.com SUSE ___ 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 16:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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? Not really. SELinux checks labels of objects against labels of processes really. uname(), gettimeofday(), getpid() and things like that aren't really affected, since they don't really do anything on any objects. I mean, doing assert_se() around them is already more than these syscalls deserve I guess, since realistically they cannot fail. And if they do fail, then there's something really really wrong with the security policy. Much much wronger than just a mislabelled file somewhere... In such a corner case I think it is fine to asserts. To me this is like checking for IO errors on stderr after logging something, or if we'd verify each time when we invoke snprintf() that the resuling string parses back to the same number with strtoull. But anyway, it's a bit of a bikeshedding thing about where you draw the line between this is clearly a programming error condition and this is clearly a runtime error condition... 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] persistent changes to the serial console
On Fri, 29.03.13 13:29, Andrey Borzenkov (arvidj...@gmail.com) wrote: serial-getty@.service is used only as template, and it looks like getty-generator always links to (/usr)/lib/systemd: from = strappend(SYSTEM_DATA_UNIT_PATH /, fservice); to = strjoin(arg_dest,/getty.target.wants/, tservice, NULL); It probably should use real unit path for fservice. Hmm, so actually even if you symlink like this, then /etc should override /lib, and the symlink destination path should only be used as last fallback. That's at least the theory, but there might be a bug somewhere... iirc there where problems with that, where aliases of autvt@ didn't get taken into account properly either... Something to look into definitely. Added to TODO list. 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 Fri, Mar 29, 2013 at 04:20:29PM +0100, Lennart Poettering wrote: Not really. SELinux checks labels of objects against labels of processes really. uname(), gettimeofday(), getpid() and things like that aren't really affected, since they don't really do anything on any objects. I mean, doing assert_se() around them is already more than these syscalls deserve I guess, since realistically they cannot fail. And if they do fail, then there's something really really wrong with the security policy. Much much wronger than just a mislabelled file somewhere... In such a corner case I think it is fine to asserts. To me this is like checking for IO errors on stderr after logging something, or if we'd verify each time when we invoke snprintf() that the resuling string parses back to the same number with strtoull. But anyway, it's a bit of a bikeshedding thing about where you draw the line between this is clearly a programming error condition and this is clearly a runtime error condition... All true. But asserts confuse people: look how some failing conditions in tests make people immediately think that something segfaulted. And in this case dumping core is completely useless, and a log error line tells just as much and is nicer to the user. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] snapshots not isolatable?
hi all, i wanna try out the systemd.snapshots for my suspend/hibernation configuration. but it seems the snapshots are not isolatable. systemdctl isolate foo.snapshot just throws an error Failed to issue method call: Operation refused, unit may not be isolated. and the outputs of systemctl show foo.snapshot: ... CanIsolate=no ... AllowIsolate=no ... according to man systemd.snapshot: ...Later on, the user may choose to return to the saved state via systemctl isolate what am i missing? btw, the version in my host is 198. best. ___ 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 Tue, 26.03.13 14:17, Bill Nottingham (nott...@redhat.com) wrote: 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? That's what I thought too at first. This feature request came from the anaconda folks who want to conditionalize a few units for s390, i.e. weird console support and things, and honestly, I can see why they prefer solving this like this rather than with a build time thing. I am not entirely sure whether this should check the kernel architecture however, or the userspace architecture. Lukas patch currently checks the kernel reported architecture, i.e. regardless whether you run a 32bit or 64bit userspace, as long as you run a 64bit kernel you will get a 64bit arch... So not sure what we want here. a) the userspace arch (which would probably effectively mean the arch systemd itself is compiled for, i.e. systemd's build arch) b) the kernelspace arch (i.e. uname()). c) both in some way? Ideas? 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] systemd-analyze: filter dot output
On Tue, 26.03.13 20:44, Łukasz Stelmach (stl...@poczta.fm) wrote: @@ -104,6 +104,12 @@ is passed the generated graph will show both ordering and requirement dependencies./para +paraOptional patterns may be given to limit the +output. With one pattern all lines for which at least +one of the unit names matches the pattern shall be +printed. With two patterns, the lines for which the +units match patterns respectively./para Hmm, not sure I like it this way too much. Somehow I would have assumed that this works like it does on the shell, i.e. you can name as many globs as you wish, and they would be treated the same way. Now, if we want to expose what your patch currently does I'd prefer if we did this via cmdline switches. i.e. --pattern=*.target, --from-pattern=*.service, or --to-pattern=*.waldo, Also, if this is parsed out of the command line it's fine to place this in global vars whose name is prefixed with arg_ or so... 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] condition: add option ConditionArchitecture
Ideas? Just provide ConditionExec=. People should build their own checkers. You still can implement several as stand-alone executables maybe.. ___ 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 Fri 29 Mar 2013 01:00:59 PM CLST, Oleksii Shevchuk wrote: Ideas? Just provide ConditionExec=. People should build their own checkers. You still can implement several as stand-alone executables maybe.. I dont think so, If there are conditions implemented there should be implemented in systemd itself, not in separate executables, forking slows down everything and trust me, developers will abuse them. ___ 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 Fri, 29.03.13 18:00, Oleksii Shevchuk (shevc...@iit.kharkov.ua) wrote: Ideas? Just provide ConditionExec=. People should build their own checkers. You still can implement several as stand-alone executables maybe.. Well, we can discuss extending ExecStartPre= so that you can configure that certain/all retvals have a failed-condition-like effect, but I am pretty sure we shouldn't involve the process forking state machine in the condition logic. 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] snapshots not isolatable?
On Fri, 29.03.13 23:42, Sun Bing (subi.the.dream.wal...@gmail.com) wrote: hi all, i wanna try out the systemd.snapshots for my suspend/hibernation configuration. but it seems the snapshots are not isolatable. systemdctl isolate foo.snapshot just throws an error Failed to issue method call: Operation refused, unit may not be isolated. and the outputs of systemctl show foo.snapshot: ... CanIsolate=no ... AllowIsolate=no ... according to man systemd.snapshot: ...Later on, the user may choose to return to the saved state via systemctl isolate what am i missing? btw, the version in my host is 198. Ah, that looks like a mistake, they really should be isolatable. AllowIsolate= flag is a relatively recent addition, and we really should set it implicitly for all snapshots. 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] Optimizing systemd binaries for small deployments
On Wed, 27.03.13 11:49, Tino Breddin (tbred...@tpip.net) 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. Well, a few notes: There are tons of configure options for optional featutres, make sure you enable exactly what you need, and not more. Also, we could make even more stuff optional, if it's sufficiently peripheral. Also note that we ship a couple of databases with generic device info, such as hwdb, keymaps and the rules set. They tend to be quite small, but if dunno, you could minimize this too. Probably not worth it though. We currently compile a lot of code into each binary, and rely on gc-sections to clean this up for us. If minimal disk footprint is key, then you could split this shared code into a private .so or so. Then, there's a ton of stuff we more or less replaced with systemd, so you can drop cron, pm-utils, acpid, at, rsyslog, inetd, ckit, initscripts, watched, cgrulesd, and more, because you don't really need it 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] condition: add option ConditionArchitecture
Well, we can discuss extending ExecStartPre= ExecStartPre= is not about that anyway, because it can be used only in .service units. but I am pretty sure we shouldn't involve the process forking state machine in the condition logic. I don't like it too. But can we have other alternatives? Some way ( or policy ) for extending without systemd patching should be provided, maybe. I think about using .target as conditions, like on-battery.target, network@XXX.target, arch@XXX.target, etc with some other way to push them on. Personally I use this approach now (for example, I don't use ConditionACPower, but battery.target and low-battery.target, which are pushed by third-party daemon). ___ 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 3:49 AM, Tino Breddin tbred...@tpip.net wrote: 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. Out of curiosity, but where does the consumed space actually sink into? Could you post perhaps the equivalend of something like du or list the top 20 largest items? Auke ___ 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 Tue, Mar 26, 2013 at 04:07:47PM -0300, Cristian Rodríguez wrote: 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.. The reason explained on IRC was to automatically start sshd in installer on s390. Currently it is started based on sshd in kernel commandline, but on s390 it must be started always. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get log_debug from logind?
2013/3/29 Lennart Poettering lenn...@poettering.net: To enable debug logging for logind, please copy /usr/lib/systemd/system/systemd-logind.service to /etc/systemd/system/systemd-logind.service and then edit it there. Add Environment=SYSTEMD_LOG_LEVEL=debug to the [Service] section. Wouldn't this be a perfect use of the .d directories? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get log_debug from logind?
On Fri, Mar 29, 2013 at 9:12 PM, Michael Biebl mbi...@gmail.com wrote: 2013/3/29 Lennart Poettering lenn...@poettering.net: To enable debug logging for logind, please copy /usr/lib/systemd/system/systemd-logind.service to /etc/systemd/system/systemd-logind.service and then edit it there. Add Environment=SYSTEMD_LOG_LEVEL=debug to the [Service] section. Wouldn't this be a perfect use of the .d directories? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
Thanks a lot guys, this clears up quite a bit of confusion :) BR, Awais From: systemd-devel-bounces+awais_belal=mentor@lists.freedesktop.org [systemd-devel-bounces+awais_belal=mentor@lists.freedesktop.org] on behalf of Lennart Poettering [lenn...@poettering.net] Sent: Friday, March 29, 2013 7:38 AM To: Frederic Crozat Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] A newbie question regarding ordering cycles On Thu, 28.03.13 13:47, Frederic Crozat (fcro...@suse.com) wrote: Le jeudi 28 mars 2013 à 12:22 +, Belal, Awais a écrit : Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: systemd[1]: Found ordering cycle on basic.target/start systemd[1]: Walked on cycle path to sockets.target/start systemd[1]: Walked on cycle path to dbus.socket/start systemd[1]: Walked on cycle path to sysinit.target/start systemd[1]: Walked on cycle path to run-postinsts.service/start systemd[1]: Walked on cycle path to basic.target/start systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start Based on experience, the problem usually lays in the .service listed in the cycle, in your case run-postinsts.service. It has probably incorrect (or no) LSB dependencies. Well, newer systemd versions do not allow early-boot SysV scripts anyway. There never was a standard way to do it. SysV scripts are only supported for normal services. systemd could be improved to not drop dbus.socket in its ordering cycle break algorithm (there were some discussions some time ago on IRC) but it hasn't happened yet. Well, I am not going to hardcode that dbus.socket is always the last one to be removed. There are certainly some changes possible (for example, kill the unit with the newest file modification date, as that is likely to be the most recently added that is borked), but tha's all black magic... I mean, this is generally not an end-user problem, more one that system integrators might run into, i.e. the folks who actually fiddle with early boot, and who write non-trivial unit files, so maybe trying to magically fix a broken situation isn't really worth it, but rather improve the debugging... 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 mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Optimizing systemd binaries for small deployments
Hi, - Original Message - On Wed, 27.03.13 11:49, Tino Breddin (tbred...@tpip.net) 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. Well, a few notes: There are tons of configure options for optional featutres, make sure you enable exactly what you need, and not more. Also, we could make even more stuff optional, if it's sufficiently peripheral. We will go into more details here later, lets say in the next 4-6 week, currently we have tight schedule for a project which also have the 4MB flash limit.. so not much time to spend right now... Also note that we ship a couple of databases with generic device info, such as hwdb, keymaps and the rules set. They tend to be quite small, but if dunno, you could minimize this too. Probably not worth it though. The DBs we already have on our radar for optimisation We currently compile a lot of code into each binary, and rely on gc-sections to clean this up for us. If minimal disk footprint is key, then you could split this shared code into a private .so or so. May thats an option to consider ad we would like to check this and discuss the options here. Then, there's a ton of stuff we more or less replaced with systemd, so you can drop cron, pm-utils, acpid, at, rsyslog, inetd, ckit, initscripts, watched, cgrulesd, and more, because you don't really need it anymore... You are exactly right if you have classic desktop (or server) distributions like Fedora, Redhat, arch etc. as focus. If you come from the embedded direction i.e. OpenWRT, you don't have all this stuff anyway, so not much space gain here. I agree with the savings on init scripts, but here again, a typical embedded Linux system has about 20-30 Services and not hundreds shipping the own config files. One could and will argue why Systemd at all in embedded Systems, but we think there ist still a lot to gain by using systemd, but lets keep they eyes open when developing systemd further. I remember the blame commands written in python and a huge bunch of dependencies attached, luckily someone was coming along to rewrite the thing. Holher Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann email: h...@travelping.com mobil: +49-171-5594745 ___ 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
Hi Auke, whether anybody has pointers we should follow or even experience using systemd for bare minimum images. Out of curiosity, but where does the consumed space actually sink into? Could you post perhaps the equivalend of something like du or list the top 20 largest items? There is a short analysis, which goes not in the level of detail you asking for, but a starting point: https://github.com/travelping/tpcore/wiki/tpcore_rootfs We could add a list with most hungry components later next week... Holger Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann email: h...@travelping.com mobil: +49-171-5594745 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] cryptsetup: RequiresMountsFor if source is a file
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=730496 https://bugs.freedesktop.org/show_bug.cgi?id=60821 --- TODO | 1 - src/cryptsetup/cryptsetup-generator.c | 22 -- 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/TODO b/TODO index 10a2b8c..5206730 100644 --- a/TODO +++ b/TODO @@ -357,7 +357,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..a8c856f 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 (is_device_path(u)) +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 v2 2/2] cryptsetup: add RequiresMountsFor for keyfile
This ensures that the keyfile is available during the opening of the encrypted
device.
Also dropped the explicit ordering Before=local-fs.target, as the containers
are ordered implicitly by their content.
---
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 a8c856f..6b9bc55 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 (is_device_path(u))
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] [PATCH]: fix doc generation with python3.x in non utf-8 locales
On Fri, Mar 29, 2013 at 03:25:23PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 26, 2013 at 05:00:23PM -0600, Kelly Anderson wrote: Hi, Here is a patch that fixed documentation with python 3.x in non utf-8 locales. Specifically in my locale latin-1 is the default setting for output going to stdout, which causes it to fail. By writing directly to file we are able to set the locale to utf-8. This also eliminates a call to tree.dump which has been deprecated and was intended for debug use only. Hi, that's a good fix. Unfortunately the patch is garbled. Could you resend the patch so that it applies cleanly? Hi, never mind. I needed to change this code anyways, so I pulled incorporated your patch in my changes, and applied the rest by hand. I'll push it in a moment. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
