[systemd-devel] [PATCH] Recognize discard option in /etc/crypttab
Hi,
forwarding this patch we received in the Debian bugtracker.
systemd-cryptsetup recognizes option 'allow-discards' in /etc/crypttab
to enable TRIM passthrough to underlying encrypted device. In Debian
this option was changed to 'discard' to avoid hyphen in option name
(see: #648868 and `man crypttab`).
The attached patch makes “discard” a synonym for “allow-discards” in
/etc/crypttab. Please merge it.
--
Best regards,
Michael
>From 4c7b781f336e71f4e8db82889d79132e04fd3cec Mon Sep 17 00:00:00 2001
From: Ondrej Balaz
Date: Fri, 9 Aug 2013 17:35:18 +0200
Subject: [PATCH] Recognize discard option in /etc/crypttab.
Signed-off-by: Ondrej Balaz
---
src/cryptsetup/cryptsetup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 3a2cfe4..ba0fdbc 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -129,7 +129,7 @@ static int parse_one_option(const char *option) {
opt_readonly = true;
else if (streq(option, "verify"))
opt_verify = true;
-else if (streq(option, "allow-discards"))
+else if (streq(option, "allow-discards") || streq(option, "discard"))
opt_discards = true;
else if (streq(option, "luks"))
opt_type = CRYPT_LUKS1;
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd.unit(5): clarify the Description= contents
Hi, Lennart, as discussed during DebConf earlier today, this patch clarifies what should go into the Description= field. Please merge it :). -- Best regards, Michael>From fef7d55294b3b407eb6513a31f4087ff84a1f20e Mon Sep 17 00:00:00 2001 From: Michael Stapelberg Date: Mon, 12 Aug 2013 21:56:52 +0200 Subject: [PATCH] systemd.unit(5): clarify the Description= contents --- man/systemd.unit.xml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index c6325d3..1714157 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -359,7 +359,15 @@ describing the unit. This is intended for use in UIs to show descriptive information along with the unit -name. +name. The description should contain a name +that means something to the end user. +Apache2 Web Server is a good +example. Bad examples are +high-performance light-weight HTTP +server (too generic) or +Apache2 (too specific and +meaningless for people who do not know +Apache). -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] Integrating an early-boot service in a blocking way?
Hi, the debian-live people have approached me and want to experiment with systemd. One of the things they need to have is running a service called live-config.service, but the issue is that it needs to run in early boot, even before udev. We thought of maybe creating a custom target, but it would need to run before basic.target and I don’t see a good way of doing that. Do you have any ideas on how to solve this (and making live-config work in a different way does not count :))? Thanks! -- Best regards, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]
Hi Martin, Martin Pitt writes: > Martin Pitt [2013-11-14 17:53 +0100]: >> So option 1 is to update the patch to not rely on "uid", but instead >> always get it from PAM. > > I went through all instances of using the uid, username, or pw, and I > cannot find any place in the PAM module where we would actually want > the originating user name, so I retract this. > >> Option 2 is to never read it from loginuid, as that's indeed not >> what one should be concerned about in a PAM module. >> Attached patch is doing option 2. > > ... and hence I'm convinced that this is the right thing to do. Thanks for your patch. This is a rather pressing issue for us (it breaks GDM logins in some cases), and we’d like to fix it by cherry-picking a patch that was merged upstream. Therefore, I’d like to ask people with a commit bit (Colin?) to please have another look and merge the patch unless something is still wrong with it :). Thanks! -- Best regards, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] [PATCH] Follow symlinks in /lib
Hi,
See http://bugs.debian.org/719695 for context.
This patch is not complete yet; at least masking/unmasking does not work
yet. Maybe I missed other verbs, too :).
Any feedback appreciated.
--
Best regards,
Michael
diff --git i/src/shared/install.c w/src/shared/install.c
index f57b94d..8f9596b 100644
--- i/src/shared/install.c
+++ w/src/shared/install.c
@@ -1023,6 +1023,8 @@ static int unit_file_load(
(int) strv_length(info->required_by);
}
+#define FOLLOW_MAX 8
+
static int unit_file_search(
InstallContext *c,
InstallInfo *info,
@@ -1053,11 +1055,44 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
+int cnt = 0;
+for (;;) {
+if (cnt++ >= FOLLOW_MAX)
+return -ELOOP;
+
+r = unit_file_load(c, info, path, allow_symlink);
+
+/* symlinks are always allowed for units in {/usr,}/lib/systemd so that
+ * one can alias units without using Alias= (the downside of Alias= is
+ * that the alias only exists when the unit is enabled). */
+if (r >= 0)
+break;
+
+if (r != -ELOOP)
+break;
+
+if (allow_symlink)
+break;
+
+if (!path_startswith(path, "/lib/systemd") &&
+!path_startswith(path, "/usr/lib/systemd"))
+break;
+
+char *target;
+r = readlink_and_make_absolute(path, &target);
+if (r < 0)
+return r;
+free(path);
+path = target;
+}
+
r = unit_file_load(c, info, path, allow_symlink);
-if (r >= 0)
+if (r >= 0) {
info->path = path;
-else {
+free(info->name);
+info->name = strdup(path_get_file_name(path));
+} else {
if (r == -ENOENT && unit_name_is_instance(info->name)) {
/* Unit file doesn't exist, however instance enablement was requested.
* We will check if it is possible to load template unit file. */
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Please proof-read: systemd’s dependencies and installation footprint
Hi, I intend to publish a document about systemd’s dependencies and installation footprint (along with a blog article) to a wider scope soon and would like to make sure I don’t publish anything which is plain wrong. Therefore, I’d be thankful if you could proofread http://t.zekjur.net/dependencies.html and let me know if you see anything wrong there. Thanks. -- Best regards, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please proof-read: systemd’s dependencies and installation footprint
Hi Zbigniew, Thanks for your answer. Zbigniew Jędrzejewski-Szmek writes: > "The binaries systemctl (299 KiB), journalctl (187 KiB) and loginctl > (91 KiB) are the main binary to use for respective part of system" > → it's a bit unclear what "to use for" means in this context. Clarified. > "pixel-perfect" → not true for a long time, since now we do coloring > and such, maybe "character-perfect" would be more adequate Fixed. > "journal log" → journal Fixed. > "there is no cyclic dependency" → actually there's a *compile time* > cyclic dependency, so it might be good to add an adjective that makes > it clear that you mean startup order dependency Fixed. > OK, you start talking about systemd, and than about libudev, and > serial ports, and it all becomes really muddy. Maybe it would be > better to first get systemd-udevd out of the way, especially that > udevd is used by everybody, so it is always loaded anyway, so the cost > of libudev.so.1 in PID 1 is nearly nil. udevd does not use libudev.so AFAICT. It does not show up in ldd /lib/systemd/systemd-udevd > "To be honest, I don’t quite understand why this code is not inlined > into systemd. " → why should it be? It is rather worth explaining why > there's so much stuff in systemd. There's a reason why other code *is* > inlined into systemd, when it *could* be provided as a shared library. > The stuff that is part of static libsystemd-shared during compilation > is inlined and not shared between all the systemd components as a > shared library because it would have to be installed in /usr/lib and > other people could link against it. But we don't want to provide any > promises regarding the stability of the internal library API, so we > take the (small) cost of static linking over the hassles that come > with having a private library in a public place. There's no such > consideration for libsystemd-daemon, because it has a public API that > is stable. Fixed. > "helper utilities" → why are there crosses and check marks, what's the > difference? ✘ means no, ✔ means yes. In the particular case it means whether the specific binary depends on e.g. udev or not. I thought that’s obvious, but I’ve clarified it. > "systemd-shutdown PID 1 will be replaced with this binary" → when? > Maybe mention that systemd-shutdown is statically linked (I know it > can be inferred from the text, but being explicit might be better). Clarified. > "Debugging, interactive tools, shell helpers ... systemd-readahead": > I would say that systemd-readahead doesn't really fall into any > of those categories. Indeed. There’s no better category, though, so I’ll just leave it as-is. > "systemd-nspawn ... for debugging" → not really, since it has gained > the ability to socket activate containers, people use it also for > production (e.g. compilation chroots, web server environenments, etc). Added. > "systemd-detect-virt ... Depending on your environment, you might not > want to start certain services — for example udev does not make sense > in an lxc container" → this is a bit misleading, because services > would be started or not using systemd's built-in ConditionVirtualization, > and this binary is for other uses. For what uses specifically? > "so that the only thing journald does is passing information to syslog" > → it also stores stuff temporarily in tmpfs. Clarified. > What I'm missing from all this, is the answer to the question set > forth in the title: what is the *total* footprint of running a normal > systemd installation (I'd be happy to see some good statistics and > analysis!). PID 1 is probably the heaviest, but journald also > contributes, and it would be nice to see the whole picture. I’m working on additional measurements which outline the memory requirements for an entire sysvinit boot and systemd boot. I’ll update you once that is done. -- Best regards, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please proof-read: systemd’s dependencies and installation footprint
Hi Lennart, Thanks for your feedback. Lennart Poettering writes: > If Debian is interested in making systemd minimal, they could split out > logind and loginctl, since that is something you need that only for > systems where users or admins log into. For embedded devices it's > totally optional. Noted. > It might be interesting to mention which of the libraries systemd > depends on are actually in Debian's "essential" and "required" > priorities, and hence are nothing that systemd would pull in but > something that one cannot install Debian without anyway. For example, > libpam, libselinux, libattr all are afair. I touched on this in the accompanying blog post, see below: For the record, the dependency list and first blog post of the series are published by now, find them at: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html http://people.debian.org/~stapelberg/docs/systemd-dependencies.html > systemd-shutdown is not statically linked. Fixed. > The readahead, bootchart, nspawn, activate, analyze, cgls/gtop stuff is > something debian could still split off, btw, if they really wanted to > (not that I would recommend that, but well...). Noted. -- Best regards, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
