Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) : On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. I have the impression that the current scheme already does everything what you need, no? I mean, if you list the template unit file in the preset file, and we enumerate such a template unit file, we end up enabling it's DefaultInstance=, which should be enough for you? Or am I missing something? For preset-all: - I may want to enable an instance different from the default instance. For example wpa_supplicant@.service does not have a default instance. (I could change the file but in this case I might as well write directly a non template service file) - I may want to enable different instances of the same template file. - disable * does not disable instanciated templates (except the ones with a default instance). But as you said, I do not see an easy way to do that the way preset-all works. Damien -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
No runtime kdbus but --enable-kdbus configuration at build time Den 08/10/2014 17.11 skrev Lennart Poettering lenn...@poettering.net: On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Is this with kdbus enabled (in systemd, kernel, runtime)? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Best Regards, Tobias On 08.10.2014 14:13, Harald Hoyer wrote: On 24.09.2014 22:08, Tobias Hunger wrote: From f3a193de94959875cd1d83f941ed8fc8275c82eb Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Wed, 24 Sep 2014 21:57:00 +0200 Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on kernel command line This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. doh.. didn't sent to mailing list... resent to list only.. sorry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 09:37, Tobias Hunger wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com mailto:harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Yes :) Sounds legit. Lennart, approved from my side (didn't look at the code, though). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logind: mount per-user tmpfs with 'smackfsroot=*' for smack enabled systems
---
src/login/logind-user.c | 8 +++-
units/systemd-logind.service.in | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index d48eca4..3847496 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -37,6 +37,7 @@
#include conf-parser.h
#include clean-ipc.h
#include logind-user.h
+#include smack-util.h
User* user_new(Manager *m, uid_t uid, gid_t gid, const char *name) {
User *u;
@@ -325,7 +326,12 @@ static int user_mkdir_runtime_path(User *u) {
mkdir(p, 0700);
-if (asprintf(t, mode=0700,uid= UID_FMT ,gid= GID_FMT
,size=%zu, u-uid, u-gid, u-manager-runtime_dir_size) 0) {
+if (use_smack())
+r = asprintf(t, mode=0700,smackfsroot=*,uid=
UID_FMT ,gid= GID_FMT ,size=%zu, u-uid, u-gid,
u-manager-runtime_dir_size);
+else
+r = asprintf(t, mode=0700,uid= UID_FMT ,gid=
GID_FMT ,size=%zu, u-uid, u-gid, u-manager-runtime_dir_size);
+
+if (r 0) {
r = log_oom();
goto fail;
}
diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in
index c6cbd1c..f087e99 100644
--- a/units/systemd-logind.service.in
+++ b/units/systemd-logind.service.in
@@ -23,7 +23,7 @@ ExecStart=@rootlibexecdir@/systemd-logind
Restart=always
RestartSec=0
BusName=org.freedesktop.login1
-CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL
CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
+CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN
CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
WatchdogSec=1min
# Increase the default a bit in order to allow many simultaneous
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
On Thu, 09.10.14 07:21, Jan Synacek (jsyna...@redhat.com) wrote: A related thing: there's a mapping bus-error - errno implemented, but it only works for the errors defined in the library itself. It would be nice to extend this mapping to the user defined errors, e.g. in core/. Would you be amenable to adding a mechianism to register additional mappings like bus-error-mapping.gperf so that they are used by the library? Maybe have internal versions of the conversion calls that allow passing in an additional table? That is not as convenient. E.g. sd_bus_error_set internally calls bus_error_name_to_errno. Currently, this always returns EIO for errors unknown to the library, and then the caller does it own lookup (e.g. looking at transaction_add_job_and_dependencies()). What precisely are you proposing instead? What about extending usage of errno with systemd specific errors? Something like EUNITMASKED or Eanything systemd specific? Plus, implementing extended version of strerror(), which would use the standard stderror() for the standard errno? Well, using errno-style errors is certainly handy, but let's face it, it's not particularly descriptive. Before attempting to extending it we should probably look at other options, such as adopting sd_bus_error at more places, which allows more flexible identifiers as well as descriptive strings. Also, we return these errnos in many of our public APIs. We really should never return something there that cannot be made sense of externally, since people might (and should be able to) escalate the errors unmodified up the chain, where the immediate systemd context is lost or unknown. (Also, just think what would happen if multiple libraries would extend errno that way! how confusing would that get). So, my suggestion is to either accept the limited vocabulary of errno for this case (which I don't think is such a loss here), or to go for sd_bus_error, but some entirely new concept sounds less than ideal. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
On Thu, 09.10.14 10:00, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Wed 08 Oct 2014 at 20:48:55 (+0200) : SyslogIdentifier= should do it. It works, thanks! See systemd.exec(5) for details. When I was looking for something like that in the doc, I was confused by this passage: This option is only useful when StandardOutput= or StandardError= are set to syslog or kmsg., but it apparently actually works with StandardOutput=journal. Oh, indeed. That's a bug in the man page. Fixed now. Thanks for the pointer! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: mount per-user tmpfs with 'smackfsroot=*' for smack enabled systems
On Thu, 09.10.14 11:02, Lukasz Skalski (l.skal...@samsung.com) wrote:
Applied! Thanks!
---
src/login/logind-user.c | 8 +++-
units/systemd-logind.service.in | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index d48eca4..3847496 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -37,6 +37,7 @@
#include conf-parser.h
#include clean-ipc.h
#include logind-user.h
+#include smack-util.h
User* user_new(Manager *m, uid_t uid, gid_t gid, const char *name) {
User *u;
@@ -325,7 +326,12 @@ static int user_mkdir_runtime_path(User *u) {
mkdir(p, 0700);
-if (asprintf(t, mode=0700,uid= UID_FMT ,gid= GID_FMT
,size=%zu, u-uid, u-gid, u-manager-runtime_dir_size) 0) {
+if (use_smack())
+r = asprintf(t, mode=0700,smackfsroot=*,uid=
UID_FMT ,gid= GID_FMT ,size=%zu, u-uid, u-gid,
u-manager-runtime_dir_size);
+else
+r = asprintf(t, mode=0700,uid= UID_FMT ,gid=
GID_FMT ,size=%zu, u-uid, u-gid, u-manager-runtime_dir_size);
+
+if (r 0) {
r = log_oom();
goto fail;
}
diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in
index c6cbd1c..f087e99 100644
--- a/units/systemd-logind.service.in
+++ b/units/systemd-logind.service.in
@@ -23,7 +23,7 @@ ExecStart=@rootlibexecdir@/systemd-logind
Restart=always
RestartSec=0
BusName=org.freedesktop.login1
-CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL
CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
+CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL
CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER
CAP_SYS_TTY_CONFIG
WatchdogSec=1min
# Increase the default a bit in order to allow many simultaneous
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] booting A/B rootfs
On Thu, 09.10.14 06:13, Darko Luketic (i...@icod.de) wrote: Hi, I have limited knowledge of the boot process. I'm wondering if the following is possible with systemd. Imagine you have 2 rootfs partitions. You build a new rootfs on a security update or when a new version of a listed package that has dependencies is released and extract this on either A or B partition (A if B is the current rootfs, B if A is the current rootfs) The idea is, with systemd you can isolate targets. I assume you could shutdown all services so that nothing but systemd is running. Then unmount the current rootfs and mount the new rootfs and boot to default target. All without needing to poweroff or physically reboot the system. Only if you install a new kernel a real reboot would be required. Would this be possible with systemd in its current state? This has been requested before, but is currently not nicely supported, but I am open to adding some support for this. Note though that you probably need to do more than just stopping all services, you need to at least flush out /run, too, plus some other things like /dev/shm, or the sysvipc objects. The part of this that I think might be suitable for direct integration into systemd is the above plus maybe high-level support in systemctl to get a new verb for rebooting this way. The swapping of the partitions though probably something to do externally, integrated in the same way as the current dracut/initrd shutdown logic is integrated, which disassembles the root disk: after systemd did everything it could do it transitions back into the initrd which then does what it needs to do. In fact, you probably could use the initrd logic for this already, just place a script /run/initramfs/shutdown, do the flushing of /run+sysv manually, and then simply reexec systemd again. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bash-completion: fix systemctl isolate
I didn't dare fix this in zsh completion (not sure if it's required, though, so I didn't even remove the TODO entry that mentions this fix is required). Jan Synacek (1): bash-completion: fix systemctl isolate shell-completion/bash/systemctl.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate
On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote: I didn't dare fix this in zsh completion (not sure if it's required, though, so I didn't even remove the TODO entry that mentions this fix is required). Jan Synacek (1): bash-completion: fix systemctl isolate shell-completion/bash/systemctl.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Hmm, the actual patch is missing? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats
On Thu, 09.10.14 09:58, Daniel P. Berrange (berra...@redhat.com) wrote:
Hmm, also, we already have a really bad formatter in place for the
journal catalog files (which only replaces @foo@ by the value of field
foo). We should probably use the same code for this new journalctl
formatter and the catalog code. In fact the catalog formatter could
really use some improvement...
Ok, I didn't know about the catalog files until now, so I'll
investigate that and see what I can do about unifying the code
for these two options.
That would be fantastic!
Do you consider the catalog file format to be part of the stable
ABI ? ie, do we need to preserve support for @foo@ if we took
the %s{FOO} approach ?
I figure the @xyz@ syntax needs to stay. I mean, I doubt this is
widely used yet (we never really advertised it that much), but then
again it has been in place for a while now. So I figure we should
change the catalog files we ship to the new syntax, but still
alternatively support the old syntax, but only in the catalog files...
Maybe something like this:
journalctl -O %t %s{CODE_FILE}:%s{CODE_LINE}
%d{_SOURCE_REALTIME_TIMESTAMP}
or something like that, where %t would simply map to the timestamp,
and %s{} maps to a field name, and %d{} the same, but reformats the
field as timestamp, assuming it is a UNIX timestamp formatted as
number...
Or something like that...
Yep, that would work for me. I'll cook up another patch to demonstrate
that approach along with catalog support.
Thanks! That'd be lovely!
I'm about to be travelling for KVM Forum / LinuxCon so probably won't get
a chance to send an updated patch for a week or two.
See you in Düsseldorf!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate
Lennart Poettering lenn...@poettering.net writes: On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote: I didn't dare fix this in zsh completion (not sure if it's required, though, so I didn't even remove the TODO entry that mentions this fix is required). Jan Synacek (1): bash-completion: fix systemctl isolate shell-completion/bash/systemctl.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Hmm, the actual patch is missing? Nope, I can see it in my mail and it the systemd-devel archives as well. This is just a cover letter I used to explain additional stuff. -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] A schedule for the systemd hackfest next week?
Heya! Next week we'll have the next systemd hackfest, at the Linux Plumbers Conference 2014, in Düsseldorf Germany. Please consider signing up here if you haven't done so: https://plus.google.com/u/0/events/c9d1h0i18rt47v42bqku24u6f38 Given that we have a room for two days in parallel to most of LPC, and a lot of things to discuss and hack on, I figured it might be useful to have a rough schedule so that people can drop in and leave depending on the topic we will focus on. I put an initial attempt for such a schedule up here: https://docs.google.com/document/d/1eKbEbVtJf5PfWpMMlEwqQrjdhq9-rrRo3TSP4eKGBZg/pub Any suggestions for changes in the schedule? Other relevant topics that should be added? Feedback very welcome! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate
On Thu, 09.10.14 12:55, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote: I didn't dare fix this in zsh completion (not sure if it's required, though, so I didn't even remove the TODO entry that mentions this fix is required). Jan Synacek (1): bash-completion: fix systemctl isolate shell-completion/bash/systemctl.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Hmm, the actual patch is missing? Nope, I can see it in my mail and it the systemd-devel archives as well. This is just a cover letter I used to explain additional stuff. Hmm, there's something wrong with mail delivery on fdo as it seems. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 10/08/2014 11:41 PM, Lennart Poettering wrote: TODO list to allow services also when they have no ExecStart= but with an ExecStop=, but this has not been implemented yet. What's the usecase for this behaviour? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library
On 10/03/2014 12:21 AM, Lennart Poettering wrote:
On Fri, 19.09.14 13:27, Susant Sahani (sus...@redhat.com) wrote:
CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
src/socket-proxy/socket-proxyd.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..7b0714d 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,11 @@ static int connection_create_pipes(Connection *c, int
buffer[2], size_t *sz) {
return -errno;
}
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+if (r 0) {
+log_error(Failed to set pipe buffer size: %m);
+return -errno;
+}
If this is about making coverity shut up: doesn't coverity undestand a
syntax like the following?
(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
I.e. by explicitly casting the result of fcntl into void, coverity
should really understand that we don't really care about the result.
Sorry for the late reply. Casting with void indeed works. Tested with
splint.
Thanks for the tip.
Would be happy to take a patch for that (if coverity groks this...)
Re-sending.
Lennart
Susant
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library
CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
src/socket-proxy/socket-proxyd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..3041903 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int
buffer[2], size_t *sz) {
return -errno;
}
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
r = fcntl(buffer[0], F_GETPIPE_SZ);
if (r 0) {
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Added test for unit file state returned by unit_file_get_state and unit_file_get_list. Made test-enabled units more basic, removing superfluous fields. Cleaned up test p
It looks like newlines at the end of the new files are inconsistent (No newline at end of file). Other than that +1. It's great to add tests, have them pass on master, optimize master (the next patch), and then still have them pass. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 16:08, Lennart Poettering wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart Just be careful choosing the prefix. It must not be the name of a kernel module, otherwise this kernel module is presented with all those options, which might freak out that module. I accidentally chose rd. not knowing that rd is a module alias for the brd kernel module. Just check with a recent kernel: # modinfo prefix I have the feeling, we should somehow register a namespace for userspace on the kernel command line or have global list. :-/ I just don't want to end with something like org.freedesktop.systemd.log_level=... :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 10/08/2014 11:41 PM, Lennart Poettering wrote: TODO list to allow services also when they have no ExecStart= but with an ExecStop=, but this has not been implemented yet. What's the usecase for this behaviour? Precisely cases like the one described earlier in this thread: when you want to run something only at shutdown, properly ordered against other units that are also shut down. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 09.10.2014 16:24, Harald Hoyer wrote: On 09.10.2014 16:08, Lennart Poettering wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart Just be careful choosing the prefix. It must not be the name of a kernel module, otherwise this kernel module is presented with all those options, which might freak out that module. I accidentally chose rd. not knowing that rd is a module alias for the brd kernel module. Just check with a recent kernel: # modinfo prefix Oh, that might not work with builtin modules and not shipped modules. So you have to manually check the kernel source code :-/ I have the feeling, we should somehow register a namespace for userspace on the kernel command line or have global list. :-/ I just don't want to end with something like org.freedesktop.systemd.log_level=... :-) ___ 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] [feature request] allow instances in file.preset
On Thu, 09.10.14 11:42, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) : On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. This feels wrong. The preset files are actually globs, not full file names. They are not really suitable as a list of filenames, but only as something to match file names against... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
I will update the patch as soon as I get home :-) Best Regards, Tobias PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) On Oct 9, 2014 4:08 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Oct 8, 2014 2:15 PM, Harald Hoyer harald.ho...@gmail.com wrote: What is the rationale of this patch? Supporting systems without /etc/fstab in the root device? Overriding the /etc/fstab settings? In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is reached, initrd-parse-etc.service is executed, which retriggers the fstab-generator and reads fstab from the real root and generates units for /usr. Hello Harald, The use case is exactly the one Lennart described in his blog about deploying Linux in the future. My setup now looks like this: I got a Btrfs partition for my Linux installations. This partition has a subvol root:somename:someid:x86_64 containing a Linux installation minus /use. Then I have several versions of /use for that distribution in more subvolumes named usr:someid:x86_64:version (all with different versions, basically getting incremented whenever a new set of packages gets installed). The idea is to now be able to write bootloader entries for all versions the somename-installation. For that the initrd needs to know which /usr to mount on top of the root partition. I can not use the fstab from the root drive here, because that would always point to the same version of /use, preventing me to roll back/forward when something breaks during an upgrade. What I could do instead is to put the information about which subvol to mount at /use into the initrd. But I actually think the way of passing this into initrd in the same way as the rootfs is more consistent and it also saves me from having a new initrd in /boot when libreoffice gets updated. That *might* be necessary when using secure boot, but only then. Does this explain my motivation for this patch sufficiently? Hmm, so I think this should be merged, but I'd like to ask for one more change. We really want to avoid inventing new non-namespaced kernel command line options, that's really something we should leave to the kernel guys... Hence, I'd propose using mount.usr=, mount.usrflags= and mount.usrfstype=... Or maybe fs. as prefix? Or mnt.? But I think mount. is the nicest one, even if it is slightly more to type. Hope that make sense? (OTOH I just yesterday merged a patch that introduced a new un-namespaced kernel cmdline option rescue, so I am not totall fair here, but I think that's a special case...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, 09.10.14 17:30, Tobias Hunger (tobias.hun...@gmail.com) wrote: I will update the patch as soon as I get home :-) Best Regards, Tobias PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) It's OK to just attach the git-format-patch formatted patches to your mail, even if it isn't the wahre Lehre. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. I think Michal just fixed this with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=6041a7ee2c1bbff6301082f192fc1b0882400d42 Could you check, please? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On 9 October 2014 17:30, Tobias Hunger tobias.hun...@gmail.com wrote: PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) Using git send-email works surprisingly well with Gmail [1]. Regards, T G-R [1] See https://coderwall.com/p/dp-gka for an example ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
Cool, seems fixed. okt 09 19:18:34 dbuch-laptop systemd[1]: Starting Hostname Service... okt 09 19:18:34 dbuch-laptop systemd[1]: Started Hostname Service. okt 09 19:20:34 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping timed out. Terminating. okt 09 19:20:34 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service entered failed state. okt 09 19:20:34 dbuch-laptop systemd[1]: systemd-hostnamed.service failed. okt 09 19:20:57 dbuch-laptop systemd[1]: Starting Hostname Service... okt 09 19:20:57 dbuch-laptop systemd[1]: Started Hostname Service. okt 09 19:22:57 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping timed out. Terminating. okt 09 19:22:57 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service entered failed state. okt 09 19:22:57 dbuch-laptop systemd[1]: systemd-hostnamed.service failed. -- Reboot -- okt 09 19:49:34 dbuch-laptop systemd[1]: Starting Hostname Service... okt 09 19:49:34 dbuch-laptop systemd[1]: Started Hostname Service. dbuch@dbuch-laptop ~ % date tor okt 9 19:55:13 CEST 2014 dbuch@dbuch-laptop ~ % systemctl --failed 0 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. They used to timeout after 2 minutes so this looks promising. 2014-10-09 18:23 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. I think Michal just fixed this with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=6041a7ee2c1bbff6301082f192fc1b0882400d42 Could you check, please? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 09/25] shared/socket-util: don't fail if libc doesn't support IDN
On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote: --- src/shared/socket-util.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c index e3e54e8..d4a1679 100644 --- a/src/shared/socket-util.c +++ b/src/shared/socket-util.c @@ -41,6 +41,16 @@ #include missing.h #include fileio.h +/* Don't fail if the standard library + * doesn't support IDN */ +#ifndef NI_IDN +#define NI_IDN 0 +#endif + +#ifndef NI_IDN_USE_STD3_ASCII_RULES +#define NI_IDN_USE_STD3_ASCII_RULES 0 +#endif If glibc supports building in a way that these are no defined I am willing to merge this (though it would belong in missing.h, not into sockt-util.c). However, I am pretty sure that glibc defines this even if IDN is disabled in the build, and if that's the case then your libc should really do the same. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 09 Oct 2014 at 16:44:42 (+0200) : But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. This feels wrong. The preset files are actually globs, not full file names. They are not really suitable as a list of filenames, but only as something to match file names against... Yes, this is exactly what I was saying, sorry for the miscommunication... -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Honor mount.usr*= on kernel command line
Lennart, Harald: I did check the kernel sources for the string \mount\: As expected that string does show up in a couple of places, but it does not seem to be in use as a module name at this time. Tobias G-R: Thanks for the instructions on how to use git-send-email:-) Tobias Hunger (1): fstab-generator: Honor mount.usr*= on kernel command line man/systemd-fstab-generator.xml | 76 - src/fstab-generator/fstab-generator.c | 90 +-- 2 files changed, 160 insertions(+), 6 deletions(-) -- 2.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: Honor mount.usr*= on kernel command line
This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). --- man/systemd-fstab-generator.xml | 76 - src/fstab-generator/fstab-generator.c | 90 +-- 2 files changed, 160 insertions(+), 6 deletions(-) diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml index e3cf5d2..65b48ee 100644 --- a/man/systemd-fstab-generator.xml +++ b/man/systemd-fstab-generator.xml @@ -104,9 +104,83 @@ (initrd) while varnamefstab=/varname is honored by both the main system and -the initrd. /para/listitem +the initrd./para/listitem /varlistentry +varlistentry +termvarnameroot=/varname/term + +listitemparaTakes the root filesystem to mount +in the initrd. +varnameroot=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnamerootfstype=/varname/term + +listitemparaTakes the root filesystem type that +will be passed to the mount command. +varnamerootfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnamerootflags=/varname/term + +listitemparaTakes the root filesystem mount options +to use. varnamerootflags=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnamemount.usr=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem to be mounted by the initrd. If +varnamemount.usrfstype=/varname or +varnamemount.usrflags=/varname is set, then +varnamemount.usr=/varname will default to the value set in +varnameroot=/varname./para + +paraOtherwise this parameter defaults to the +filename/usr/filename entry +found in filename/etc/fstab/filename on the root +filesystem./para + +paravarnamemount.usr=/varname is honored by the initrd. +/para/listitem +/varlistentry +varlistentry + termvarnamemount.usrfstype=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem type that will be passed to the mount +command. If varnamemount.usr=/varname or +varnamemount.usrflags=/varname is set, then +varnamemount.usrfstype=/varname will default to the value set in +varnamerootfstype=/varname./para + +paraOtherwise this value will be read from the +filename/usr/filename entry in +filename/etc/fstab/filename on the root filesystem./para + +paravarnamemount.usrfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnamemount.usrflags=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem mount options to use. If +varnamemount.usr=/varname or +varnamemount.usrfstype=/varname is set, then +varnamemount.usrflages=/varname will default to the value set in +varnamerootflags=/varname./para +paraOtherwise this value will be read from the +filename/usr/filename entry in +filename/etc/fstab/filename on the root filesystem./para + +
[systemd-devel] Fast User Switching does not seem to work
Hello all! I am not sure this is the appropriate mailing list, and I have also posted to intel-...@lists.freedesktop.org (without any solution) and arch-gene...@archlinux.org Please indicate if you recommend me posting the problem to another list. I am encountering a peculiar problem with Fast User Switching or Kernel Mode Setting and I do not know how to troubleshoot it. Suppose the following tty2,3 or VTs: 1. Ctrl+Alt+F2:logged in user in console (no X) 2. Ctrl+Alt+F3:logged in user in console (no X) 3. Ctrl+Alt+F4:logged in user in Desktop Environment (X) 4. Ctrl+Alt+F5:logged in user in Desktop Environment (X) From 1 to 2, or 2 to 1 there is no delay. From 1,2 to 3, or 1,2 to 4 there is no delay. From 3,4 to 1,2 there **is** delay. From 3 to 4, or 4 to 3, there **is**delay. In words: when I run two (or more) Virtual Terminals switching between them (Ctrl+Alt+F4-5, etc.) takes 2+ seconds. (The VTs are either simply initiated with startx from tty2 and tty3 and having only TWM, xorg-clock and xterm as their open windows OR as different displays with KDisplay Manager (kdm) in :0 and :1) I am using an intel graphics driver so I suppose KMS should be enabled by default and this seems to be the case, but there still are delays swithing between VTs. I have followed the instructions at http://carlosbecker.com/posts/how-to-enable-kms-on-i915-graphiccard-archlinux/ https://wiki.archlinux.org/index.php/kernel_mode_setting https://wiki.archlinux.org/index.php/Intel_graphics after a fresh Arch Linux installation, but I am still experiencing the problem. I am certain it is not a hardware related issue, because I can fast switch in ubuntu, but not in Arch linux. My Arch uses systemd and Ubuntu upstart. Last, I am aware of the systemd's on-demand feature of spawning terminals but I think it is not related to this, since I think I correctly pre-spawned them. How can I make switching between VTs as instantaneous as possible? PS: $ sudo cat /sys/module/i915/parameters/modeset 1 ### Note: ### Before starting the process of enabling KMS (which I suppose it should be enabled in the first place, right?) this value was:-1 $ uname -a Linux myhostname 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 GNU/Linux $ lsmod | grep -e drm -e 915 -e kms crc32_pclmul12915 0 scsi_mod 142915 4 uas,usb_storage,libata,sd_mod i915 864879 8 button129091 i915 i2c_algo_bit 127441 i915 video 179951 i915 drm_kms_helper492621 i915 drm 258005 10 i915,drm_kms_helper i2c_core 501525 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit intel_gtt 178482 i915,intel_agp $ sudo lspci -vvnn | head -28 | tail -21 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device [1849:0152] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 40 Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 4181 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 Kernel modules: i915 $ head -10 /var/log/Xorg.0.log [ 4.919] X.Org X Server 1.16.1 Release Date: 2014-09-21 [ 4.919] X Protocol Version 11, Revision 0 [ 4.919] Build Operating System: Linux 3.16.1-1-ARCH x86_64 [ 4.919] Current Operating System: Linux myhostname 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 [ 4.919] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=af9a90ee-5db2-4abf-b8be-006a65e9f09e rw quiet video=SVIDEO-1:d [ 4.920] Build Date: 21 September 2014 10:53:13AM [ 4.920] [ 4.920] Current version of pixman: 0.32.6 ### Note: ### As kernel parameters I have also tried video=SVIDEO-1:d, i915.modeset=1, and nothing, but neither works. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 10/09/2014 02:26 PM, Lennart Poettering wrote: On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 10/08/2014 11:41 PM, Lennart Poettering wrote: TODO list to allow services also when they have no ExecStart= but with an ExecStop=, but this has not been implemented yet. What's the usecase for this behaviour? Precisely cases like the one described earlier in this thread: when you want to run something only at shutdown, properly ordered against other units that are also shut down. To me that already works just fine. [Unit] Description=My Shutdown Test Before=shutdown.target DefaultDependencies=no [Service] Type=oneshot ExecStart=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-2 [Install] WantedBy=shutdown.target journalctl SYSLOG_IDENTIFIER=SHUTDOWN -- Logs begin at Thu 2013-10-24 11:47:22 GMT, end at Thu 2014-10-09 20:00:17 GMT. -- Oct 09 19:57:51 localhost.localdomain SHUTDOWN[1968]: Systemd shutdown test-1 -- Reboot -- Oct 09 19:59:19 localhost.localdomain SHUTDOWN[1898]: Systemd shutdown test-2 ( the former log is from when I initially tested the unit before reboot ) If I wanted to order it after an service I added After=httpd.service [Unit] Description=My Shutdown Test Before=shutdown.target After=httpd.service DefaultDependencies=no [Service] Type=oneshot ExecStart=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-3 [Install] WantedBy=shutdown.target In my test I added this line to httpd.service ExecStop=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-3 Apache Stopped Then I rebooted and as you can see things seem to work perfectly as in the test case was stopped after apache had stopped make the shutdown order correct # journalctl SYSLOG_IDENTIFIER=SHUTDOWN -- Reboot -- Oct 09 20:16:37 localhost.localdomain SHUTDOWN[1972]: Systemd shutdown test-3 Apache Stopped Oct 09 20:16:38 localhost.localdomain SHUTDOWN[1985]: Systemd shutdown test-3 What I dont understand what's the usecase for somekind of ExecStop= modfications, why do we need to do that? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 10/09/2014 08:28 PM, Jóhann B. Guðmundsson wrote: What I dont understand what's the usecase for somekind of ExecStop= modfications, why do we need to do that? Note that the Before= in the test script is failing to pass which indicates something is borked in the ordering I added the Before= line in shutdown-test.service [Unit] Description=My Shutdown Test Before=httpd.service shutdown.target DefaultDependencies=no [Service] Type=oneshot ExecStart=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-4 [Install] WantedBy=shutdown.target And added this line to the httpd.service ExecStop=/bin/systemd-cat -t SHUTDOWN /bin/echo Systemd shutdown test-4 after shutdown-test.service Rebooted and as you can see the shutdown-test.service is being run *after* the httpd.service not before... Oct 09 21:11:15 localhost.localdomain SHUTDOWN[2098]: Systemd shutdown test-4 after shutdown-test.service Oct 09 21:11:16 localhost.localdomain SHUTDOWN[2108]: Systemd shutdown test-4 Expected result, shutdown-test.service being run before httpd.service as in... Oct 09 21:11:15 localhost.localdomain SHUTDOWN[2108]: Systemd shutdown test-4 Oct 09 21:11:16 localhost.localdomain SHUTDOWN[2098]: Systemd shutdown test-4 after shutdown-test.service ( systemd-208-22.fc20.x86_64 which probably means the dracut and alsa units that are tied to the shutdown.target aren't working as expected ) Perhaps that bug is the reason you think we need somekind of ExecStop= modfications? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag
Hi Lennart! Thanks for your response! I observed this issue on Arch Linux ARM running systemd-216-3, which it appears uses sources from about a week before that patch was committed. Thanks for pointing out the commit! I'll compile from HEAD and test again On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote: On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote: Hello, A little bit back I wrote in about having some difficulties adding network devices to containers. With some help from the list, I figured out how to add my network devices to an already running container using 'iw phy' and 'ip link'. However, I have not yet successfully added an interface to a container by way of the --network-interface flag. Attempting to add any ethernet devices by this method meets with the error: [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists According to the systemd-nspawn documentation, it seems like this invocation should work --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, it is moved back to the host namespace. Note that --network-interface= implies --private-network. This option may be used more than once to add multiple network interfaces to the container. If I'm doing something wrong, then it seems like the documentation may desire revisiting. If I'm not, then this could be unintended behavior. Which version of systemd-nspawn are you trying this with? Note that there was a recent fix in the code handling --network-interface=, that might make work what you are trying to do: http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id=31 25b3ef5db70d45882c7d6f617705802c5f939e Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote: The ExecStart=/bin/true we just add because current systemd versions refuse to run service units that have no ExecStart= set. It is on the TODO list to allow services also when they have no ExecStart= but with an ExecStop=, but this has not been implemented yet. Isn't this it: commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1 Author: Lennart Poettering lenn...@poettering.net Date: Thu Aug 21 18:50:42 2014 +0200 service: allow services of Type=oneshot that specify no ExecStart= commands This is useful for services that simply want to run something on shutdown, but not at bootup. They should only set ExecStop= but leave ExecStart= unset. Confused, Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann mar...@holtmann.org escribió: Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there? Thanks, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] clarify what microsoft and oracle stands for
--- man/systemd-detect-virt.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml index 1e8230c..4f9980a 100644 --- a/man/systemd-detect-virt.xml +++ b/man/systemd-detect-virt.xml @@ -68,8 +68,8 @@ virtualization technology. The following technologies are currently identified: varnameqemu/varname, varnamekvm/varname, varnamevmware/varname, -varnamemicrosoft/varname, -varnameoracle/varname, varnamexen/varname, +varnamemicrosoft/varname (Hyper-V), +varnameoracle/varname (VirtualBox), varnamexen/varname, varnamebochs/varname, varnamechroot/varname, varnameuml/varname, varnameopenvz/varname, varnamelxc/varname, -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] clarify what microsoft and oracle stands for
On Thu, Oct 09, 2014 at 10:14:36PM -0400, Rahul Sundaram wrote: --- man/systemd-detect-virt.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml index 1e8230c..4f9980a 100644 --- a/man/systemd-detect-virt.xml +++ b/man/systemd-detect-virt.xml @@ -68,8 +68,8 @@ virtualization technology. The following technologies are currently identified: varnameqemu/varname, varnamekvm/varname, varnamevmware/varname, -varnamemicrosoft/varname, -varnameoracle/varname, varnamexen/varname, +varnamemicrosoft/varname (Hyper-V), +varnameoracle/varname (VirtualBox), varnamexen/varname, varnamebochs/varname, varnamechroot/varname, varnameuml/varname, varnameopenvz/varname, varnamelxc/varname, Hi, I merged this and Dale's descriptions and pushed. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values
On Wed, Oct 08, 2014 at 08:58:53PM +0200, Jan Janssen wrote: On 2014-10-08 14:59, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 08, 2014 at 08:24:49AM +0200, Jan Janssen wrote: Gesendet: Mittwoch, 08. Oktober 2014 um 01:40 Uhr Von: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl An: Jan Janssen medhe...@web.de Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values On Mon, Oct 06, 2014 at 06:57:38PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote: *bump* Sorry, I'll look into this. Doesn't work. Both without or with your other patch sd_journal_enumerate_unique I get bogus results on my test case. It seems the issue is more complicated. That's odd. Care to elaborate what bogus results means? Are you even affected by the bug in question without the patch? Yes, I have a VM where I get a smaller number from -F _BOOT_ID than from --list-boots (w/o your patches), and then the same smaller number with one or two of your patches. So results become consistent, but equally bad. Of course I can't know if this is exactly the same bug, but it certainly looks like it. Sounds like maybe one of those calls end up interleaving journals from different machines? Also, does removing the call to journal_file_object_release() in sd_journal_enumerate_unique() improve things or not? How about moving it after the if(found) where it was before the patch? I'd love to investigate this, but I sadly don't have any journals that triggers this :( Hi, I now pushed your patch to add release_cookie. I found that the problem I saw was with sd_j_enumerate_unique getting confused by removal of corrupted files. See the commit message for longer explanation. You were right that there's a problem with interleaving sd_j_e_u and sd_j_next in list_boots(), because this triggered the issue. I decided to fix this and still allow interleaving. To reproduce my issue, it is enough to have a file which is corrupted and this corruption gets detected in sd_j_next(), but the file is in good enough shape to be opened and pass sd_j_enumerate_unique(). If the file is not the first in hashmap, the problem should occur. I was inclined to merge your other patch (to remove the interleaving, especially that it makes the code shorter and simpler), but ultimately decided against that. It makes the listing noticably slower (1.5 → 1.9 s in my case). I imagine that on a slower disk this would be even more visible, as we essentially iterate over the file list twice. Please test, but note that 'journalctl -F_BOOT_ID' might return *more* items than 'journalctl --list-boots' because the latter will remove the files for which it detects corruption. So it is even possible that simply looking at the journal with normal sequential access (i.e. plain 'journalctl') can show partial data for boots that --list-boots will not show. I'm not sure how significant this is and what to do with that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: remove unnecessary ordering dependencies in systemd-hibernate-resume@.service
On Wed, Aug 27, 2014 at 08:32:56PM +0400, Ivan Shapovalov wrote: -Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service +Before=local-fs-pre.target Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library
On Thu, Oct 09, 2014 at 07:01:11PM +0530, Susant Sahani wrote:
CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
src/socket-proxy/socket-proxyd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/socket-proxy/socket-proxyd.c
b/src/socket-proxy/socket-proxyd.c
index ff2b24f..3041903 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int
buffer[2], size_t *sz) {
return -errno;
}
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
r = fcntl(buffer[0], F_GETPIPE_SZ);
if (r 0) {
For the sake of ML archives...
this was pushed by David.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
