Re: [systemd-devel] Container, private network and socket activation
On Tue, Feb 03, 2015 at 11:28:09PM +0100, Christian Seiler wrote: > Am 03.02.2015 um 22:06 schrieb Lennart Poettering: > > Socket activation is somethings daemons need to support > > explicitly. Many do these days, but I don't think Apache is one of > > them. > > FYI: all released versions (i.e. up to 2.4.x) of Apache httpd don't > support it yet, but the current development version does - at least if > you compile it with the corresponding options (no module needs to be > loaded for that, it's in the core). > > There's a proposal to backport that and sd_notify integration[1] to the > stable 2.4.x branch, but nothing's happened so far: > > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1656674&view=markup#l138 > > [1] Although Fedora apparently already includes sd_notify integration > for quite a while now, but no socket activation... Fadora allows socket activation for httpd, actually, since: http://pkgs.fedoraproject.org/cgit/httpd.git/commit/?id=572a5df9ee47a39d346a4f6b7cd76f6a8804d63f -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] VLAN's not coming up "systemd-networkd.service loaded failed" + systemd-networkd seg fault
On Thu, 20.11.14 15:28, Brendan Horan (brendanho...@basstech.net) wrote: > > No one has any clue? > > Or do I need to provide more information? (if so what?) > Hmm, somehow this thread got lost. Is this still an issue with current > git? If so could you repost, and we'll have a look at it. Unsure if this is still an issue with the current git. When I can test this again and if it is still an issue I will repost to the list. > Sorry for not responding more timely and for resurrecting this months > old thread! No problem. Thank you for your time to reply. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DefaultDependencies=false on scopes
Hey Lennart- On Tue, Feb 3, 2015 at 10:32 AM, Brandon Philips wrote: > On Tue, Feb 3, 2015 at 10:20 AM, Lennart Poettering > wrote: >> I have added DefaultDependencies= for you now: >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50 > > Thank you. I will work on getting Docker fixed up to fix this annoying > behavior. So, is this the best way to tell if the systemd I am working with supports setting this property on a scope? https://github.com/philips/libcontainer/blob/systemd-default-dependencies-false/cgroups/systemd/apply_systemd.go#L74 Essentially I am trying to create a scope and seeing if I get a PropertyReadOnly, if I do I don't set it. For reference the PR is: https://github.com/docker/libcontainer/pull/359 Thanks, Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Container, private network and socket activation
> Hmm, to implement something like this I think the best option would be > to set up the interface to later pass to the container first on the > host, then listen on the container's IP address on the host. When a > connection comes in the container would have to be started via socket > activation, and would then have to take over the container interface > (with --network-interface=), so that all further connections are > delivered directly to the container and the host is not involved > anymore. I managed to set this up. In short: # ip link add type veth # ip addr add 192.168.10.10/24 brd + dev veth1 # ip addr add 192.168.10.20/24 brd + dev veth0 # ip link set veth1 up # ip link set veth0 up # brctl addif br_lxc veth0 This sets two interfaces, one of which (veth1) goes to the container via the following service file: [Unit] Description=My little container [Service] Type=simple KillMode=process ExecStart=/usr/bin/systemd-nspawn -jbD /media/Kabi/debian-tree/ \ --network-interface=veth1 \ --bind /media/Kabi/apache/:/apache/ \ --bind /media/Kabi/backup_packages/apt/archives/:/var/cache/apt/archives/ \ --bind /media/Kabi/repozytorium:/repozytorium \ 3 In addition, I have my bridge interface set: auto br_lxc iface br_lxc inet static address 192.168.10.100 netmask 255.255.255.0 broadcast 192.168.10.255 bridge_ports none bridge_waitport 0 bridge_fd 0 The next thing is to socket activate the container through this file: [Unit] Description=The HTTP/HTTPS socket of my little container [Socket] ListenStream=192.168.10.10:80 ListenStream=192.168.10.10:443 When I start the socket, I get: root:~# systemctl start mycontainer.socket root:~# systemctl status mycontainer.socket ● mycontainer.socket - The HTTP/HTTPS socket of my little container Loaded: loaded (/etc/systemd/system/mycontainer.socket; static; vendor preset: enabled) Active: active (listening) since Wed 2015-02-04 04:00:51 CET; 1s ago Listen: 192.168.10.10:80 (Stream) 192.168.10.10:443 (Stream) Feb 04 04:00:51 morfikownia systemd[1]: Listening on The HTTP/HTTPS socket of my little container. That's all for the host. In the container I had to configure the passed interface via /etc/network/interface : auto veth1 iface veth1 inet static address 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 gateway 192.168.10.100 And that's it. This setup works. I mean, when I type in my firefox http://192.168.10.10, the container boots and I'm able to browse the page. Now I have some questions: 1. When I try to connect for the very first time, I get a timeout, even though the container is working. I can cancel the connection immediately, and reconnect after 2-3 sec and then the page shows up. All subsequent connections work without a problem, just the first one gets a timeout. Is there a way to fix this, so the first connection that boots the system could be somehow delayed, so after a while the page would show up? 2. Is there a way to shut down the container automatically after some period of inactivity? Let's say there's no traffic for 30min, and after this time the container goes down. 3. How to stop the container manually? I'm asking because when I try via "systemctl stop mycontainer.service" , it stops, but: ... Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Halting system. Feb 04 04:15:58 morfikownia systemd-machined[14353]: Machine debian-tree terminated. Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Container debian-tree has been shut down. Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container... Feb 04 04:15:58 morfikownia systemd[1]: Stopping Container debian-tree. Feb 04 04:15:58 morfikownia systemd[1]: Stopped Container debian-tree. Feb 04 04:15:58 morfikownia kernel: br_lxc: port 1(veth0) entered disabled state Feb 04 04:15:58 morfikownia kernel: device veth0 left promiscuous mode Feb 04 04:15:58 morfikownia kernel: br_lxc: port 1(veth0) entered disabled state Feb 04 04:15:58 morfikownia systemd-nspawn[15325]: Spawning container debian-tree on /media/Kabi/debian-tree. Feb 04 04:15:58 morfikownia systemd-nspawn[15325]: Press ^] three times within 1s to kill container. Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service: main process exited, code=exited, status=237/n/a Feb 04 04:15:58 morfikownia systemd[1]: Failed to start My little container. Feb 04 04:15:58 morfikownia systemd[1]: Unit mycontainer.service entered failed state. Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service failed. Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container... Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service: main process exited, code=exited, status=237/n/a Feb 04 04:15:58 morfikownia systemd[1]: Failed to start My little container. Feb 04 04:15:58 morfikownia systemd[1]: Unit mycontainer.service entered failed state. Feb 04 04:
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
> On Feb 3, 2015, at 3:52 PM, Lennart Poettering wrote: > > On Tue, 03.02.15 23:22, Jay Faulkner (j...@jvf.cc) wrote: > >> Hi all, >> >> As I posted last week, a change merged a while ago to systemd-nspawn >> adding seccomp protections with no ability to enable/disable broke >> the Ironic Python Agent ramdisk which utilizes CoreOS and >> systemd. The attached patch makes the behavior optional, with it >> defaulting to disabled. I did this for two reasons; the first being >> that my (and other consumers of OpenStack Ironic) use case was >> broken, as would anyone else using spawn in this >> manner. Additionally, seccomp filters can be configured specifically >> as desired in the unit file. > > This was about allowing kernel module loading from inside nspawn > containers? > Yes, exactly. > I completely missed that we actually really have seccomp filters to > disallow that in place... We hence have two layers of security there > to turn off kernel module loading: seccomp and the missing > CAP_SYS_MODULE capability. > As I discovered looking through the code; setting capability=all prevents *any* capabilities from being dropped, which means I was covered on this until the change was merged to add seccomp support. > I am not particularly fond of the idea of adding a completely new > command line option for this though. Maybe we can find another way for > this. > > For example, one option could be to split the seccomp syscall > blacklist in two: split out the kernel kmod related syscalls, and > only add them to the seccomp filter if arg_retain does not include > CAP_SYS_MODULE. This would then leave the module seccomp filters in > place by default, however, if you add the CAP_SYS_MODULE cap to the > container with --capability= then the seccomp filter is changed to > also allow the module loading sys calls. I implemented this; the patch can be pulled directly from https://github.com/jayofdoom/systemd/pull/2.patch to prevent me from corrupting this along the way. As a note; unlike what we discussed in IRC, someone passing capability=all will be covered for module loading in this situation, because all sets the bitmask to -1, effectively enabling all capabilities. Thanks, Jay Faulkner > The patch is corrupted, it includes Windows new lines. > > If you rework the patch as suggested above, and send it as uncorrupted > patch, I'd be happy to merge it. > > 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] [systemd-commits] 2 commits - TODO src/core src/shared
On Wed, 04.02.15 02:23, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > Sounds OK to me. Question is how to check this best... > > > > Maybe check with get_ctty_devnr() if we have a controlling tty? > > If I launch 'systmectl' in a script from the command line, I'd prefer it not > to be in debug mode either. checking the controlling tty would achieve that. Note that you cannot accidentally lose your controlling tty. Even if you use shell redirection to disconnect a process' stdin, stdout, stderr away from a tty, it will still keep it as ctty (that's why SIGINT is still delivered to a process on C-c, even if you disconnect all its fds from the tty). The only way to really get rid of your ctty is by calling setsid() or invoking TIOCNOTTY, but this is precisely what daemons do, not what normal commands do. Hence I think get_ctty_devnr() is a really good choice for this... > Maybe something like > org.freedesktop.systemd1.Manager.GetUnitByPID(getpid()) not being a > .scope? Hmm, I really wouldn't want to involve dbus here, after all we'd use it in pretty much all code... Also, scope units are used for other purposes too, like "systemd-run"... Also, I think that debug mode should even be enabled for user daemons as long as they are not controlled directly by terminals... 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] [systemd-commits] 2 commits - TODO src/core src/shared
On Wed, Feb 04, 2015 at 02:15:25AM +0100, Lennart Poettering wrote: > On Wed, 04.02.15 02:10, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > On Tue, Feb 03, 2015 at 04:47:44PM -0800, Lennart Poettering wrote: > > > TODO | 15 +++ > > > src/core/main.c |2 -- > > > src/shared/log.c |4 +++- > > > 3 files changed, 18 insertions(+), 3 deletions(-) > > > > > > New commits: > > > commit 5e07a79e84ab8b045b9df1a2719f14fc84471a1d > > > Author: Lennart Poettering > > > Date: Wed Feb 4 01:42:49 2015 +0100 > > > > > > core: don't reset log level to NOTICE if we get quiet on the kernel > > > cmdline > > > > > > quiet should really just have an effect on the stuff we dump on the > > > console, not what we log elsewhere. > > > > > > Hence: > > > > > > debug on kernel cmdline ??? interpreted by every tool, turns > > > up > > > log levels to "debug" everywhere. > > Actually I find this quite annoying in practice. Command line tools > > also obey this, spewing stuff on the terminal. If debug settings are > > specified on the commandline, there's no nice way to "unspecify" them. > > > > Maybe we could amend the rule to only turn on debug in things started > > in system services? > > Sounds OK to me. Question is how to check this best... > > Maybe check with get_ctty_devnr() if we have a controlling tty? If I launch 'systmectl' in a script from the command line, I'd prefer it not to be in debug mode either. Maybe something like org.freedesktop.systemd1.Manager.GetUnitByPID(getpid()) not being a .scope? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] cg_path_get_user_unit(): Did not correctly parse user-unit templates.
On Tue, 03.02.15 20:07, Luke Shumaker (luke...@sbcglobal.net) wrote:
> It ran either skip_session() or skip_user_manager(), then ran skip_slices()
> iff skip_session() ran. It needs to run skip_slices() in either case.
>
> Included is a test case demonstrating why.
Thanks! Applied!
> ---
> src/shared/cgroup-util.c| 18 --
> src/test/test-cgroup-util.c | 1 +
> 2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
> index 0d3cc53..d34e1fa 100644
> --- a/src/shared/cgroup-util.c
> +++ b/src/shared/cgroup-util.c
> @@ -1251,17 +1251,15 @@ int cg_path_get_user_unit(const char *path, char
> **unit) {
> /* Skip slices, if there are any */
> e = skip_slices(path);
>
> -/* Skip the session scope... */
> +/* Skip the session scope or user manager... */
> t = skip_session(e);
> -if (t)
> -/* ... and skip more slices if there's one */
> -e = skip_slices(t);
> -else {
> -/* ... or require a user manager unit to be there */
> -e = skip_user_manager(e);
> -if (!e)
> -return -ENOENT;
> -}
> +if (!t)
> +t = skip_user_manager(e);
> +if (!t)
> +return -ENOENT;
> +
> +/* ... and skip more slices if there are any */
> +e = skip_slices(t);
>
> return cg_path_decode_unit(e, unit);
> }
> diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
> index 58eb744..67eeeb5 100644
> --- a/src/test/test-cgroup-util.c
> +++ b/src/test/test-cgroup-util.c
> @@ -93,6 +93,7 @@ static void test_path_get_user_unit(void) {
> check_p_g_u_u("/meh.service", -ENOENT, NULL);
> check_p_g_u_u("/session-3.scope/_cpu.service", 0, "cpu.service");
>
> check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/server.service",
> 0, "server.service");
> +
> check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/foobar.slice/foobar@pie.service",
> 0, "foobar@pie.service");
>
> check_p_g_u_u("/user.slice/user-1000.slice/user@.service/server.service",
> -ENOENT, NULL);
> }
>
> --
> 2.2.2
>
> ___
> 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] [systemd-commits] 2 commits - TODO src/core src/shared
On Wed, 04.02.15 02:10, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Tue, Feb 03, 2015 at 04:47:44PM -0800, Lennart Poettering wrote: > > TODO | 15 +++ > > src/core/main.c |2 -- > > src/shared/log.c |4 +++- > > 3 files changed, 18 insertions(+), 3 deletions(-) > > > > New commits: > > commit 5e07a79e84ab8b045b9df1a2719f14fc84471a1d > > Author: Lennart Poettering > > Date: Wed Feb 4 01:42:49 2015 +0100 > > > > core: don't reset log level to NOTICE if we get quiet on the kernel > > cmdline > > > > quiet should really just have an effect on the stuff we dump on the > > console, not what we log elsewhere. > > > > Hence: > > > > debug on kernel cmdline ??? interpreted by every tool, turns up > > log levels to "debug" everywhere. > Actually I find this quite annoying in practice. Command line tools > also obey this, spewing stuff on the terminal. If debug settings are > specified on the commandline, there's no nice way to "unspecify" them. > > Maybe we could amend the rule to only turn on debug in things started > in system services? Sounds OK to me. Question is how to check this best... Maybe check with get_ctty_devnr() if we have a controlling tty? 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] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: > 2015-02-04 1:54 GMT+01:00 Lennart Poettering : > > On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: > >> Is this the same issue as > >> https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ? > > > > Feels like it. > > > > It's not clear to me though why the bug was closed, i.e. what fix was > > applied there... > > We pulled a fix/workaround from the Fedora package [1] if my memory > serves me well. > If we could get rid of that and this is fixed upstream proper, that > would be great. > > Michael > > > [1] > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b That hack is actually not that ugly... Though incomplete since it will only add refs to runlevel[1-5], but not 0,6... But I still think the .wants symlinks from sysv-generator might be the better hack to apply... 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] [systemd-commits] 2 commits - TODO src/core src/shared
On Tue, Feb 03, 2015 at 04:47:44PM -0800, Lennart Poettering wrote: > TODO | 15 +++ > src/core/main.c |2 -- > src/shared/log.c |4 +++- > 3 files changed, 18 insertions(+), 3 deletions(-) > > New commits: > commit 5e07a79e84ab8b045b9df1a2719f14fc84471a1d > Author: Lennart Poettering > Date: Wed Feb 4 01:42:49 2015 +0100 > > core: don't reset log level to NOTICE if we get quiet on the kernel > cmdline > > quiet should really just have an effect on the stuff we dump on the > console, not what we log elsewhere. > > Hence: > > debug on kernel cmdline ??? interpreted by every tool, turns up > log levels to "debug" everywhere. Actually I find this quite annoying in practice. Command line tools also obey this, spewing stuff on the terminal. If debug settings are specified on the commandline, there's no nice way to "unspecify" them. Maybe we could amend the rule to only turn on debug in things started in system services? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix install location of systemd.pc
On Tue, 30.12.14 16:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Mon, Dec 29, 2014 at 03:01:12PM +, Simon Peeters wrote: > > 2014-12-29 13:02 GMT+00:00 Martin Pitt : > > > Mike Gilbert [2014-12-28 12:41 -0500]: > > >> From Lennart's commit message, it seems like this was done intentionally. > > > > > > The addition of libdir was certainly intentional, that's why I didn't > > > propose to just remove libdir. But it looks like this was just missing > > > to adjust the install location accordingly? > > > > just my 2c: > > > > well, the addition of libdir was to be able to find the libdir for the > > "primary" arch (however you might define that), moving the pc file > > with this info to $libdir/pkgconfig makes that argument moot since you > > need to know libdir in order to know libdir. > > > > So if I can follow lennart correctly there are 2 possible ways: > > - have libdir in the pc file in /usr/share and make it to denote the > > "primary" arch (which is the current situation) > > - not have libdir in the pc file at all and still have the pc file in > > /usr/share (since libdir does not make sense if the file is in > > $libdir/pkgconfig, and it is the only reason why it might not belong > > in /usr/share) > > > > I have no preference between the 2, but moving the pc file to > > $libdir/pkgconfig just does not make sense. > > What is $libdir in the .pc file used for? If we can answer that, it'll > be clearer whether status quo is correct. The reason I added $libdir there is actually to make this easily queriable, so that I could reference that in file-hierarchy(7). See the part about "vendor-supplied operating system resources" in there. Martin's fix to move this to /usr/share looks right, though, afaics. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] cg_path_get_user_unit(): Did not correctly parse user-unit templates.
It ran either skip_session() or skip_user_manager(), then ran skip_slices()
iff skip_session() ran. It needs to run skip_slices() in either case.
Included is a test case demonstrating why.
---
src/shared/cgroup-util.c| 18 --
src/test/test-cgroup-util.c | 1 +
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 0d3cc53..d34e1fa 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1251,17 +1251,15 @@ int cg_path_get_user_unit(const char *path, char
**unit) {
/* Skip slices, if there are any */
e = skip_slices(path);
-/* Skip the session scope... */
+/* Skip the session scope or user manager... */
t = skip_session(e);
-if (t)
-/* ... and skip more slices if there's one */
-e = skip_slices(t);
-else {
-/* ... or require a user manager unit to be there */
-e = skip_user_manager(e);
-if (!e)
-return -ENOENT;
-}
+if (!t)
+t = skip_user_manager(e);
+if (!t)
+return -ENOENT;
+
+/* ... and skip more slices if there are any */
+e = skip_slices(t);
return cg_path_decode_unit(e, unit);
}
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 58eb744..67eeeb5 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -93,6 +93,7 @@ static void test_path_get_user_unit(void) {
check_p_g_u_u("/meh.service", -ENOENT, NULL);
check_p_g_u_u("/session-3.scope/_cpu.service", 0, "cpu.service");
check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/server.service",
0, "server.service");
+
check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/foobar.slice/foobar@pie.service",
0, "foobar@pie.service");
check_p_g_u_u("/user.slice/user-1000.slice/user@.service/server.service",
-ENOENT, NULL);
}
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cg_path_get_user_unit(): Did not correctly parse user-unit templates.
At Wed, 4 Feb 2015 01:52:36 +0100, Lennart Poettering wrote: > > +/* Skip the session scope or user manager... */ > > +(t = skip_session(e)) || (t = skip_user_manager(e)); > > Hmpf, I really don't like this ()||() magic I must say. > > Any chance you can rework this to just use normal > > t = skip_session(e); > if (!t) > t = skip_user_manager(...) > > THis is really an excercise in making code easily readable, not an > excercsie to show superior C skills ;-) Sure. I thought the || version was easier to read; that it showed the intent better. Though it may be that it's similar to a Ruby idiom, and I've been working with some Ruby recently. -- Happy hacking, ~ Luke Shumaker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
2015-02-04 1:54 GMT+01:00 Lennart Poettering : > On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: >> Is this the same issue as >> https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ? > > Feels like it. > > It's not clear to me though why the bug was closed, i.e. what fix was > applied there... We pulled a fix/workaround from the Fedora package [1] if my memory serves me well. If we could get rid of that and this is fixed upstream proper, that would be great. Michael [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b -- 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] [PATCH 3/4] systemctl: edit: further reword error messages
On Wed, Feb 04, 2015 at 03:35:47AM +0300, Ivan Shapovalov wrote:
> On 2015-01-05 at 17:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 19, 2014 at 05:08:09PM +0300, Ivan Shapovalov wrote:
> > > ---
> > > src/systemctl/systemctl.c | 22 +++---
> > > 1 file changed, 11 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> > > index 658793e..20c367c 100644
> > > --- a/src/systemctl/systemctl.c
> > > +++ b/src/systemctl/systemctl.c
> > > @@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char
> > > **user_home, char **user_runtime, Loo
> > >
> > > r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
> > > if (r < 0)
> > > -return log_error_errno(r, "Failed to lookup unit lookup
> > > paths: %m");
> > > +return log_error_errno(r, "Failed to get unit lookup
> > > paths: %m");
> > Maybe "query"? "get" is ugly.
>
> OK.
>
> >
> > > return 0;
> > > }
> > > @@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char
> > > *new_path, const char *original_path
> > >
> > > r = tempfn_random(new_path, &t);
> > > if (r < 0)
> > > -return log_error_errno(r, "Failed to determine temporary
> > > filename for %s: %m", new_path);
> > > +return log_error_errno(r, "Failed to determine temporary
> > > filename for \"%s\": %m", new_path);
> > >
> > > r = mkdir_parents(new_path, 0755);
> > > if (r < 0) {
> > > -log_error_errno(r, "Failed to create directories for %s:
> > > %m", new_path);
> > > +log_error_errno(r, "Failed to create directories for
> > > \"%s\": %m", new_path);
> > > free(t);
> > > return r;
> > > }
> > > @@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char
> > > *new_path, const char *original_path
> > > if (r == -ENOENT) {
> > > r = touch(t);
> > > if (r < 0) {
> > > -log_error_errno(r, "Failed to create temporary
> > > file %s: %m", t);
> > > +log_error_errno(r, "Failed to create temporary
> > > file \"%s\": %m", t);
> > > free(t);
> > > return r;
> > > }
> > > } else if (r < 0) {
> > > -log_error_errno(r, "Failed to copy %s to %s: %m",
> > > original_path, t);
> > > +log_error_errno(r, "Failed to copy \"%s\" to \"%s\":
> > > %m", original_path, t);
> > > free(t);
> > > return r;
> > > }
> > > @@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char
> > > *unit_name,
> > > if (!path_equal(fragment_path, tmp_new_path) &&
> > > access(tmp_new_path, F_OK) == 0) {
> > > char response;
> > >
> > > -r = ask_char(&response, "yn", "%s already exists, are
> > > you sure to overwrite it with %s? [(y)es, (n)o] ", tmp_new_path,
> > > fragment_path);
> > > +r = ask_char(&response, "yn", "\"%s\" already exists,
> > > are you sure to overwrite it with \"%s\"? [(y)es, (n)o] ", tmp_new_path,
> > > fragment_path);
> >
> > This is not gramatically correct. I think
> > "\"%s\" already exists. Overwrite with \"%s\"?..." would be better.
>
> OK.
>
> >
> >
> > > if (r < 0) {
> > > free(tmp_new_path);
> > > return r;
> > > @@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char
> > > *unit_name,
> > >
> > > r = create_edit_temp_file(tmp_new_path, fragment_path,
> > > &tmp_tmp_path);
> > > if (r < 0) {
> > > -log_error_errno(r, "Failed to create temporary file for
> > > %s: %m", tmp_new_path);
> > > +log_error_errno(r, "Failed to create temporary file for
> > > \"%s\": %m", tmp_new_path);
> > > free(tmp_new_path);
> > > return r;
> > > }
> > > @@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
> > > assert(args);
> > >
> > > if (!on_tty()) {
> > > -log_error("Cannot edit units if we are not on a tty");
> > > +log_error("Not on a tty, refusing.");
> > Why? Replacing a nice specific error message with a generic one seems to
> > be a step backwards.
>
> I've tried to follow the existing pattern of most error messages in
> systemd: "Condition, action + -ing."
>
> I'll reword again to make messages more specific... unless you tell me
> to stop bikeshedding and leave it as is ;)
Yeah, I think that that those messages are OK.
> > > -log_warning("Edition of %s canceled: temporary
> > > file empty", *original);
> > > +log_warning("Temporary file empty, not saving.");
> > And here.
>
> Here? Th
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: > 2015-02-04 1:29 GMT+01:00 Lennart Poettering : > > On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > >> This looks like fallout of moving to generators for sysv units. Before > >> systemd added dependencies on runlevelX.target directly to units built > >> from initscripts. This forced runlevelX.target resolution and > >> everything was OK. Now core systemd never references these targets > >> directly. > >> > >> This is a genuine bug which will bite people. But it looks like worked > >> just by accident before anyway :( So we need possibility to define > >> aliases for existing units without exhaustive search across all unit > >> definitions ... may be unit.alias.d? > > > > This is a real shortcoming of the current logic in systemd, indeed. > > > > So, one possible way out of this might be add a .wants/ dep from > > multi-user.target.wants/ to runlevel3.target, if runlevel3.target is > > linked to that. THis would cause runlevel3.target to be loaded, which > > would then detect the symlink and merge it into > > multi-user.target. After loading it would try to create the .wants > > link, but recognize that it is now trying to create a .wants link on > > itself, and suppress it. > > Is this the same issue as > https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ? Feels like it. It's not clear to me though why the bug was closed, i.e. what fix was applied there... 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] cg_path_get_user_unit(): Did not correctly parse user-unit templates.
On Tue, 03.02.15 19:46, Luke Shumaker (luke...@sbcglobal.net) wrote:
> It ran either skip_session() or skip_user_manager(), then ran skip_slices()
> iff skip_session() ran. It needs to run skip_slices() in either case.
>
> Included is a test case demonstrating why.
Oh! Indeed!
> ---
> src/shared/cgroup-util.c| 19 ---
> src/test/test-cgroup-util.c | 1 +
> 2 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
> index 0d3cc53..1c5af69 100644
> --- a/src/shared/cgroup-util.c
> +++ b/src/shared/cgroup-util.c
> @@ -1251,17 +1251,14 @@ int cg_path_get_user_unit(const char *path, char
> **unit) {
> /* Skip slices, if there are any */
> e = skip_slices(path);
>
> -/* Skip the session scope... */
> -t = skip_session(e);
> -if (t)
> -/* ... and skip more slices if there's one */
> -e = skip_slices(t);
> -else {
> -/* ... or require a user manager unit to be there */
> -e = skip_user_manager(e);
> -if (!e)
> -return -ENOENT;
> -}
> +/* Skip the session scope or user manager... */
> +(t = skip_session(e)) || (t = skip_user_manager(e));
> +
> +if (!t)
> +return -ENOENT;
Hmpf, I really don't like this ()||() magic I must say.
Any chance you can rework this to just use normal
t = skip_session(e);
if (!t)
t = skip_user_manager(...)
THis is really an excercise in making code easily readable, not an
excercsie to show superior C skills ;-)
> +
> +/* ... and skip more slices if there are any */
> +e = skip_slices(t);
>
> return cg_path_decode_unit(e, unit);
> }
> diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
> index 58eb744..67eeeb5 100644
> --- a/src/test/test-cgroup-util.c
> +++ b/src/test/test-cgroup-util.c
> @@ -93,6 +93,7 @@ static void test_path_get_user_unit(void) {
> check_p_g_u_u("/meh.service", -ENOENT, NULL);
> check_p_g_u_u("/session-3.scope/_cpu.service", 0, "cpu.service");
>
> check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/server.service",
> 0, "server.service");
> +
> check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/foobar.slice/foobar@pie.service",
> 0, "foobar@pie.service");
>
> check_p_g_u_u("/user.slice/user-1000.slice/user@.service/server.service",
> -ENOENT, NULL);
> }
>
Otherwise looks good. And you get extra points for the added testcase!
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] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
2015-02-04 1:29 GMT+01:00 Lennart Poettering : > On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: > >> This looks like fallout of moving to generators for sysv units. Before >> systemd added dependencies on runlevelX.target directly to units built >> from initscripts. This forced runlevelX.target resolution and >> everything was OK. Now core systemd never references these targets >> directly. >> >> This is a genuine bug which will bite people. But it looks like worked >> just by accident before anyway :( So we need possibility to define >> aliases for existing units without exhaustive search across all unit >> definitions ... may be unit.alias.d? > > This is a real shortcoming of the current logic in systemd, indeed. > > So, one possible way out of this might be add a .wants/ dep from > multi-user.target.wants/ to runlevel3.target, if runlevel3.target is > linked to that. THis would cause runlevel3.target to be loaded, which > would then detect the symlink and merge it into > multi-user.target. After loading it would try to create the .wants > link, but recognize that it is now trying to create a .wants link on > itself, and suppress it. Is this the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ? -- 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] "quiet" on kernel command line also prevents logging to journal
On Sun, 14.12.14 18:28, Andrei Borzenkov (arvidj...@gmail.com) wrote: > Before commit d7b15e0a0161e8fd823bffd61a4799364871582f "quiet" would > suppress console messages but still do normal logging. Now "quiet" also > clamps log level to NOTICE meaning that all messages about > starting/stopping services are no more logged. True. > Is this change intentional? This makes it rather hard to debug any > problem related to service startup order. Hmm, well, the change was intentional, but the effect of it was not clear to me ;-) You are right though. I have now changed this part again: http://cgit.freedesktop.org/systemd/systemd/commit/?id=5e07a79e84ab8b045b9df1a2719f14fc84471a1d Thanks, 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] cg_path_get_user_unit(): Did not correctly parse user-unit templates.
It ran either skip_session() or skip_user_manager(), then ran skip_slices()
iff skip_session() ran. It needs to run skip_slices() in either case.
Included is a test case demonstrating why.
---
src/shared/cgroup-util.c| 19 ---
src/test/test-cgroup-util.c | 1 +
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 0d3cc53..1c5af69 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1251,17 +1251,14 @@ int cg_path_get_user_unit(const char *path, char
**unit) {
/* Skip slices, if there are any */
e = skip_slices(path);
-/* Skip the session scope... */
-t = skip_session(e);
-if (t)
-/* ... and skip more slices if there's one */
-e = skip_slices(t);
-else {
-/* ... or require a user manager unit to be there */
-e = skip_user_manager(e);
-if (!e)
-return -ENOENT;
-}
+/* Skip the session scope or user manager... */
+(t = skip_session(e)) || (t = skip_user_manager(e));
+
+if (!t)
+return -ENOENT;
+
+/* ... and skip more slices if there are any */
+e = skip_slices(t);
return cg_path_decode_unit(e, unit);
}
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 58eb744..67eeeb5 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -93,6 +93,7 @@ static void test_path_get_user_unit(void) {
check_p_g_u_u("/meh.service", -ENOENT, NULL);
check_p_g_u_u("/session-3.scope/_cpu.service", 0, "cpu.service");
check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/server.service",
0, "server.service");
+
check_p_g_u_u("/user.slice/user-1000.slice/user@1000.service/foobar.slice/foobar@pie.service",
0, "foobar@pie.service");
check_p_g_u_u("/user.slice/user-1000.slice/user@.service/server.service",
-ENOENT, NULL);
}
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] forever loop during garbage collection
On Wed, 10.12.14 15:22, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Sorry for the late reply. > On Mon, Dec 8, 2014 at 8:09 PM, Lennart Poettering > wrote: > > On Sun, 30.11.14 14:38, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > > > >> Hi, > >> > >> We are experiencing an unbreakable loop in manager_dispatch_gc_queue. > >> Problem happens when systemd runs in sysV compatibility mode (Porky > >> enables this). > >> > >> Seems like manager_dispatch_gc_queue's while loop gets stuck and seems > >> like unit_gc_sweep cannot make a decision about the unit. As a result, > >> it marks the unit with offset_unsure and adds the unit back to gc > >> queue. > >> > >> If I am reading the code correctly recursive unit_gc_sweep will never > >> be able to remove the unit from the gc queue if it is referenced by > >> another unit and if another unit is referenced by the unit. > >> > >> A is referenced by B > >> B is referenced by A > > > > So in this case first A will be processed by the GC sweep, it will > > follow the link to B while setting the state to IN_PATH and invoke the > > GC sweep on that. B will then be set to IN_PATH too. GC sweep now > > follows its link back, and up at A again, but this time return quickly > > because its state is set to IN_PATH. Due to this, it will then set B's > > state to UNSURE, and return to A, which in effect will now be set to > > UNSURE too. Now, we return into GC queue dispatch call, which will > > notice that it is UNSURE and uprgade that to BAD, and kill it because > > there's nothin in the unit's dependency network that is clearly a > > GOOD, and hence should be removed. > > > > The essence of cycle breaking here is really in > > manager_dispatch_gc_queue() which uprgades UNSURE to BAD in the end. I > > am not seeing how this could end up in an endless loop hence. > > I have debugged it more and as you have said there is no bug in code > but it takes so long to go out of unit_gc_sweep I thought there is a > forever loop. > > Attached is my patch on 216 and > https://drive.google.com/file/d/0B_uiALgWpGXtZ0VidURxSnVhcDA/view?usp=sharing > is a part of the log after patch. > > It has been 3 hours since I issued "systemctl isolate" and according > to the logs I can see that garbage collection logic is making it's way > back up. I guess it will eventually resolve itself but after so many > hours. Hmm, so, you mean the code works correctly but scales really badly? How many units do you have? > > (Search for "- -" and it is happening every 300.000 lines) > > Problem seemed to be introduced on "95ed329" - Move handling of sysv > initscripts to a generator. Hmm, how precisely do the deps look like the generator creates for you? Any chance you can run "/usr/lib/systemd/system-generators/systemd-sysv-generator /tmp/foo /tmp/foo /tmp/foo", and check what deps it precisely generates in /tmp/foo? I have never seen that the GC scales this badly... > This is totally due to how sysV generator is linking services but I > think slowness on GC can happen on a complex system with many units > linked with each other. > > Thoughts? I am puzzled, quite frankly... 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 3/4] systemctl: edit: further reword error messages
On 2015-01-05 at 17:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 19, 2014 at 05:08:09PM +0300, Ivan Shapovalov wrote:
> > ---
> > src/systemctl/systemctl.c | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> > index 658793e..20c367c 100644
> > --- a/src/systemctl/systemctl.c
> > +++ b/src/systemctl/systemctl.c
> > @@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char
> > **user_home, char **user_runtime, Loo
> >
> > r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
> > if (r < 0)
> > -return log_error_errno(r, "Failed to lookup unit lookup
> > paths: %m");
> > +return log_error_errno(r, "Failed to get unit lookup
> > paths: %m");
> Maybe "query"? "get" is ugly.
OK.
>
> > return 0;
> > }
> > @@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char
> > *new_path, const char *original_path
> >
> > r = tempfn_random(new_path, &t);
> > if (r < 0)
> > -return log_error_errno(r, "Failed to determine temporary
> > filename for %s: %m", new_path);
> > +return log_error_errno(r, "Failed to determine temporary
> > filename for \"%s\": %m", new_path);
> >
> > r = mkdir_parents(new_path, 0755);
> > if (r < 0) {
> > -log_error_errno(r, "Failed to create directories for %s:
> > %m", new_path);
> > +log_error_errno(r, "Failed to create directories for
> > \"%s\": %m", new_path);
> > free(t);
> > return r;
> > }
> > @@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char
> > *new_path, const char *original_path
> > if (r == -ENOENT) {
> > r = touch(t);
> > if (r < 0) {
> > -log_error_errno(r, "Failed to create temporary
> > file %s: %m", t);
> > +log_error_errno(r, "Failed to create temporary
> > file \"%s\": %m", t);
> > free(t);
> > return r;
> > }
> > } else if (r < 0) {
> > -log_error_errno(r, "Failed to copy %s to %s: %m",
> > original_path, t);
> > +log_error_errno(r, "Failed to copy \"%s\" to \"%s\": %m",
> > original_path, t);
> > free(t);
> > return r;
> > }
> > @@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char
> > *unit_name,
> > if (!path_equal(fragment_path, tmp_new_path) &&
> > access(tmp_new_path, F_OK) == 0) {
> > char response;
> >
> > -r = ask_char(&response, "yn", "%s already exists, are you
> > sure to overwrite it with %s? [(y)es, (n)o] ", tmp_new_path, fragment_path);
> > +r = ask_char(&response, "yn", "\"%s\" already exists, are
> > you sure to overwrite it with \"%s\"? [(y)es, (n)o] ", tmp_new_path,
> > fragment_path);
>
> This is not gramatically correct. I think
> "\"%s\" already exists. Overwrite with \"%s\"?..." would be better.
OK.
>
>
> > if (r < 0) {
> > free(tmp_new_path);
> > return r;
> > @@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char
> > *unit_name,
> >
> > r = create_edit_temp_file(tmp_new_path, fragment_path,
> > &tmp_tmp_path);
> > if (r < 0) {
> > -log_error_errno(r, "Failed to create temporary file for
> > %s: %m", tmp_new_path);
> > +log_error_errno(r, "Failed to create temporary file for
> > \"%s\": %m", tmp_new_path);
> > free(tmp_new_path);
> > return r;
> > }
> > @@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
> > assert(args);
> >
> > if (!on_tty()) {
> > -log_error("Cannot edit units if we are not on a tty");
> > +log_error("Not on a tty, refusing.");
> Why? Replacing a nice specific error message with a generic one seems to
> be a step backwards.
I've tried to follow the existing pattern of most error messages in
systemd: "Condition, action + -ing."
I'll reword again to make messages more specific... unless you tell me
to stop bikeshedding and leave it as is ;)
>
> > return -EINVAL;
> > }
> >
> > if (arg_transport != BUS_TRANSPORT_LOCAL) {
> > -log_error("Cannot remotely edit units");
> > +log_error("Remote operation requested, refusing.");
> And the same here.
>
> > return -EINVAL;
> > }
> >
> > @@ -6205,12 +6205,12 @@ static int edit(sd_bus *bus, char **args) {
> > * It's useful if the user wants to cancel its modification
> > */
> > if (null_or_empty_path(*tmp)) {
Re: [systemd-devel] [PATCH 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded
On 2015-02-03 at 23:05 +0100, Lennart Poettering wrote: > On Fri, 19.12.14 17:08, Ivan Shapovalov (intelfx...@gmail.com) wrote: > > What happened to this patch series actually? I think only 1/4 was ever > commited, what about the other ones? Ivan, any chance you can rebase > the rest with Zbigniew's requested changes and post again? Yeah, I've kinda forgotten about this series... Will do. Thanks for the reminder! -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: > This looks like fallout of moving to generators for sysv units. Before > systemd added dependencies on runlevelX.target directly to units built > from initscripts. This forced runlevelX.target resolution and > everything was OK. Now core systemd never references these targets > directly. > > This is a genuine bug which will bite people. But it looks like worked > just by accident before anyway :( So we need possibility to define > aliases for existing units without exhaustive search across all unit > definitions ... may be unit.alias.d? This is a real shortcoming of the current logic in systemd, indeed. So, one possible way out of this might be add a .wants/ dep from multi-user.target.wants/ to runlevel3.target, if runlevel3.target is linked to that. THis would cause runlevel3.target to be loaded, which would then detect the symlink and merge it into multi-user.target. After loading it would try to create the .wants link, but recognize that it is now trying to create a .wants link on itself, and suppress it. These extra .wants symlinks could even be generated dynamically from sysv-generator, so that people can easily override the runlevel mappings by placing a symlink in /etc, without having to manually also add the .wants/ link at the same time... It's a bit ugly, and feels a bit hackish, but should work. Another option would be to actually add expose the internal dependency type "References" to the outside. It's only purpose is to act as reference for the GC logic, thus ensuring that its target is loaded. I am kinda leaning towards the sysv-generator option. Happy to take a patch if anybody wants to hack this up... 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] [ANNOUNCE] systemd v218
On Fri, 12.12.14 15:57, Matthias Urlichs (matth...@urlichs.de) wrote: > Hi, > > Colin Guthrie: > > What's the argument for including /usr/local in all this stuff? Feels > > wrong to me. > > > +ME_TOO. /usr/local frequently has wider permissions than reasonable for > something that can affect system startup. > > I can think of one argument in favor of this -- you can modify the system > default that way, without touching /etc, so this would add local > modifications to an image which you then use for system initialization. > > However, you can do the same thing by adding appropriate *.conf files to > /usr/lib/systemd/**. /usr is OS vendor territory. /usr/local is admin territory. The admin should not modify /usr, ever. 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] virt: add detect_vm_devicetree for powerpc arches
On Tue, 03.02.15 17:56, Chris J Arges (chris.j.ar...@canonical.com) wrote: > Check sysfs devicetree values in order to detect if we are running on a KVM > hypervisor on a powerpc architecture. Looks good! Applied! Thanks! 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] virt: add detect_vm_devicetree for powerpc arches
Check sysfs devicetree values in order to detect if we are running on a KVM
hypervisor on a powerpc architecture.
---
src/shared/virt.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index f10baab..7c1381f 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -101,6 +101,22 @@ static int detect_vm_cpuid(const char **_id) {
return 0;
}
+static int detect_vm_devicetree(const char **_id) {
+#if defined(__powerpc__) || defined(__powerpc64__)
+_cleanup_free_ char *hvtype = NULL;
+int r;
+
+r =
read_one_line_file("/sys/firmware/devicetree/base/hypervisor/compatible",
&hvtype);
+if (r >= 0) {
+if (streq(hvtype, "linux,kvm")) {
+*_id = "kvm";
+return 1;
+}
+}
+#endif
+return 0;
+}
+
static int detect_vm_dmi(const char **_id) {
/* Both CPUID and DMI are x86 specific interfaces... */
@@ -204,6 +220,10 @@ int detect_vm(const char **id) {
if (r != 0)
goto finish;
+r = detect_vm_devicetree(&_id);
+if (r != 0)
+goto finish;
+
if (_id) {
/* "other" */
r = 1;
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
On Tue, 03.02.15 23:22, Jay Faulkner (j...@jvf.cc) wrote: > Hi all, > > As I posted last week, a change merged a while ago to systemd-nspawn > adding seccomp protections with no ability to enable/disable broke > the Ironic Python Agent ramdisk which utilizes CoreOS and > systemd. The attached patch makes the behavior optional, with it > defaulting to disabled. I did this for two reasons; the first being > that my (and other consumers of OpenStack Ironic) use case was > broken, as would anyone else using spawn in this > manner. Additionally, seccomp filters can be configured specifically > as desired in the unit file. This was about allowing kernel module loading from inside nspawn containers? I completely missed that we actually really have seccomp filters to disallow that in place... We hence have two layers of security there to turn off kernel module loading: seccomp and the missing CAP_SYS_MODULE capability. I am not particularly fond of the idea of adding a completely new command line option for this though. Maybe we can find another way for this. For example, one option could be to split the seccomp syscall blacklist in two: split out the kernel kmod related syscalls, and only add them to the seccomp filter if arg_retain does not include CAP_SYS_MODULE. This would then leave the module seccomp filters in place by default, however, if you add the CAP_SYS_MODULE cap to the container with --capability= then the seccomp filter is changed to also allow the module loading syscalls. The patch is corrupted, it includes Windows new lines. If you rework the patch as suggested above, and send it as uncorrupted patch, I'd be happy to merge it. 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] Make seccomp protections in systemd-nspawn optional
For context this puts a toggle on this feature added to nspawn: http://cgit.freedesktop.org/systemd/systemd/commit/?id=28650077f36466d9c5ee27ef2006fae3171a2430 I encouraged Jay to make it an opt-in flag so as to not break other people who had working setups when using nspawn as a minimal ns wrapper. Brandon On Tue, Feb 3, 2015 at 3:22 PM, Jay Faulkner wrote: > Hi all, > > As I posted last week, a change merged a while ago to systemd-nspawn adding > seccomp protections with no ability to enable/disable broke the Ironic Python > Agent ramdisk which utilizes CoreOS and systemd. The attached patch makes the > behavior optional, with it defaulting to disabled. I did this for two > reasons; the first being that my (and other consumers of OpenStack Ironic) > use case was broken, as would anyone else using spawn in this manner. > Additionally, seccomp filters can be configured specifically as desired in > the unit file. > > I appreciate your time and effort in getting this patch merged, so I’ll be > able to upgrade and consume a newer systemd. > > Thanks, > Jay Faulkner > > > > > ___ > 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] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
On 03.02.2015 18:43, David Herrmann wrote: > Hi > > On Tue, Feb 3, 2015 at 6:36 PM, poma wrote: >> On 02.02.2015 19:58, David Herrmann wrote: >>> As I'm not really interested in hacking on network-managers, I've >>> decided to stop working on MiracleCast. If, some day, there's a >>> working P2P stack on linux, I might resurrect it. But it sounds more >>> likely that I'll refer to the Intel solution (WYSIWIDI) instead. >>> There're also gstreamer plugins for WFD now, so maybe give them a try? >>> >> >> gst-rtsp-server-wfd >> https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md >> >> Pre-conditions: >> >> This module is running on established p2p connection with wifi direct, which >> means that you have to setup this network environment to run this module. I >> hope this link would be very helpful. ( >> http://cgit.freedesktop.org/~dvdhrm/miracle ) >> >> You are referring to them, they are referring to you. :) > > They provide a gstreamer plugin for Miracast, but quite frankly didn't > bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack > to provide a P2P link. If NM provides a P2P API, you can just set it > up via nmcli and then use the gst modules to run Miracast (or you can > just use the ConnMan API right now). > > Thanks > David > Well at least there is an open RFE - Network Manager [enh] Add support for WiFi P2P (aka WiFi Direct) https://bugzilla.gnome.org/show_bug.cgi?id=734073 And in this thread I see Patrik Flykt - ConnMan. Connman WiFi p2p API evaluation https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html Let's see if NetworkMan can learn from ConnMan. :) Thanks again for the occurrence. poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Lennart Poettering wrote on 11/12/14 00:16: > > * All systemd programs that read standalone configuration > > files in /etc now also support a corresponding series of > > .conf.d configuration directories in /etc/, /run/, > > /usr/local/lib/, /usr/lib/, and (if configured with > > --enable-split-usr) /lib/. In particular, the following > > configuration files now have corresponding configuration > > directories: system.conf user.conf, logind.conf, > > journald.conf, sleep.conf, bootchart.conf, coredump.conf, > > resolved.conf, timesyncd.conf, journal-remote.conf, and > > journal-upload.conf. Note that distributions should use the > > configuration directories in /usr/lib/; the directories in > > /etc/ are reserved for the system administrator. > > Hmmm, at what point is /usr/local/lib/systemd/journald.conf.d/foo.conf read? > > Does the journal start only after all local filesystems are mounted, I > don't see anything that ensures this in the .service or .socket files > for it (same applies to other tools, but journal is probably most at > risk because it's started early with DefaultDependencies=no) > > It feels very, very odd that /usr/local is being parsed at all here when > the --prefix arg does not include it. I mean this kinda conflicts with > users doing their own compiles with --prefix=/usr/local and installing > stuff there... If the were experimenting, but ultimately didn't want to > use it, it seems odd to me that the actual packaged version of system > would read these files. > > What's the argument for including /usr/local in all this stuff? Feels > wrong to me. Well, /usr/local has very unclear semantics. Installing something into /usr/local if the stuff is never included in any search paths makes it pretty useless. The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff (admin). The whole thing is really not thought to the end though. Some folks have /usr/local on NFS, which we cannot handle, since we'll look into it already before NFS is mounted for some things, and never check it again... Note that even though this is not thought to the end, the current behaviour is perfectly in line with what the XDG basedir spec suggests, which says that /usr/local should be included in the search paths for things... So far we always included it. I can see reasons to keep it that way, I can see reasons way not including might also be a good choice. Currently I don't see strong enough reasons to make the change though. 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] Make seccomp protections in systemd-nspawn optional
Hi all, As I posted last week, a change merged a while ago to systemd-nspawn adding seccomp protections with no ability to enable/disable broke the Ironic Python Agent ramdisk which utilizes CoreOS and systemd. The attached patch makes the behavior optional, with it defaulting to disabled. I did this for two reasons; the first being that my (and other consumers of OpenStack Ironic) use case was broken, as would anyone else using spawn in this manner. Additionally, seccomp filters can be configured specifically as desired in the unit file. I appreciate your time and effort in getting this patch merged, so I’ll be able to upgrade and consume a newer systemd. Thanks, Jay Faulkner systemd-nspawn-seccomp-default-disable.patch Description: systemd-nspawn-seccomp-default-disable.patch ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] VLAN's not coming up "systemd-networkd.service loaded failed" + systemd-networkd seg fault
On Thu, 20.11.14 15:28, Brendan Horan (brendanho...@basstech.net) wrote: > No one has any clue? > Or do I need to provide more information? (if so what?) Hmm, somehow this thread got lost. Is this still an issue with current git? If so could you repost, and we'll have a look at it. Sorry for not responding more timely and for resurrecting this months old thread! 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] Something is removing links from my *.wants/ directory
On Sat, 13.12.14 07:36, Adam Papai (w...@wooh.hu) wrote: > Yeah, something similar is happening. If I edit the container.target and > add the Wants= instead of creating the .wants directory it works well. > > I think the preset-all is "syncing" the config with the .wants directory as > well and removes all links which are not defined in the config. So editing > the unit file solved my issue. You could alternatively pre-gernate a machine ID in /etc/machine-id using "systemd-machine-id-setup". If the file is missing systemd will assume an unpopulated /etc, and run preset-all as first step. I figure we should also change systemd though to ensure that preset-all in that case is purely additive, and does not delete any units. Added this to the TODO list for now. 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] /proc and /sys get unmounted during boot from NFS, which results in boot error
On Tue, 03.02.15 23:00, Olaf Leidinger (ol...@mescharet.de) wrote: > Dear systemd-devel list, > > I'm trying to debug the following problem: > > For some unknown reason, /proc and /sys get unmounted during boot > from a NFS mounted rootfs. Booting to an emergency shell, I can observe > them disappear by first calling mount (which reads from /proc due to > /etc/mtab > being a symlink) and then calling "ls /proc". After calling ls, mount > obviously > complains about not being able to read mtab, instead of listing the mounts as > before. > > A 2nd or 3rd call of mount before listing /proc works fine, too. That's certainly weird. The log you pasted below doesn't show any other commands running, which is particularly weird. Maybe something from your initrd is acting weird? systemd itself mounts /proc and /sys very early during boot, and then never touches them anymore. They are excluded from the usual .mount unit logic in order to ensure they never accidentally disappear... > Booting with debug options yields no further information, no new > messages appear while the debug shell is running and the messages > before are not very interesting (as far as I can tell) [--> end of > mail]. It might be interesting to strace PID 1 while you are doing this. And if that doesn't help strace the other processes you run, to see if any of them unmounts anything. 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] Avoid reloading services when shutting down
On Tue, 03.02.15 23:03, Michael Biebl (mbi...@gmail.com) wrote: > > While I just made this scenario up I think it's actually quite > > realistic, and I think it's a valid thing for admins to do > > Well, we could easily check if DefaultDependencies=yes in this case. > Actually, this is already what we do for the boot case. [1] > > So even with your made-up example, it would work. > > >> The thing is, you have to be extra careful to never, ever call a > >> restart/reload from such hook scripts. If those are triggered via > >> service or systemctl on a native or SysV script doesn't make a > >> difference. > > > > It is completely fine to enqueue restarts and reloads from hook > > scripts. However the emphasis is on *enqueue*. The issue is that you > > block on it, you shouldn't do that. > > > > On Fedora, iscsi is reloaded from an NM callout. If you ask me that's > > frickin' ugly, but it *is* supported as long as iscsi's reload is > > queued asynchronously instead of requested synchronously. In Fedora, > > the logic to make this async sits on the client side of things, it's > > not enforced by the engine in PID 1. > > > > The same really applies to Debian too... > > > >> It's simply to easy to cause a dead lock this way, and I think systemd > >> should try much harder to avoid such situations. > > > > Well, it would be great if we could solve the halting problem. But we > > can't. > > > > I mean, I am all ears regarding adding deadlock detection code. But I > > am really not convinced that breaking the engine for *everybody* just > > because *some* clients are weird is an option. > > Calling it "breaking the engine for everybody" is hyperbole. > > That said, do you have better ideas how we could avoid having systemd > easily being dead-locked on shutdown? > I'm all for solving it in a nicer way. But simply throwing the hands > in the air and saying, not our problem, doesn't help. I made a clear recommendation: whenever commands are converted from sysv operations into systemctl operations, then add --no-block or --job-mode=ignore-deps to the systemctl command line, after checking that you are in startup or shutdown mode. Why wouldn't that suffice? 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] cryptsetup: Do not warn If the key is /dev/*random
On Tue, 03.02.15 14:18, Josh Triplett (j...@joshtriplett.org) wrote:
> On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
> > On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org)
> > wrote:
> >
> > > Using /dev/urandom as a key is valid for swap, do not
> > > warn if this devices are world readable.
> > > ---
> > > src/cryptsetup/cryptsetup.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
> > > index e6b37ac..38930ae 100644
> > > --- a/src/cryptsetup/cryptsetup.c
> > > +++ b/src/cryptsetup/cryptsetup.c
> > > @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
> > >
> > > /* Ideally we'd do this on the open fd, but
> > > since this is just a
> > > * warning it's OK to do this in two steps. */
> > > -if (stat(key_file, &st) >= 0 && (st.st_mode &
> > > 0005))
> > > -log_warning("Key file %s is
> > > world-readable. This is not a good idea!", key_file);
> > > +if (stat(key_file, &st) >= 0 && (st.st_mode &
> > > 0005)) {
> > > +if(!STR_IN_SET(key_file, "/dev/urandom",
> > > "/dev/random", "/dev/hw_random"))
> > > +log_warning("Key file %s is
> > > world-readable. This is not a good idea!", key_file);
> > > +}
> >
> > I'd prefer if we'd change the check instead to only apply to
> > S_ISREG() files. This way we wouldn't have to list all RNG device
> > nodes.
>
> With the exception of /dev/*random, you don't want a world-readable
> device used for a key either. Some people have setups that use a USB
> device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
> case, the file should *not* be world-readable.
Strictly speaking that is true. But this is really just a safety net
(and only a warning) for files people create, where they forgot to set
the right perms. However, device nodes are not created by people, but
by devtmpfs and adjusted by udev, and hence are very unlikely to be
incorrect. I mean, there's little point to protect systemd-cryptsetup
from systemd-udevd, if you follow what I mean.
I really prefer not having to include the whitelist of devices here...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error
Dear systemd-devel list, I'm trying to debug the following problem: For some unknown reason, /proc and /sys get unmounted during boot from a NFS mounted rootfs. Booting to an emergency shell, I can observe them disappear by first calling mount (which reads from /proc due to /etc/mtab being a symlink) and then calling "ls /proc". After calling ls, mount obviously complains about not being able to read mtab, instead of listing the mounts as before. A 2nd or 3rd call of mount before listing /proc works fine, too. This happens on an gentoo-amd64 system using kernel 3.18.5 and systemd-218. Booting with debug options yields no further information, no new messages appear while the debug shell is running and the messages before are not very interesting (as far as I can tell) [--> end of mail]. Booting the very same installation with the same initramfs from a disk works fine, even when forcing the disk to be mounted read-only, as the NFS share is. About a year ago, I installed a number-crunching cluster, whose nodes are running from a read-only NFS share. This was also a gentoo based system running systemd-215. Stuff works fine, there. Thus, I tried version 215 and even 216 for the new installation, too, yet without success. What might cause systemd to unmount /proc and /sys? Or might this issue not be related to systemd at all? Thanks for your input! Olaf # [] [leading kernel messages skipped] [ 17.857082] systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpu,cpuacct of type cgroup with options cpu,cpuacct. [ 17.857308] systemd[1]: Mounting cgroup to /sys/fs/cgroup/memory of type cgroup with options memory. [ 17.857505] systemd[1]: Mounting cgroup to /sys/fs/cgroup/devices of type cgroup with options devices. [ 17.857694] systemd[1]: Mounting cgroup to /sys/fs/cgroup/net_cls of type cgroup with options net_cls. [ 17.857882] systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpuset of type cgroup with options cpuset. [ 17.858073] systemd[1]: Mounting cgroup to /sys/fs/cgroup/freezer of type cgroup with options freezer. [ 17.858258] systemd[1]: Mounting cgroup to /sys/fs/cgroup/blkio of type cgroup with options blkio. [ 17.858479] systemd[1]: systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) [ 17.860362] systemd[1]: Detected architecture 'x86-64'. [ 17.879066] systemd[1]: Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd. [ 17.879273] systemd[1]: Installed release agent. [ 17.879434] systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. [ 17.882492] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-debug-generator as 161. [ 17.882782] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-gpt-auto-generator as 162. [ 17.883095] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-getty-generator as 163. [ 17.883403] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-system-update-generator as 164. [ 17.883685] systemd[160]: Spawned /usr/lib/systemd/system-generators/gentoo-local-generator as 165. [ 17.883969] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-efi-boot-generator as 166. [ 17.884273] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-fstab-generator as 167. [ 17.884565] systemd[160]: Spawned /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator as 168. [ 17.923410] systemd-efi-boot-generator[166]: Not an EFI boot, exiting. [ 17.923445] systemd-fstab-generator[167]: Parsing /etc/fstab [ 17.925772] systemd-fstab-generator[167]: Found entry what=134.96.30.183:/exports/raid/client/distribution/gentoo-amd64 where=/ type=nfs nofail=no noauto=no [ 17.926259] systemd-gpt-auto-generator[162]: Not a EFI boot, not creating root mount. [ 17.987813] systemd-gpt-auto-generator[162]: Root file system not on a (single) block device. [ 17.987848] systemd-fstab-generator[167]: Found entry what=home-srv:/home where=/home type=nfs nofail=yes noauto=no [ 17.988250] systemd[160]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator succeeded. [ 17.988422] systemd[160]: /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator succeeded. [ 17.988582] systemd[160]: /usr/lib/systemd/system-generators/systemd-debug-generator succeeded. [ 17.988745] systemd[160]: /usr/lib/systemd/system-generators/systemd-getty-generator succeeded. [ 17.988900] systemd[160]: /usr/lib/systemd/system-generators/systemd-system-update-generator succeeded. [ 18.090371] systemd[160]: /usr/lib/systemd/system-generators/gentoo-local-generator succeeded. [ 18.090528] systemd[160]: /usr/lib/systemd/system-generators/systemd-fstab-generator succeeded. [ 18.090680] systemd[160]: /usr/lib/systemd/system-generators/systemd-efi-boot-generator succeeded.
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Tue, 2015-02-03 at 19:00 +, Keller, Jacob E wrote: > Hey, > > I've recently been using systemd-networkd to great success on a few of > my machines here. However I ran into an interesting problem on at least > 2 machines so far. I've included the output of journal for > systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was > suggested on another post. In addition the only network file I have > configured is em0.network which contains the following, > Short answer: I removed biosdevname and then it was all happy. This seems like a problem or delay in how long biosdevname takes to indicate the name and honestly systemd persistent names are better anyways. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
Lennart Poettering wrote: > Hmm, so, I thought a lot about this in the past weeks. I think the way > I'd really like to see this work in the end is that we never have to > persist the UID mappings. This could work if the kernel would provide > us with the ability to bind mount a file system into the container > applying a fixed UID shift. That way, the shifted UIDs would never hit > the actual disk, and hence we wouldn't have to persist their mappings. It ought to be possible to run an arbitrary distribution inside a container, even a distribution that itself wants to run sandboxed applications in containers. Nesting matters, so a bare shift may not suffice. On the other hand, a shift is the simplest solution for simple utility containers, such as those launched by systemd-nspawn. nspawn could trivially avoid persisting the UID map by applying a shift, while a full container solution might want to construct persistent dynamic UID maps, or integrate with special PAM/NSS modules, or any number of other creative solutions. Container UID handling was exactly what I had in mind when I sent in a kernel patch for the setusers() system call. If an unprivileged user on the host system can have a pile of UIDs handed to them by the host system, and can use any of those IDs in their UID map, then they can set up any arbitrary container UID handling without further assistance from host root. A PAM module on the host could then, by policy, hand some or all unprivileged users a substantial stack of host UIDs that they can arbitrarily map to container UIDs; together with support for applying UID maps to a mounted filesystem, that would provide all the necessary kernel support. In addition to containers, that would also provide a sensible solution for a smarter fakeroot-style tool that lets a user construct filesystems with slightly more complicated policies than "root owns everything", again without any help from host root other than "here, have a pile of subordinate UIDs". I'd be happy to revisit kernel setusers() support if anyone would be interested in saying "yes, this is the solution we want". - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Container, private network and socket activation
Am 03.02.2015 um 22:06 schrieb Lennart Poettering: > Socket activation is somethings daemons need to support > explicitly. Many do these days, but I don't think Apache is one of > them. FYI: all released versions (i.e. up to 2.4.x) of Apache httpd don't support it yet, but the current development version does - at least if you compile it with the corresponding options (no module needs to be loaded for that, it's in the core). There's a proposal to backport that and sd_notify integration[1] to the stable 2.4.x branch, but nothing's happened so far: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1656674&view=markup#l138 [1] Although Fedora apparently already includes sd_notify integration for quite a while now, but no socket activation... Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random
On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
> On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org)
> wrote:
>
> > Using /dev/urandom as a key is valid for swap, do not
> > warn if this devices are world readable.
> > ---
> > src/cryptsetup/cryptsetup.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
> > index e6b37ac..38930ae 100644
> > --- a/src/cryptsetup/cryptsetup.c
> > +++ b/src/cryptsetup/cryptsetup.c
> > @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
> >
> > /* Ideally we'd do this on the open fd, but since
> > this is just a
> > * warning it's OK to do this in two steps. */
> > -if (stat(key_file, &st) >= 0 && (st.st_mode &
> > 0005))
> > -log_warning("Key file %s is
> > world-readable. This is not a good idea!", key_file);
> > +if (stat(key_file, &st) >= 0 && (st.st_mode &
> > 0005)) {
> > +if(!STR_IN_SET(key_file, "/dev/urandom",
> > "/dev/random", "/dev/hw_random"))
> > +log_warning("Key file %s is
> > world-readable. This is not a good idea!", key_file);
> > +}
>
> I'd prefer if we'd change the check instead to only apply to
> S_ISREG() files. This way we wouldn't have to list all RNG device
> nodes.
With the exception of /dev/*random, you don't want a world-readable
device used for a key either. Some people have setups that use a USB
device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
case, the file should *not* be world-readable.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libabc: Make things hold a reference to their context
On Mon, Dec 8, 2014 at 10:12 PM, Josh Triplett wrote: > The sample libabc includes functions to get a "thing", as a sample > sub-object of the overall library context. Each "thing" has a reference > to the parent library context, and a function to return that reference. > Given that, abc_thing_new_from_string should call abc_ref, and > abc_thing_unref should call abc_unref when freeing a thing. > --- > src/libabc.c | 3 ++- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded
On Fri, 19.12.14 17:08, Ivan Shapovalov (intelfx...@gmail.com) wrote:
What happened to this patch series actually? I think only 1/4 was ever
commited, what about the other ones? Ivan, any chance you can rebase
the rest with Zbigniew's requested changes and post again?
Thanks,
Lennart
> "Not found" condition in find_paths_to_edit() has been made non-fatal
> because the error message in edit() ("Cannot find any units to edit")
> suggests that.
>
> Error messages in edit() themselves have been removed because
> - result of expand_names() is not checked anywhere else
> - an extra "cannot find any units to edit" is redundant due to error reporting
> for each unit in unit_find_paths() and find_paths_to_edit()
> ---
> src/systemctl/systemctl.c | 53
> +++
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 7af111c..658793e 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -2325,9 +2325,12 @@ static int unit_find_paths(sd_bus *bus,
>
> if (!avoid_bus_cache && !unit_name_is_template(unit_name)) {
> _cleanup_bus_error_free_ sd_bus_error error =
> SD_BUS_ERROR_NULL;
> +_cleanup_bus_message_unref_ sd_bus_message *unit_load_error
> = NULL;
> _cleanup_free_ char *unit = NULL;
> _cleanup_free_ char *path = NULL;
> _cleanup_strv_free_ char **dropins = NULL;
> +_cleanup_strv_free_ char **load_error = NULL;
> +char *unit_load_error_name, *unit_load_error_message;
>
> unit = unit_dbus_path_from_name(unit_name);
> if (!unit)
> @@ -2336,6 +2339,31 @@ static int unit_find_paths(sd_bus *bus,
> if (need_daemon_reload(bus, unit_name) > 0)
> warn_unit_file_changed(unit_name);
>
> +r = sd_bus_get_property(
> +bus,
> +"org.freedesktop.systemd1",
> +unit,
> +"org.freedesktop.systemd1.Unit",
> +"LoadError",
> +&error,
> +&unit_load_error,
> +"(ss)");
> +if (r < 0)
> +return log_error_errno(r, "Failed to get LoadError:
> %s", bus_error_message(&error, r));
> +
> +r = sd_bus_message_read(
> +unit_load_error,
> +"(ss)",
> +&unit_load_error_name,
> +&unit_load_error_message);
> +if (r < 0)
> +return bus_log_parse_error(r);
> +
> +if (!isempty(unit_load_error_name)) {
> +log_error("Unit %s is not loaded, ignoring: %s",
> unit_name, unit_load_error_message);
> +return 0;
> +}
> +
> r = sd_bus_get_property_string(
> bus,
> "org.freedesktop.systemd1",
> @@ -2403,6 +2431,10 @@ static int unit_find_paths(sd_bus *bus,
> r = unit_file_find_dropin_paths(lp->unit_path, NULL,
> names, dropin_paths);
> }
>
> +if (r == 0) {
> +log_error("No files found for unit %s, ignoring.",
> unit_name);
> +}
> +
> return r;
> }
>
> @@ -4780,10 +4812,8 @@ static int cat(sd_bus *bus, char **args) {
> r = unit_find_paths(bus, *name, avoid_bus_cache, &lp,
> &fragment_path, &dropin_paths);
> if (r < 0)
> return r;
> -else if (r == 0) {
> -log_warning("Unit %s does not have any files on
> disk", *name);
> +else if (r == 0)
> continue;
> -}
>
> if (first)
> first = false;
> @@ -6114,9 +6144,13 @@ static int find_paths_to_edit(sd_bus *bus, char
> **names, char ***paths) {
> r = unit_find_paths(bus, *name, avoid_bus_cache, &lp, &path,
> NULL);
> if (r < 0)
> return r;
> -else if (r == 0 || !path)
> +else if (r == 0)
> +continue;
> +else if (!path) {
> // FIXME: support units with path==NULL (no
> FragmentPath)
> -return log_error_errno(ENOENT, "Unit %s not found,
> cannot edit.", *name);
> +log_error("No fragment exists for unit %s,
> ignoring.");
> +continue;
> +}
>
> if (arg_full)
> r = unit_f
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
2015-02-03 22:38 GMT+01:00 Lennart Poettering : > On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote: > >> 2015-02-03 22:10 GMT+01:00 Lennart Poettering : >> > I don't see how this would apply to non-sysv code. I mean, code that >> > is written with systemd semantics in mind should be able to issue a >> > service reload during any time it wants to, if it keeps the ordering >> > issues in mind. For example, if I have a service that has >> > DefaultDependencies=no (and hence ordered against nothing at all by >> > default), and I want to issue systemctl reload on it, knowing that >> > this cannot really deadlock, since there are no deps that could cause >> > deadlocks, then i should be able to do so. With your patch you turn >> > these reloads into NOPs... >> >> During shutdown (and early boot), yes. But why would you want to >> schedule a restart or reload during shutdown? > > Well, we try to keep reloads out of the default codepaths, but it's > easy to construct cases where people might want to deviate fromt the > default codepaths. > >> Do you have a real-world example for that? > > Consider systemd-journald.service. It's a service with > DefaultDependencies=no. We don't terminate it as part of the normal > shutdown, we leave that to the final killing spree, so that we have > logging for as long as possible. > > Now, people might want to hack something up that changes journald > configuration to forward logs to kmsg during the last part of > shutdown, so that they can see it in netconsole or so. SO they write > their little service that patches journald.conf and restarts journald, > and this is done during shutdown from a normal service's ExecStop= > line. This normally works fine, since journald is not ordered against > anything that matters. But it doesn't work on Debian, because on > Debian there's no way anymore to restart journald as soon as shutdown > commenced... > > While I just made this scenario up I think it's actually quite > realistic, and I think it's a valid thing for admins to do Well, we could easily check if DefaultDependencies=yes in this case. Actually, this is already what we do for the boot case. [1] So even with your made-up example, it would work. >> The thing is, you have to be extra careful to never, ever call a >> restart/reload from such hook scripts. If those are triggered via >> service or systemctl on a native or SysV script doesn't make a >> difference. > > It is completely fine to enqueue restarts and reloads from hook > scripts. However the emphasis is on *enqueue*. The issue is that you > block on it, you shouldn't do that. > > On Fedora, iscsi is reloaded from an NM callout. If you ask me that's > frickin' ugly, but it *is* supported as long as iscsi's reload is > queued asynchronously instead of requested synchronously. In Fedora, > the logic to make this async sits on the client side of things, it's > not enforced by the engine in PID 1. > > The same really applies to Debian too... > >> It's simply to easy to cause a dead lock this way, and I think systemd >> should try much harder to avoid such situations. > > Well, it would be great if we could solve the halting problem. But we > can't. > > I mean, I am all ears regarding adding deadlock detection code. But I > am really not convinced that breaking the engine for *everybody* just > because *some* clients are weird is an option. Calling it "breaking the engine for everybody" is hyperbole. That said, do you have better ideas how we could avoid having systemd easily being dead-locked on shutdown? I'm all for solving it in a nicer way. But simply throwing the hands in the air and saying, not our problem, doesn't help. Things like that hurt our users badly. systemd should always try to get into a usable state, i.e. to boot into state where one can log in, or shutdown/reboot successfully. As much as I like systemd, it's really easy to break it currently and it would be awesome if it was more robust in such situations. Michael [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Avoid-reload-and-re-start-requests-during-early-boot.patch -- 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] Do not realize and migrate cgroups multiple times / test suite patch
On Sat, 13.12.14 17:15, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello Lennart, > > Lennart Poettering [2014-12-09 2:37 +0100]: > > hashmap_put() will actually compare the string, not the pointer to > > it. Our hashmap implementation gets a hash function pointer as well as > > an element comparison function as input, to ensure that that works > > correctly. > > Ah right. I understand how these work now, and I extended the test > case to cover this case (equal key, but different pointer). The patch for this has been merged, apparently. > However, unit_create_cgroups() still seems to be quite wasteful: It > still gets called dozens of time for -.slice for every unit that gets > started, and thus calls cg_create_everywhere() for the already > existing cgroup. Why doesn't this function just check if > u->cgroup_path already exists, and if so just return right away? Are > there situations where the same unit cgroup needs to be realized and > pids migrated to it multiple times? unit_create_cgroups() is invoked from unit_realize_cgroup_now(), which exits early if the unit is already realized for all controllers that the unit needs. Thus, unit_create_cgroups() should not be called that often, but only when the mask of controllers to realize changes. 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] Avoid reloading services when shutting down
On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote: > 2015-02-03 22:10 GMT+01:00 Lennart Poettering : > > I don't see how this would apply to non-sysv code. I mean, code that > > is written with systemd semantics in mind should be able to issue a > > service reload during any time it wants to, if it keeps the ordering > > issues in mind. For example, if I have a service that has > > DefaultDependencies=no (and hence ordered against nothing at all by > > default), and I want to issue systemctl reload on it, knowing that > > this cannot really deadlock, since there are no deps that could cause > > deadlocks, then i should be able to do so. With your patch you turn > > these reloads into NOPs... > > During shutdown (and early boot), yes. But why would you want to > schedule a restart or reload during shutdown? Well, we try to keep reloads out of the default codepaths, but it's easy to construct cases where people might want to deviate fromt the default codepaths. > Do you have a real-world example for that? Consider systemd-journald.service. It's a service with DefaultDependencies=no. We don't terminate it as part of the normal shutdown, we leave that to the final killing spree, so that we have logging for as long as possible. Now, people might want to hack something up that changes journald configuration to forward logs to kmsg during the last part of shutdown, so that they can see it in netconsole or so. SO they write their little service that patches journald.conf and restarts journald, and this is done during shutdown from a normal service's ExecStop= line. This normally works fine, since journald is not ordered against anything that matters. But it doesn't work on Debian, because on Debian there's no way anymore to restart journald as soon as shutdown commenced... While I just made this scenario up I think it's actually quite realistic, and I think it's a valid thing for admins to do > The thing is, you have to be extra careful to never, ever call a > restart/reload from such hook scripts. If those are triggered via > service or systemctl on a native or SysV script doesn't make a > difference. It is completely fine to enqueue restarts and reloads from hook scripts. However the emphasis is on *enqueue*. The issue is that you block on it, you shouldn't do that. On Fedora, iscsi is reloaded from an NM callout. If you ask me that's frickin' ugly, but it *is* supported as long as iscsi's reload is queued asynchronously instead of requested synchronously. In Fedora, the logic to make this async sits on the client side of things, it's not enforced by the engine in PID 1. The same really applies to Debian too... > It's simply to easy to cause a dead lock this way, and I think systemd > should try much harder to avoid such situations. Well, it would be great if we could solve the halting problem. But we can't. I mean, I am all ears regarding adding deadlock detection code. But I am really not convinced that breaking the engine for *everybody* just because *some* clients are weird is an option. 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] Unit files on another partition
On Fri, 12.12.14 16:06, D.S. Ljungmark (spi...@aanstoot.se) wrote: Sorry for the late reply, and resurrecting this old thread, I am still busy processing the remaining unanswered mails and patches from the last months. I think we talked about this at FOSDEM quickly now? Anyway: > hi, > Our / partitions are on a squashfs media, which means that unit files > are read-only. There is a partition for read-write content > (Scratchable), and I'm wondering if it would be possible to add > unit-files there and have the boot order cope with this correctly? Not really. systemd is kinda designed to calculate an initial transaction that is as complete as possible as early as possible. If you have units not mounted then they cannot be taken into consideration. Two options: a) You pre-mount your unit dir filesystem in your initrd before transitioning into the host OS, so that the host's systemd has all unit files accessible from the first instant on. b) You reload configuration once during boot, after you mounted the unit dir fs. I think a) is the nicer solution. generally we try to keep reloads out of the default code paths, since they are slow and ugly, but that's just the default code paths, local setups are welcome to add reloads where necessary. Minor caveat: currently, if you have a Type=oneshot service with multiple ExecStart= lines issuing the reload might have the result that we execute some lines multiple times, because there's not clear way to know where to continue execution in that case... Hope this is still useful, 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] Avoid reloading services when shutting down
2015-02-03 22:10 GMT+01:00 Lennart Poettering : > I don't see how this would apply to non-sysv code. I mean, code that > is written with systemd semantics in mind should be able to issue a > service reload during any time it wants to, if it keeps the ordering > issues in mind. For example, if I have a service that has > DefaultDependencies=no (and hence ordered against nothing at all by > default), and I want to issue systemctl reload on it, knowing that > this cannot really deadlock, since there are no deps that could cause > deadlocks, then i should be able to do so. With your patch you turn > these reloads into NOPs... During shutdown (and early boot), yes. But why would you want to schedule a restart or reload during shutdown? Do you have a real-world example for that? The thing is, you have to be extra careful to never, ever call a restart/reload from such hook scripts. If those are triggered via service or systemctl on a native or SysV script doesn't make a difference. It's simply to easy to cause a dead lock this way, and I think systemd should try much harder to avoid such situations. -- 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] Fail to reset-failed as user
On Fri, 12.12.14 16:06, Olivier Brunel (j...@jjacky.com) wrote: Sorry for resurrecting this old thread this late. Is this still an issue? Does this work on current git? > Today I had one unit in failed state, and after taking care of things I > wanted to simply reset its state (to inactive) w/out having to start it. > > Looking up the man page, I see there's a command reset-failed for this > exact purpose, awesome. So I go: > > % systemctl reset-failed backups2.service > Failed to reset failed state of unit backups2.service: No such device or > address Hmm, did you issue this from some weird environment (su/sudo context, from a system service context or so?) If this is still an issue, could you try to reproduce this after issuing "systemd-analyze set-log-level debug"? Then please attach the log output this generates! Thanks, 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] [systemd-commits] src/bus-proxyd src/login src/machine src/nspawn src/tmpfiles
On Tue, 03.02.15 09:04, Thomas H.P. Andersen (pho...@gmail.com) wrote:
> On Tue, Feb 3, 2015 at 12:50 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Feb 02, 2015 at 02:07:37PM -0800, Thomas H.P. Andersen wrote:
> >> --- a/src/nspawn/nspawn.c
> >> +++ b/src/nspawn/nspawn.c
> >> @@ -3610,7 +3610,6 @@ int main(int argc, char *argv[]) {
> >> }
> >>
> >> if (arg_ephemeral) {
> >> -_cleanup_release_lock_file_ LockFile
> >> original_lock = LOCK_FILE_INIT;
> >> char *np;
> >>
> >> /* If the specified path is a mount point we
> >> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> >> index 930b9a6..443851a 100644
> >> --- a/src/tmpfiles/tmpfiles.c
> >> +++ b/src/tmpfiles/tmpfiles.c
> >> @@ -630,7 +630,7 @@ static int get_xattrs_from_arg(Item *i) {
> >>
> >> while ((r = unquote_first_word(&p, &xattr, false)) > 0) {
> >> _cleanup_free_ char *tmp = NULL, *name = NULL,
> >> -*value = NULL, *value2 = NULL, *_xattr = xattr;
> >> +*value = NULL, *value2 = NULL;
> > This leaks xattr, no?
>
> oh, you are right. I will revert that.
For the sake of the archives: Thomas apparently fixed this now in git.
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] Avoid reloading services when shutting down
On Tue, 03.02.15 21:58, Michael Biebl (mbi...@gmail.com) wrote: > 2015-02-03 21:52 GMT+01:00 Lennart Poettering : > > > > But note that this way you alter *all* queued jobs that way, > > regardless if they are created with the assumptions of sysv behaviour > > or if they were created in code that understands systemd's semantics, > > and actually cares for the correct ordering.. > > The patch does not alter any ordering, it simply throws away > reload/restart requests, which would be pointless anyway. Well, OK, "cares for execution of the jobs", then. > > I'd strongly recommend finding local solutions to the problems at hand > > here, rather than changing behaviour for all other non-sysv code as > > well... > > Maybe this is an misunderstanding, but this issue is not sysv specific at all. I don't see how this would apply to non-sysv code. I mean, code that is written with systemd semantics in mind should be able to issue a service reload during any time it wants to, if it keeps the ordering issues in mind. For example, if I have a service that has DefaultDependencies=no (and hence ordered against nothing at all by default), and I want to issue systemctl reload on it, knowing that this cannot really deadlock, since there are no deps that could cause deadlocks, then i should be able to do so. With your patch you turn these reloads into NOPs... 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] Container, private network and socket activation
On Tue, 03.02.15 20:45, Mikhail Morfikov (mmorfi...@gmail.com) wrote: > > Also note that using socket activation for cotnainers means that > > systemd instance inside the container also needs to have configuration > > for the socket, to pass it on to the service that ultimately shall > > answer for it. Are you sure that apache2 has support for that, and > > that you set it up? > > Actually, I just want to start the container when someone else tries to > connect to the port 80 of the host, just using the container's IP > address. So, for instance, my host has IP 192.168.1.150, the container > has IP 192.168.10.10 , and I want to type the second address in a web > browser so the system in the container could boot and start apache. Hmm, to implement something like this I think the best option would be to set up the interface to later pass to the container first on the host, then listen on the container's IP address on the host. When a connection comes in the container would have to be started via socket activation, and would then have to take over the container interface (with --network-interface=), so that all further connections are delivered directly to the container and the host is not involved anymore. This way you'd still have two seperate network namespaces, but the interface would change namespace during activation of the container, so that first the host owns it and processes it and then the container. Of course, either way you'd need socket activation support in your Apache. And I don't think Apache provides that right now out of the box... Also note that ther's a slight security risk here: the socket that is used for activation is from the hosts's namespace. Using the old BSD netdev ioctls like SIOCGIFCONF will reveal the host's network setup, not the container's setup. > Then I could browse the page that is hosted by the apache server inside > of the container. I'm not sure if that's even possible, but apache > inside of the container starts at boot automatically, so I think there's > no need for setting anything in the container -- please correct me if > I'm wrong. Socket activation is somethings daemons need to support explicitly. Many do these days, but I don't think Apache is one of them. 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] Avoid reloading services when shutting down
2015-02-03 21:52 GMT+01:00 Lennart Poettering : > > But note that this way you alter *all* queued jobs that way, > regardless if they are created with the assumptions of sysv behaviour > or if they were created in code that understands systemd's semantics, > and actually cares for the correct ordering.. The patch does not alter any ordering, it simply throws away reload/restart requests, which would be pointless anyway. > I'd strongly recommend finding local solutions to the problems at hand > here, rather than changing behaviour for all other non-sysv code as > well... Maybe this is an misunderstanding, but this issue is not sysv specific at all. -- 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] [PATCH] Avoid reloading services when shutting down
On Tue, 03.02.15 20:50, Michael Biebl (mbi...@gmail.com) wrote: > >> Another option might be to pass --job-mode=ignore-dependencies instead > >> of --no-block, which was created for usecases like this, even though > >> it is frickin' ugly... > > > > For reload that should be fairly okay, as reload will quickly fail if > > the unit isn't actually running, and if it is running its dependencies > > already ought to be satisfied. > > > > I'll look into both, thanks for the hints! > > Keep in mind though, that you'll need to not only update "service", > but also invoke-rc.d and the lsb-hook, which is used when someone > calls /etc/init.d/foo directly. > > It's also magnitudes less efficient to spawn external binaries to get > the system state then doing this check from within systemd itself. > > So I'm not really convinced that shifting the responsibility here to > the scripts themselves is the better approach. But note that this way you alter *all* queued jobs that way, regardless if they are created with the assumptions of sysv behaviour or if they were created in code that understands systemd's semantics, and actually cares for the correct ordering.. I'd strongly recommend finding local solutions to the problems at hand here, rather than changing behaviour for all other non-sysv code as well... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] test-capabilities fail and systemd-timesyncd broken
Hi, This commit 51ddf61540976fc7b09ce5 solved systemd-resolved, but broke systemd-timesyncd. Atleast on my system. dbuch@dbuch-laptop ~ % lscpu | grep -i "byte" Byte Order:Little Endian dbuch@dbuch-laptop ~ % SYSTEMD_LOGLEVEL=debug sudo /usr/lib/systemd/systemd-timesyncd Failed to enable capabilities bits: Invalid argument I suspect the usage of log2u64() is wrong? Im not able to gork this, but hope this helps :) Kind regards, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
True, but it's better than nothing. Well, I guess systemd-networkd doing basic things will have to wait on kdbus :-) On Tue, Feb 3, 2015 at 3:32 PM, Lennart Poettering wrote: > 1;3802;0cOn Tue, 03.02.15 14:38, Charles Devereaux (syst...@guylhem.net) > wrote: > > > On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering < > lenn...@poettering.net> > > wrote: > > > > > I am pretty sure signals are not a particularly good interface for > > > this. We should add a proper bus API for this one day, but this kinda > > > has to wait until kdbus is a done deal, since networkd runs in early > > > boot, and dbus-daemon is not available in early boot. > > > > Which would be a good usecase for signals (until kdbus happens, which > might > > take some time) > > Signals are asynchronous, which makes them a lot less useful to use, > since you cannot wait resonably for completion the operation you request. > > 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] Avoid reloading services when shutting down
On Tue, 03.02.15 20:36, Martin Pitt (martin.p...@ubuntu.com) wrote: > Lennart Poettering [2015-02-03 18:10 +0100]: > > I am very strongly against adding hacky work-arounds like this to PID > > Yeah, indeed. This is why I asked for a more elegant approach, and > indeed the --no-block or --job-mode=ignore-dependencies sound like > slightly better approaches to this. I'll test these more thoroughly > tomorrow, thanks for pointing out! > > > 1. The deadlocks are deadlocks, and implying --no-block if we are in > > shutdown mode is a pretty drastic hack I think that special cases one > > peculiar case way too much. > > Right, the problem is of course more generic. Any set of jobs (i. e. a > transaction) which causes (maybe through some indirection) one of its > job members to get restarted/reloaded will suffer from this deadlock > problem, AFAIUI. Booting and shutdown are therefore mostly affected by > this as pretty much every other time there the pending transactions > are only very small. It's really about synchronous waiting on jobs. If you synchronously wait for completion of jobs that are ordered against the job your are part of yourself, then things will deadlock. This can happen in many contexts. You can fix this by: a) changing from synchronous to asynchronous operation or b) removing the ordering (either individually for the job, or generically forever in the unit) Now, regardless which option you choose it's always a good idea to keep this change as local as possible. Altering the state engine for all operations is the worst solution... 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] slow systemd-networkd DHCP client on wlan0 with systemd v217
1;3802;0cOn Tue, 03.02.15 14:38, Charles Devereaux (syst...@guylhem.net) wrote: > On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering > wrote: > > > I am pretty sure signals are not a particularly good interface for > > this. We should add a proper bus API for this one day, but this kinda > > has to wait until kdbus is a done deal, since networkd runs in early > > boot, and dbus-daemon is not available in early boot. > > Which would be a good usecase for signals (until kdbus happens, which might > take some time) Signals are asynchronous, which makes them a lot less useful to use, since you cannot wait resonably for completion the operation you request. 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] Avoid reloading services when shutting down
2015-02-03 20:36 GMT+01:00 Martin Pitt : > Lennart Poettering [2015-02-03 18:10 +0100]: >> I am very strongly against adding hacky work-arounds like this to PID > > Yeah, indeed. This is why I asked for a more elegant approach, and > indeed the --no-block or --job-mode=ignore-dependencies sound like > slightly better approaches to this. I'll test these more thoroughly > tomorrow, thanks for pointing out! The current patch we ship in Debian is admittedly not the nicest one, but it solves a very real issue which affects a lot of non-trivial setups. >> 1. The deadlocks are deadlocks, and implying --no-block if we are in >> shutdown mode is a pretty drastic hack I think that special cases one >> peculiar case way too much. > > Right, the problem is of course more generic. Any set of jobs (i. e. a > transaction) which causes (maybe through some indirection) one of its > job members to get restarted/reloaded will suffer from this deadlock > problem, AFAIUI. Booting and shutdown are therefore mostly affected by > this as pretty much every other time there the pending transactions > are only very small. > >> My recommendation would be to stick this into your /usr/bin/service >> compat glue. Use the state string "systemctl is-system-running" >> outputs to check if you are shutting down. If so, add --no-block to >> the params you pass to systemctl. > > That actually sounds like just what's needed here. is-system-running > will also neatly cover the corresponding case on bootup. > >> Another option might be to pass --job-mode=ignore-dependencies instead >> of --no-block, which was created for usecases like this, even though >> it is frickin' ugly... > > For reload that should be fairly okay, as reload will quickly fail if > the unit isn't actually running, and if it is running its dependencies > already ought to be satisfied. > > I'll look into both, thanks for the hints! Keep in mind though, that you'll need to not only update "service", but also invoke-rc.d and the lsb-hook, which is used when someone calls /etc/init.d/foo directly. It's also magnitudes less efficient to spawn external binaries to get the system state then doing this check from within systemd itself. So I'm not really convinced that shifting the responsibility here to the scripts themselves is the better approach. Michael -- 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] Container, private network and socket activation
> Also note that using socket activation for cotnainers means that > systemd instance inside the container also needs to have configuration > for the socket, to pass it on to the service that ultimately shall > answer for it. Are you sure that apache2 has support for that, and > that you set it up? Actually, I just want to start the container when someone else tries to connect to the port 80 of the host, just using the container's IP address. So, for instance, my host has IP 192.168.1.150, the container has IP 192.168.10.10 , and I want to type the second address in a web browser so the system in the container could boot and start apache. Then I could browse the page that is hosted by the apache server inside of the container. I'm not sure if that's even possible, but apache inside of the container starts at boot automatically, so I think there's no need for setting anything in the container -- please correct me if I'm wrong. pgpZjLYp3PFB1.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering wrote: > I am pretty sure signals are not a particularly good interface for > this. We should add a proper bus API for this one day, but this kinda > has to wait until kdbus is a done deal, since networkd runs in early > boot, and dbus-daemon is not available in early boot. Which would be a good usecase for signals (until kdbus happens, which might take some time) In an ideal world, kdbus will be the perfect solution, but at the moment, the few signals mentioned would immediately solve some serious limitations of systemd-networkd. Also, in the future, having 2 ways to do the same thing might be a good thing, especially for something as important as networking (ex: in case some distribution do not want to use kdbus, or waits a while to implement it, and in the meantime has to use weird hack. signals could lessen the pain) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
Lennart Poettering [2015-02-03 18:10 +0100]: > I am very strongly against adding hacky work-arounds like this to PID Yeah, indeed. This is why I asked for a more elegant approach, and indeed the --no-block or --job-mode=ignore-dependencies sound like slightly better approaches to this. I'll test these more thoroughly tomorrow, thanks for pointing out! > 1. The deadlocks are deadlocks, and implying --no-block if we are in > shutdown mode is a pretty drastic hack I think that special cases one > peculiar case way too much. Right, the problem is of course more generic. Any set of jobs (i. e. a transaction) which causes (maybe through some indirection) one of its job members to get restarted/reloaded will suffer from this deadlock problem, AFAIUI. Booting and shutdown are therefore mostly affected by this as pretty much every other time there the pending transactions are only very small. > My recommendation would be to stick this into your /usr/bin/service > compat glue. Use the state string "systemctl is-system-running" > outputs to check if you are shutting down. If so, add --no-block to > the params you pass to systemctl. That actually sounds like just what's needed here. is-system-running will also neatly cover the corresponding case on bootup. > Another option might be to pass --job-mode=ignore-dependencies instead > of --no-block, which was created for usecases like this, even though > it is frickin' ugly... For reload that should be fairly okay, as reload will quickly fail if the unit isn't actually running, and if it is running its dependencies already ought to be satisfied. I'll look into both, thanks for the hints! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Tue, 03.02.15 14:15, Charles Devereaux (syst...@guylhem.net) wrote: > My current solution with dhcpcd is a sleep service sending signals to > dhcpcd (give back the lease/reclaim it), something which could be extended > to systemd-networkd, with other signals for other meanings that you may not > want by default, like: > - removing the configuration it did (which is currently kept when > systemd-networkd is stopped, which could be useful in some scenarios to > avoid asking an additional IP address every time) > - starting or stopping the DHCP servers services (which once started keep > running) > > Even if systemd-networkd does not support a fine grained logic as I > regretted in another message about br0, this would at least support most of > the basic scenarios many people will need. I am pretty sure signals are not a particularly good interface for this. We should add a proper bus API for this one day, but this kinda has to wait until kdbus is a done deal, since networkd runs in early boot, and dbus-daemon is not available in early boot. 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 v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()
2015-02-03 19:52 GMT+01:00 Zbigniew Jędrzejewski-Szmek : > On Tue, Feb 03, 2015 at 07:29:06PM +0100, Michael Biebl wrote: >> If there are only for internal use, maybe we should consider hiding them. > Please don't. Once they're public, they're public. We can consider doing that > when bumping so version for another reason. You're right, of course. -- 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] slow systemd-networkd DHCP client on wlan0 with systemd v217
My current solution with dhcpcd is a sleep service sending signals to dhcpcd (give back the lease/reclaim it), something which could be extended to systemd-networkd, with other signals for other meanings that you may not want by default, like: - removing the configuration it did (which is currently kept when systemd-networkd is stopped, which could be useful in some scenarios to avoid asking an additional IP address every time) - starting or stopping the DHCP servers services (which once started keep running) Even if systemd-networkd does not support a fine grained logic as I regretted in another message about br0, this would at least support most of the basic scenarios many people will need. $ cat /dhcpcd-sleep.service [Unit] Description=DHCP client sleep hook Before=sleep.target ConditionVirtualization=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/killall -USR1 dhcpcd ExecStop=/usr/bin/killall -SIGALRM dhcpcd [Install] WantedBy=sleep.target On Tue, Feb 3, 2015 at 11:27 AM, Lennart Poettering wrote: > On Tue, 03.02.15 18:20, Patrik Flykt (patrik.fl...@linux.intel.com) wrote: > > > On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote: > > > On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote: > > > > > > > Another problem with systemd-networkd is that the lease is not > renewed > > > > after sleep. > > > > > > > > This is a basic feature, a laptop is frequently physicially moved, > which > > > > means another DHCP lease should be acquired, but I don't see how to > > > > do that. > > > > > > Hmm, I figure all DHCP leases should be refreshed when we come back > > > from suspend. Hooking that up should be pretty easy. Added to the TODO > > > list. > > > > > > That said, isn't the link beat lost anyway during suspend, and thus we > > > should refresh automatically, anyway? > > > > > > Either way refreshing on resume can't hurt... > > > > Is the resume event detected somehow in systemd? > > The kernel unfortunately provides no API for this right now. However, > if logind is the one suspending the machine, then it sends out a > PrepareForSleep() signal before doing so. systemd-resolved already > hooks into that: > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684 > > Tom mentioned he's already looking into adding similar code to > networkd to handle this properly. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
Hey, I've recently been using systemd-networkd to great success on a few of my machines here. However I ran into an interesting problem on at least 2 machines so far. I've included the output of journal for systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was suggested on another post. In addition the only network file I have configured is em0.network which contains the following, $cat /etc/systemd/network/em0.network [Match] Name=em0 [Network] DHCP=Yes The journalctl for systemd-networkd after bootup is, -- Logs begin at Mon 2012-12-31 20:02:09 PST, end at Tue 2015-02-03 10:57:09 PST. -- Feb 03 10:37:44 jekeller-copperpass systemd-networkd[1055]: timestamp of '/etc/systemd/network' changed Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : link 7 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : link 8 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : MAC address: 7e:5e:7c:31:44:4d Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : MAC address: b6:ec:a9:4b:e5:42 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : getting address failed: Device or resource busy Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.7 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message type=signal sender=org.freedesktop.DBus destination=:1.7 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : link 9 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : link 10 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : MAC address: 52:54:00:84:d2:d5 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexiste
Re: [systemd-devel] a way to limit restarts?
On Wed, 10.12.14 09:41, Ivan Shapovalov (intelfx...@gmail.com) wrote: > On Tuesday 09 December 2014 at 13:11:41, Nekrasov, Alexander wrote: > > Totally missed those. Thanks. Will OnFailure= be activated when the limit > > is hit? The manual only directly describes StartLimitAction= which isn’t > > exactly what’s required > > OnFailure= will be activated each time the unit enters "failed" state, i. e. > at the same time it is restarted. > > There is apparently no way to start a special unit when the start limit is > reached. > However, I may have missed it as well... Hmm, we should either change bbehaviour of OnFailure, to only trigger after the star limit is hit, or introduce some option to make this configurable I guess. Also see: https://bugs.freedesktop.org/show_bug.cgi?id=87799 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Open-Source Miracast - Wifi-Display on linux
Hi, This should be a reply to Davids message on Feb 2 but I'm not a subscriber and just happened to see this on the web archive... I apologize for the relative off-topicness and suggest that any followup questions be sent to wysiwidi mailing list: https://lists.01.org/mailman/listinfo/wysiwidi-dev. David Herrmann wrote: > As people continuously ask me about this, I'll just try to answer it > on the public ML: > > To make Miracast work, we need access to a Wifi P2P API. The kernel > implements Wifi P2P and wpa_supplicant provides access to it via it's > ctrl-interface (and I think recently even gained a dbus API). In > MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant > and provides P2P to MircaleCast. However, this does not work well in > parallel to NetworkManager/wicd/connman/... running. You really cannot > run wpa_supplicant multiple times on the same interface. Hence, > MiracleCast development is currently stalled until the different > network-managers provide a P2P API. > > Intel recently added such an API to ConnMan and provides a WFD > implementation on its own [1]. I highly recommend looking into it. > It's now up to NetworkManager to catch up. systemd-networkd doesn't do > L2 setup, so it's not really related. wicd is kinda dead [2], so I > doubt they'll come up with something. I'm one of the people working on this new implementation (Wysiwidi). We haven't made much noise yet as we didn't have a whole lot of demonstrably working code to show -- but that has changed in the last month or so and the project may well be worth a look now. I'll try to get a blog post with more details up Any Day Now but in short: The test sink included in Wysiwidi currently works with an Android source. It doesn't look pretty yet, you may hit GStreamer problems and the latency is higher than it should be, but 95% of the time it works every time. As far as Wifi P2P goes, the parts required by a Miracast implementation now work quite reliably with newish Intel wifi hardware (e.g. 7260) using _very_ recent Connman and wpa_supplicant. > Furthermore, P2P support is pretty "limited" right now. Officially, > almost all recent devices support it, but it's particularly annoying > to set it up, due to major bugs across all the stacks (in no way > limited to linux drivers). I mean, 3 of 4 of my connection attempts > between Android and Windows devices fails.. not even talking about my > wpa_supplicant hacks. This. I've previously worked on DLNA (notorious for interoperability problems) and frankly Miracast seems worse. The good news is that after two months of bug fixes wpa_supplicant and connman actually do a pretty good job -- but again, all testing has been done on Intel hardware: YMMV. My quick IOP test results are here https://github.com/01org/wysiwidi/wiki/Interoperability. It's still pretty red -- but note that in December it was red all over. Thanks, Jussi > As I'm not really interested in hacking on network-managers, I've > decided to stop working on MiracleCast. If, some day, there's a > working P2P stack on linux, I might resurrect it. But it sounds more > likely that I'll refer to the Intel solution (WYSIWIDI) instead. > There're also gstreamer plugins for WFD now, so maybe give them a try? > > Thanks > David > > [1] https://github.com/01org/wysiwidi > [2] https://answers.launchpad.net/wicd/+question/227789 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()
On Tue, Feb 03, 2015 at 07:29:06PM +0100, Michael Biebl wrote: > 2015-02-03 15:18 GMT+01:00 Kay Sievers : > > On Tue, Feb 3, 2015 at 3:09 PM, Zbigniew Jędrzejewski-Szmek > > wrote: > >> On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote: > >>> On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > >>> wrote: > >>> > >>> > On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote: > >>> > > On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl > >>> > > wrote: > >>> > > > Updated patch which the correct version information. > >>> > > > >>> > > Applied. > >>> > > >>> > Hm, I think this was an unintentional ABI break. udev_queue_flush @@ > >>> > LIBUDEV_183 > >>> > was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker > >>> > cannot know > >>> > that this is the same symbol. > >>> > >>> Hmm can you elaborate on this? I missing the context? Is there > >>> something to fix here? > >> For two releases systemd had a symbol, which then got removed. > >> Anyone compiling during that time and using it, would get a crashing > >> binary after installing systemd from the latest version. > >> > >> Although this happened a while ago and nobody complained suggests > >> that there were few users, and any there were got recompiled anyway. > > > > There should be no external users of these symbols, they were just > > exported for consistency. > > > http://codesearch.debian.net/results/udev_queue_flush > confirms that there are no external users. > > If there are only for internal use, maybe we should consider hiding them. Please don't. Once they're public, they're public. We can consider doing that when bumping so version for another reason. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Execute custom command whenever network interface appears
On Sun, 14.12.14 11:50, DimanNe (dima...@ya.ru) wrote: > Hello, > I read manual about systemd-networkd module > (http://www.freedesktop.org/software/systemd/man/systemd.network.html), > and as far as I know, I can do only basic actions (like run dhcp, or > assign static addresses/mac/routes and so on), but in general I want > to run some script or command. > > Here is real world example - > https://wiki.archlinux.org/index.php/ZTE_MF_823_(Megafon_M100-3)_4G_Modem > If you are using usb modem, you should > 1) run dhcp > 2) run curl/wget with special url > > so, my question, it it possible just now (how?)? If not, what is the best > approach to accomplish described above task? No, this is currently not supported, and it is unlikely that we ever will. In general we are not really convinced that doing callouts from lower layers into higher layers of the stack is something to support. If you want to do something like this make the higher stack subscribe to changes from the lower stack. In scripts you can use systemd-networkd-wait-online for that, to a certain level... 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] Cycle between logind and NetworkManager in case of remote user database
On Tue, 16.12.14 08:45, David Herrmann (dh.herrm...@gmail.com) wrote: > Hi > > On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams wrote: > > On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: > >> systemd tries to launch logind service which now waits for services it > >> is ordered After and eventually times out. > > > > NM patch filed for review by NM dev team: > > > > https://bugzilla.gnome.org/show_bug.cgi?id=741572 > > Thanks a lot! > > > Also, I don't think logind should fail if there is no network; no reason > > for it to crash and burn just because everything isn't quite ready > > when It doesn't crash and burn. If you talk to logind before its dependencies are fulfilled, and you do so synchronously, the method call will simply block until logind is up. There are two ways out here: a) not triggering activation by marking this in the bus message, or b) doing the method call asynchronously, rather than synchronously. Fix a) seems to be the right one here, since you'd really create a deadlock here otherwise. And I see that this is how you fixed it, so all is great. > > it starts. I presume it's got capability to deal with sporadic network > > outages, and that's not really different than waiting for networking to > > show up soon after it starts. But not my department... > > When a user loggs in, we resolve the name to UID. As the initial > logind binary was only used for login management, it was reasonable to > avoid starting up before the nss-user-lookup is initialized. Now that > systemd-logind provides other independent APIs, it might be ok to drop > that requirement again. > If the nss user lookup is not ready at the time someone logs in, we > will print a warning and skip tracking that session. Sounds fine to > me, but Lennart might have more comments. I am pretty sure we shouldn't allow user logins before the user database is fully accessible. If a user los in, he should see correct information about other users in "ls -l" output, and so on. It's OK to allow root to login earlier (and we do, via sulogin and stuff), but normal users during normal operation should not be allowed to do that. I am pretty sure we should leave the existing ordering as is. 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] DefaultDependencies=false on scopes
On Tue, Feb 3, 2015 at 10:20 AM, Lennart Poettering wrote: > I have added DefaultDependencies= for you now: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50 Thank you. I will work on getting Docker fixed up to fix this annoying behavior. Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()
2015-02-03 15:18 GMT+01:00 Kay Sievers : > On Tue, Feb 3, 2015 at 3:09 PM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Tue, Feb 03, 2015 at 01:34:23PM +0100, Lennart Poettering wrote: >>> On Thu, 29.01.15 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) >>> wrote: >>> >>> > On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote: >>> > > On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl wrote: >>> > > > Updated patch which the correct version information. >>> > > >>> > > Applied. >>> > >>> > Hm, I think this was an unintentional ABI break. udev_queue_flush @@ >>> > LIBUDEV_183 >>> > was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot >>> > know >>> > that this is the same symbol. >>> >>> Hmm can you elaborate on this? I missing the context? Is there >>> something to fix here? >> For two releases systemd had a symbol, which then got removed. >> Anyone compiling during that time and using it, would get a crashing >> binary after installing systemd from the latest version. >> >> Although this happened a while ago and nobody complained suggests >> that there were few users, and any there were got recompiled anyway. > > There should be no external users of these symbols, they were just > exported for consistency. http://codesearch.debian.net/results/udev_queue_flush confirms that there are no external users. If there are only for internal use, maybe we should consider hiding them. -- 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] DefaultDependencies=false on scopes
On Mon, 15.12.14 17:44, Brandon Philips (bran...@ifup.co) wrote: > Hello- > > How is a user supposed to disable DefaultDependencies on a scope? From > the docs it seems like it should work: > > "Unless DefaultDependencies=false is used, scope units will implicitly > have dependencies of type Conflicts= and Before= on > shutdown.target." Well, currenlty not all our props are exposed for transient units yet. Many are, but we were too lazy to add them all. If you need more properties, then let me know, and we can add them. I have added DefaultDependencies= for you now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50 > But, in practice: > > systemd-run --scope --property="DefaultDependencies=false" /usr/bin/sleep > 5 > Unknown assignment DefaultDependencies=false. > Failed to create message: Invalid argument This works now. 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] pam_limits: Could not set limit for ...: Operation not permitted
On Mon, 15.12.14 22:42, Kai Krakow (hurikha...@gmail.com) wrote: > Hello! > > I'm seeing the following errors in systemd's journal: > > Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): > Could not set limit for 'memlock': Operation not permitted > Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): > Could not set limit for 'nice': Operation not permitted > Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): > Could not set limit for 'rtprio': Operation not permitted > Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed: > Operation not permitted > Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning > /usr/lib/systemd/systemd: Operation not permitted > > Is it meaningless? Do I have to worry? Or which configuration do I miss? Hmm, this is certainly weird. It indicates some issue with your PAM setup maybe? Do you have SELinux enabled? Is this in some container or so? 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] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
Hi On Tue, Feb 3, 2015 at 6:36 PM, poma wrote: > On 02.02.2015 19:58, David Herrmann wrote: >> As I'm not really interested in hacking on network-managers, I've >> decided to stop working on MiracleCast. If, some day, there's a >> working P2P stack on linux, I might resurrect it. But it sounds more >> likely that I'll refer to the Intel solution (WYSIWIDI) instead. >> There're also gstreamer plugins for WFD now, so maybe give them a try? >> > > gst-rtsp-server-wfd > https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md > > Pre-conditions: > > This module is running on established p2p connection with wifi direct, which > means that you have to setup this network environment to run this module. I > hope this link would be very helpful. ( > http://cgit.freedesktop.org/~dvdhrm/miracle ) > > You are referring to them, they are referring to you. :) They provide a gstreamer plugin for Miracast, but quite frankly didn't bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack to provide a P2P link. If NM provides a P2P API, you can just set it up via nmcli and then use the gst modules to run Miracast (or you can just use the ConnMan API right now). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] test-dhcp-client failing in mock builds
On Tue, Feb 3, 2015 at 5:08 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Feb 03, 2015 at 06:49:21AM +0100, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Feb 03, 2015 at 02:42:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: >> > On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote: >> > > http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html >> > > >> > > I haven't got time to properly analyze the problem since then... >> > It sounded familiar ;) >> > >> > >> > On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote: >> > > "Operation not permitted" is what is printed for EPERM. But EPERM is not >> > > present in the client code itself, so I'm inclined towards a "permission >> > > problem" somewhere when running mock. >> > EPERM is also returned when using /dev/null in epoll_ctl_add. >> > I think I fixed it now. >> > >> > Which leads to a failure on arm in test-network: >> > FAIL: test-network >> > == >> > Assertion '!address_equal(a1, a2)' failed at >> > ../src/network/test-network.c:161, function test_address_equality(). >> > Aborting. >> > >> > I got out my chromebook to see what going on here. >> Ha, undefined behaviour on right shift. Gotta love C ;) >> >> So the tests pass in mock on all three primary arches. >> >> I'll let it spin on arm64 just to see what comes up. > And that passes too. Great stuff! Thanks! -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
On 02.02.2015 19:58, David Herrmann wrote: > Hi > > On Sun, Feb 1, 2015 at 10:50 AM, poma wrote: >> MiracleCast - Howto >> "Current State" > > [snip] > >> Can folks from the NetworkManager team & systemd-networkd team answer >> regarding the current status in this matter? > > As people continuously ask me about this, I'll just try to answer it > on the public ML: > > To make Miracast work, we need access to a Wifi P2P API. The kernel > implements Wifi P2P and wpa_supplicant provides access to it via it's > ctrl-interface (and I think recently even gained a dbus API). In > MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant > and provides P2P to MircaleCast. However, this does not work well in > parallel to NetworkManager/wicd/connman/... running. You really cannot > run wpa_supplicant multiple times on the same interface. Hence, > MiracleCast development is currently stalled until the different > network-managers provide a P2P API. > Are you for to make the request for improvement towards NetworkManager? > Intel recently added such an API to ConnMan and provides a WFD > implementation on its own [1]. I highly recommend looking into it. > It's now up to NetworkManager to catch up. systemd-networkd doesn't do > L2 setup, so it's not really related. wicd is kinda dead [2], so I > doubt they'll come up with something. > > Furthermore, P2P support is pretty "limited" right now. Officially, > almost all recent devices support it, but it's particularly annoying > to set it up, due to major bugs across all the stacks (in no way > limited to linux drivers). I mean, 3 of 4 of my connection attempts > between Android and Windows devices fails.. not even talking about my > wpa_supplicant hacks. > Thank you for your comprehensive explanation! > As I'm not really interested in hacking on network-managers, I've > decided to stop working on MiracleCast. If, some day, there's a > working P2P stack on linux, I might resurrect it. But it sounds more > likely that I'll refer to the Intel solution (WYSIWIDI) instead. > There're also gstreamer plugins for WFD now, so maybe give them a try? > gst-rtsp-server-wfd https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md Pre-conditions: This module is running on established p2p connection with wifi direct, which means that you have to setup this network environment to run this module. I hope this link would be very helpful. ( http://cgit.freedesktop.org/~dvdhrm/miracle ) You are referring to them, they are referring to you. :) > Thanks > David > > [1] https://github.com/01org/wysiwidi > [2] https://answers.launchpad.net/wicd/+question/227789 > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
On Tue, 03.02.15 18:01, Martin Pitt (martin.p...@ubuntu.com) wrote: > Lennart Poettering [2015-02-03 17:29 +0100]: > > Hmm, why precisely does this stall for 90s? > > The current transaction has final.target and all other jobs which need > to be shut down. One of these now trigger "systemctl reload > postfix.service", but that reload isn't going to actually run in the > same transaction but in the next one. OTOH systemctl reload > waits for the reloading to finish, thus we have a deadlock. > > > Isn't this a case where people should just use "--no-block"? > > Kind of. Not using this is the right thing while the machine is > running, so that the reload is actually done after calling systemctl > reload, and you can go on using postfix or whatever. --no-block should > help during shutdown, or early boot (same principal bug, but slightly > different patch, see http://bugs.debian.org/624599). > > So every time you call reload you'd have to check whether or not you > are in early boot/during shutdown, or in the running system, and > conditionally use --no-block. However, as such scripts should never > call systemctl directly, but "service foo reload" (to work with other > init systems or chroot), it would be also possible to move that check > there, and conditionally add --no-block. It would just be another > thing that every distro has to re-discover :-) I am very strongly against adding hacky work-arounds like this to PID 1. The deadlocks are deadlocks, and implying --no-block if we are in shutdown mode is a pretty drastic hack I think that special cases one peculiar case way too much. My recommendation would be to stick this into your /usr/bin/service compat glue. Use the state string "systemctl is-system-running" outputs to check if you are shutting down. If so, add --no-block to the params you pass to systemctl. Another option might be to pass --job-mode=ignore-dependencies instead of --no-block, which was created for usecases like this, even though it is frickin' ugly... 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] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
On Tue, 03.02.15 16:34, Serge Hallyn (serge.hal...@ubuntu.com) wrote: > > > the UID/GID on entire filesystem sub-trees given to containers with > > > userns is a real unpleasant thing to have to deal with. I'd not want > > Of course you would *not* want to take a stock rootfs where uid == 0 > and shift that into the container, as that would give root in the > container a chance to write root-owned files on the host to leverage > later in a convoluted attack :) Is this really a problem? I mean, the only way how this could be exploitable is if people make the container hierarchy accessible to other users, but that should be easy to prohibit by making the container's parent dir 0700, which we already do for nspawn's container in /var/lib/machines... The only other risk I can see here is that if people use traditional ext4 quota, then the container's disk usage will be added to the host's usage. But that's easy to avoid, by simply never placing container images and the host on the same quota device... Also, in the case of systemd-nspawn we strongly emphasize usage with loopback devices. In that case there's no vulnerability at all, since the device is completely seperate from the host fs, and it will only be mounted in the container, but not in the host... > We might want to come up with a containers concensus that container > rootfs's are always shipped with uid range 0-65535 -> 10-165535. > That still leaves a chance for container A (mapped to 20-265535) > to write valid setuid-root binary for container B (mapped to > 30-365535), which isn't possible otherwise. But that's better > than doing so for host-root. Well, ultimately I'd recommend an automatism like this for container managers: a) if not otherwise configured, let's give each container their own 16bit of uids. This would mean each 32bit uid could be neatly split into the upper 16bit that would become a "container" id, plus the lower 16bit for the actual "virtual" UID. b) we will never set up UID ranges orthogonal from GID ranges. c) when a container image is started, the container manager first checks the UID/GID owner of the root of the root file system. It masks the lower 16bit away, and only looks for the upper 16bit. d) It will then look for an unused container id (which means, an unused range of 64K UIDs), and then shifts the offset it identified following c) to this new container id. With that in place it doesn't really matter which base people use in their containers, the container manager would do the right thing, and shift everything into the right place. Paranoid people could ship their container images shifted to some ID of their choice, and lazy folks could just ship their container images with base 0, but then must make sure they don't give anybody else access to the hierarchy, and don't confuse quota... > > > [1] Using a separate disk image per container means a container can't > > > DOS other containers by exhausting inodes for example with $millions > > > of small files. > > > > Indeed. I'd claim that without such a concept of mount point uid > > shifting the whole userns story is not very useful IRL... > > I had always thought this would eventually be done using a stackable > filesystem, but doing it at bind mount time would be neat too, and > less objectionable to the kernel folks. (Though overlayfs is in now, > so ) > > I'm actually quite surprised noone has sat down and written a > stackable uid-shifting fs yet. If it's done as part of bind mounts, or as an extension of overlayfs, or in a completely new fs, doesn't really matter to me. I'd certainly welcome a solution based on any of these options! 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] Avoid reloading services when shutting down
Lennart Poettering [2015-02-03 17:29 +0100]: > Hmm, why precisely does this stall for 90s? The current transaction has final.target and all other jobs which need to be shut down. One of these now trigger "systemctl reload postfix.service", but that reload isn't going to actually run in the same transaction but in the next one. OTOH systemctl reload waits for the reloading to finish, thus we have a deadlock. > Isn't this a case where people should just use "--no-block"? Kind of. Not using this is the right thing while the machine is running, so that the reload is actually done after calling systemctl reload, and you can go on using postfix or whatever. --no-block should help during shutdown, or early boot (same principal bug, but slightly different patch, see http://bugs.debian.org/624599). So every time you call reload you'd have to check whether or not you are in early boot/during shutdown, or in the running system, and conditionally use --no-block. However, as such scripts should never call systemctl directly, but "service foo reload" (to work with other init systems or chroot), it would be also possible to move that check there, and conditionally add --no-block. It would just be another thing that every distro has to re-discover :-) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Tue, 16.12.14 17:22, Filipe Brandenburger (filbran...@google.com) wrote: > On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering > wrote: > > In fact, I think we should drop the > > libcap dependency altogether and just do the two syscalls it offers to > > us natively in systemd code. Neither is libcap a particularly nice > > library, nor is the stuff it does particularly complex, hence we can > > as well wrap the two calls we need in our code. > > I started looking at this and I just sent a patch set to remove the > include of where it was not really in use. > > Regarding the valid uses of libcap, it looks like the non-trivial part > is cap_to_text/cap_from_text which we would have to reimplement and > possibly keep them in sync with libcap. Yeah, this is indeed not the nicest code to hack up, but should be quite doable still. > libcap also tries to support kernels which only support 32-bit > capabilities. If we replace that code, should we make an assumption of > 64-bit capabilities and just use a uint64_t to represent the bits? I think 64bit caps have been standard since a lng time already. AFAIK though the kernel/userspace API is built around arrays of 64bit values currently though, to allow extension one day. This is how we expose it in sd-bus for the message metadata caps currently, maybe we should do it everywhere the same. > Let me know if you think this is something worth doing and I can > contribute an implementation. Absolutely. Would love to drop the dep! 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] logind, su - sessions and initscripts compatibility
On Thu, 18.12.14 11:05, Andrei Borzenkov (arvidj...@gmail.com) wrote: > As far as I know, systemd still officially retains compatibility with > initscripts. Unfortunately, session management now at least partially > broke it. > > Any initscript that is using "su -" would create logind session; this > session will persist until processes started by initscript are > runing. Any initscript that uses "su -" is broken I am very much convinced. For two reasons. First of all, the dash means that you want a login shell, i.e. one that "feels" like a "real" user login. That's very inappropriate for daemons. Secondly, su goes through the whole PAM stack. PAM is really for setting up user sessions, it has no place when setting up the environment for a daemon. If you want to set up the environment for a daemon, use "start-stop-daemon", "runuser", or simply systemd's User= setting. None of them goes through PAM. If you go through PAM, then you not only get a new systemd session opened for it, but also an audit session, selinux session, ... And you clearly don't want that. This is unfortunately little documented, but it's really how it is. Do not use "su" for init scripts. Never, ever. It's a user command, not a command to use in codepaths outside of user sessions. All this is wrong outside of the systemd context, and just a slightly bit more inside the systemd context, but the correct fix is certainly outside of the scope of systemd. Sorry, 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] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
Quoting Lennart Poettering (lenn...@poettering.net): > On Tue, 03.02.15 15:03, Daniel P. Berrange (berra...@redhat.com) wrote: > > > > Hmm, so, I thought a lot about this in the past weeks. I think the way > > > I'd really like to see this work in the end is that we never have to > > > persist the UID mappings. This could work if the kernel would provide > > > us with the ability to bind mount a file system into the container > > > applying a fixed UID shift. That way, the shifted UIDs would never hit > > > the actual disk, and hence we wouldn't have to persist their mappings. > > > > > > Instead on each container startup we'd look for a new UID range, and > > > release it entirely when the container shuts down. The bind mount with > > > UID shift would then shift the UIDs up, the userns stuff would shift > > > it down from inside the container again. > > > > > > Of course, this all depends on whether the kernel will get an > > > extension to apply uid shifts to bind mounts. I hear they want to > > > provide this, but let's see. > > > > I would dearly love to see that happen. Having to recursively change It'd definately be useful (though not without issues). > > the UID/GID on entire filesystem sub-trees given to containers with > > userns is a real unpleasant thing to have to deal with. I'd not want Of course you would *not* want to take a stock rootfs where uid == 0 and shift that into the container, as that would give root in the container a chance to write root-owned files on the host to leverage later in a convoluted attack :) We might want to come up with a containers concensus that container rootfs's are always shipped with uid range 0-65535 -> 10-165535. That still leaves a chance for container A (mapped to 20-265535) to write valid setuid-root binary for container B (mapped to 30-365535), which isn't possible otherwise. But that's better than doing so for host-root. > > the filesystem UID shift to only apply to bind mounts though. It is > > not uncommon to use a disk image[1] for a container's filesystem, so > > being able to request a UID shift on *any* filesystem mount is pretty > > desirable, rather than having to mount the image and then bind mount > > it onto itself just to apply the UID shift. > > Well, you can always change the bind mount flags without creating a > new bind mount with MS_BIND|MS_REMOUNT. > > > [1] Using a separate disk image per container means a container can't > > DOS other containers by exhausting inodes for example with $millions > > of small files. > > Indeed. I'd claim that without such a concept of mount point uid > shifting the whole userns story is not very useful IRL... I had always thought this would eventually be done using a stackable filesystem, but doing it at bind mount time would be neat too, and less objectionable to the kernel folks. (Though overlayfs is in now, so ) I'm actually quite surprised noone has sat down and written a stackable uid-shifting fs yet. -serge ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
On Tue, 03.02.15 17:26, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Hey all,
>
> I'm currently reviewing our Debian patches for systemd, and came
> across this one which sounds important for other distributions, too.
> This was reported and fixed two years ago in
> https://bugs.debian.org/635777 which has all the details and logs, but
> the summary is:
>
> Distributions have quite a lot of "run scripts in this .d/ directory
> if stuff happens"; e. g. the ISC DHCP client has
> /etc/dhcp/dhclient-{enter,exit}-hooks.d/, Debian's ifupdown has
> /etc/network/if-{up,down}.d/, and of course init.d scripts themselves
> also occasionally call "service foo reload" and similar. It can happen
> that when requesting a shutdown, a script of the above kind reloads or
> restarts another service. In this case, postfix wants to reload itself
> after a network interface goes up or down; during runtime that works
> fine, but if it happens during shutdown, that "systemctl reload
> postfix" will cause the entire shutdown to stall for 90s (the default
> timeout).
Hmm, why precisely does this stall for 90s?
Isn't this a case where people should just use "--no-block"?
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] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Tue, 03.02.15 18:20, Patrik Flykt (patrik.fl...@linux.intel.com) wrote: > On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote: > > On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote: > > > > > Another problem with systemd-networkd is that the lease is not renewed > > > after sleep. > > > > > > This is a basic feature, a laptop is frequently physicially moved, which > > > means another DHCP lease should be acquired, but I don't see how to > > > do that. > > > > Hmm, I figure all DHCP leases should be refreshed when we come back > > from suspend. Hooking that up should be pretty easy. Added to the TODO > > list. > > > > That said, isn't the link beat lost anyway during suspend, and thus we > > should refresh automatically, anyway? > > > > Either way refreshing on resume can't hurt... > > Is the resume event detected somehow in systemd? The kernel unfortunately provides no API for this right now. However, if logind is the one suspending the machine, then it sends out a PrepareForSleep() signal before doing so. systemd-resolved already hooks into that: http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684 Tom mentioned he's already looking into adding similar code to networkd to handle this properly. 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] Avoid reloading services when shutting down
Hey all,
I'm currently reviewing our Debian patches for systemd, and came
across this one which sounds important for other distributions, too.
This was reported and fixed two years ago in
https://bugs.debian.org/635777 which has all the details and logs, but
the summary is:
Distributions have quite a lot of "run scripts in this .d/ directory
if stuff happens"; e. g. the ISC DHCP client has
/etc/dhcp/dhclient-{enter,exit}-hooks.d/, Debian's ifupdown has
/etc/network/if-{up,down}.d/, and of course init.d scripts themselves
also occasionally call "service foo reload" and similar. It can happen
that when requesting a shutdown, a script of the above kind reloads or
restarts another service. In this case, postfix wants to reload itself
after a network interface goes up or down; during runtime that works
fine, but if it happens during shutdown, that "systemctl reload
postfix" will cause the entire shutdown to stall for 90s (the default
timeout).
Michael Stapelberg wrote the attached patch which fixes this by
disallowing unit reloads/restarts when final.target is queued. This is
admittedly not very elegant as it hardcodes the "final.target" name
(and also, for upstream the comment should be adjusted of course), but
it does fix the issue. I can still reproduce the problem with 218 in a
VM.
Is this something which we can fix upstream in a more elegant manner?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From: Tollef Fog Heen
Date: Tue, 16 Oct 2012 18:39:27 +0200
Subject: Avoid reloading services when shutting down
Doing so won't work and makes no sense. Thanks to Michael Stapelberg
for the patch. Closes: #624599.
---
src/core/manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/core/manager.c b/src/core/manager.c
index 6382400..acef626 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1147,6 +1147,8 @@ int manager_startup(Manager *m, FILE *serialization, FDSet *fds) {
int manager_add_job(Manager *m, JobType type, Unit *unit, JobMode mode, bool override, sd_bus_error *e, Job **_ret) {
int r;
Transaction *tr;
+Job *j;
+Iterator i;
assert(m);
assert(type < _JOB_TYPE_MAX);
@@ -1156,6 +1158,29 @@ int manager_add_job(Manager *m, JobType type, Unit *unit, JobMode mode, bool ove
if (mode == JOB_ISOLATE && type != JOB_START)
return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, "Isolate is only valid for start.");
+if (type == JOB_RELOAD || type == JOB_RELOAD_OR_START || type == JOB_RESTART || type == JOB_TRY_RESTART) {
+HASHMAP_FOREACH(j, m->jobs, i) {
+assert(j->installed);
+
+/* If final.target is queued (happens on poweroff, reboot and
+ * halt), we will not accept new reload jobs. They would not be
+ * executed ever anyways (since the shutdown comes first), but
+ * they block the shutdown process: when systemd tries to stop
+ * a unit such as ifup@eth0.service, that unit might invoke a
+ * systemctl reload command, which blockingly waits (but only
+ * gets executed after all other queued units for the shutdown
+ * have been executed).
+ *
+ * See http://bugs.debian.org/624599 and
+ * http://bugs.debian.org/635777 */
+if (strcmp(j->unit->id, "final.target") == 0) {
+log_debug("final.target is queued, ignoring %s request for unit %s", job_type_to_string(type), unit->id);
+sd_bus_error_setf(e, BUS_ERROR_SHUTTING_DOWN, "final.target is queued, ignoring %s request for unit %s", job_type_to_string(type), unit->id);
+return -EINVAL;
+}
+}
+}
+
if (mode == JOB_ISOLATE && !unit->allow_isolate)
return sd_bus_error_setf(e, BUS_ERROR_NO_ISOLATION, "Operation refused, unit may not be isolated.");
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.
On Tue, 03.02.15 16:11, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: > > Hmm, what precisely is the issue again here? You are looking for a way > > to make the root disk writable when using gpt auto discovery after > > boot, without shipping an /etc/fstab that would result in remounting > > after boot? Why wouldn't specifying "rw" on the kernel cmdline suffice > > for that? > > The issue is that without specifying neither "ro" nor "rw" on the > kernel command line (nor via any other configuration - e.g. > /etc/fstab, explicit mount unit etc.), the partition flags are not > honoured for the root partition by gpt-auto-generator and one ends up > with a "ro" mounted rootfs, instead of a "rw" one. Well, I'd claim it *is* honoured... After all the flag is called "read-only", and hence when set it ensures that things are read-only, but it doesn't make any claim about what happens when writable... But of course, that's nitpicking... ;-) Maybe we should turn the gpt part flags into a tri-state, by adding a second bit to it: 00 → default behaviour, which means ro for root parts, rw for other parts 10 → always read-only, regardless if root or not 01 → always writable, regardless if root or not And the existing bit would be the first of the two bits above. Combination 11 would be invalid, but treated as 00 for now... And the kernel options "ro" and "rw" would always override the flags for the root disk, and so would fstab. Would that work for you? Would be happy to take a patch for this! 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] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Tue, 2015-02-03 at 11:46 +0100, Lennart Poettering wrote: > On Mon, 02.02.15 23:12, Charles Devereaux (syst...@guylhem.net) wrote: > > > Another problem with systemd-networkd is that the lease is not renewed > > after sleep. > > > > This is a basic feature, a laptop is frequently physicially moved, which > > means another DHCP lease should be acquired, but I don't see how to > > do that. > > Hmm, I figure all DHCP leases should be refreshed when we come back > from suspend. Hooking that up should be pretty easy. Added to the TODO > list. > > That said, isn't the link beat lost anyway during suspend, and thus we > should refresh automatically, anyway? > > Either way refreshing on resume can't hurt... Is the resume event detected somehow in systemd? I'd assume that links are lost when suspending and reconnected on resume, so maybe that is the only event needing attention. I'll take a quick look into what my laptop thinks about the issue... Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.
On 3 February 2015 at 15:50, Lennart Poettering wrote:
> On Mon, 29.12.14 14:33, Dimitri John Ledkov (dimitri.j.led...@intel.com)
> wrote:
>
> Heya,
>
> Sorry for the late review, still busy keeping up with all the unmerged
> patches and unreplied mails that queued up...
>
> Is this issue still relevant?
>
I believe it is relevant, but I gave up working on it at the moment.
>> Signed-off-by: Dimitri John Ledkov
>
> (We do not use S-o-b, we are not the kernel...)
>
>> This is not yet really ready for application, as ultimately this is
>> only solution for part of the problem.
>>
>> With this patch, post-initrd -.mount unit will have correct
>> "Options=rw" if READ_ONLY flag is not set and ro/rw was not specified
>> on the kernel cmdline. In the initrd the -.mount unit will continue
>> to be mounted ro by default (honoring cmdline rw flag, but ignoring
>> unset READ_ONLY flag).
>>
>> However, remount-fs only considers /etc/fstab and only remounts
>> things with options as specified in the /etc/fstab. Thus the fact
>> that -.mount unit changed "Options=ro" -> "Options=rw" between
>> initramfs and pivoted system does not result in the root filesystem
>> getting remounted as rw.
>
> Hmm, what precisely is the issue again here? You are looking for a way
> to make the root disk writable when using gpt auto discovery after
> boot, without shipping an /etc/fstab that would result in remounting
> after boot? Why wouldn't specifying "rw" on the kernel cmdline suffice
> for that?
The issue is that without specifying neither "ro" nor "rw" on the
kernel command line (nor via any other configuration - e.g.
/etc/fstab, explicit mount unit etc.), the partition flags are not
honoured for the root partition by gpt-auto-generator and one ends up
with a "ro" mounted rootfs, instead of a "rw" one.
I guess at the very least we could document that from
http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/:
"For the root, server data and home partitions the partition flag bit
60 ("read-only") may be used to mark a partition for read-only mounts
only. If set the partition will be mounted read-only instead of
read-write."
Is not implemented for root partition by gpt-auto-generator, but only
for the server data & home partitions.
--
Regards,
Dimitri.
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] test-dhcp-client failing in mock builds
On Tue, Feb 03, 2015 at 06:49:21AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Feb 03, 2015 at 02:42:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote: > > > http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html > > > > > > I haven't got time to properly analyze the problem since then... > > It sounded familiar ;) > > > > > > On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote: > > > "Operation not permitted" is what is printed for EPERM. But EPERM is not > > > present in the client code itself, so I'm inclined towards a "permission > > > problem" somewhere when running mock. > > EPERM is also returned when using /dev/null in epoll_ctl_add. > > I think I fixed it now. > > > > Which leads to a failure on arm in test-network: > > FAIL: test-network > > == > > Assertion '!address_equal(a1, a2)' failed at > > ../src/network/test-network.c:161, function test_address_equality(). > > Aborting. > > > > I got out my chromebook to see what going on here. > Ha, undefined behaviour on right shift. Gotta love C ;) > > So the tests pass in mock on all three primary arches. > > I'll let it spin on arm64 just to see what comes up. And that passes too. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH][Resend][RFC] core: Fix wrong timestamps in rtc-in-local time mode.
On Thu, 25.12.14 22:00, Chunhui He (hchun...@mail.ustc.edu.cn) wrote: Sorry for the late response, still busy processing all the queued mails and patches... > Thanks David! Yes, I missed Lennart's reply. > > Thanks Lennart! > Yes, I agree rtc-in-local-time is a compatibility hack. > > But I think similar issues in other components is orthogonal to this bug. > The key is that systemd records _inconsistent_ timestamps. It's surely a > logic _error_ introduced in commit 3a170f3d3358135a39ac6eafe66f18aef0bd67d, > even though this bug appears in "compatibility hack". > > rtc-in-utc is orthogonal too. In contrast, using rtc-in-utc is a workaround > in this situation. Since we provide the compatibility, we have to fix it. Hmm, so you are saying there's a bug in rtc-in-utc behaviour here too? Could you elaborate, please? I mean, I think we should accept that wallclock time is not linear (I mean, the fact that it isn't linear is acknowledged by the existance of CLOCK_MONOTONIC...), and I think it's a really good idea to record the kernel's notion of the wallclock time at the point some event happened, even if it's likely to be incorrectly set. Note that we do a lot of things before the initial timewarp is done, including loading of the SELinux policy. Given how time consuming loading of SELinux policy is, and that it might result in log messages on its own, we really should not confuse the user by reporting some very selected early, specific events adjusted, while leaving the usual events unadjusted... We are really interested in making logging timestamps relatable to each other, regardless where they come from. This only works, if the all sources use the unaltered kernel timestamps, so that everybody's time axis makes a jump at the same time when the timewarp is first enforced. Adjusting some logged timestamps but not others would be really confusing... I hope this makes any sense. But maybe I misunderstood what precsiely you are actually intending to change with your patch? 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] gpt-auto-generator: honor read-only attribute for native rootfs, post-initrd.
On Mon, 29.12.14 14:33, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Heya, Sorry for the late review, still busy keeping up with all the unmerged patches and unreplied mails that queued up... Is this issue still relevant? > Signed-off-by: Dimitri John Ledkov (We do not use S-o-b, we are not the kernel...) > This is not yet really ready for application, as ultimately this is > only solution for part of the problem. > > With this patch, post-initrd -.mount unit will have correct > "Options=rw" if READ_ONLY flag is not set and ro/rw was not specified > on the kernel cmdline. In the initrd the -.mount unit will continue > to be mounted ro by default (honoring cmdline rw flag, but ignoring > unset READ_ONLY flag). > > However, remount-fs only considers /etc/fstab and only remounts > things with options as specified in the /etc/fstab. Thus the fact > that -.mount unit changed "Options=ro" -> "Options=rw" between > initramfs and pivoted system does not result in the root filesystem > getting remounted as rw. Hmm, what precisely is the issue again here? You are looking for a way to make the root disk writable when using gpt auto discovery after boot, without shipping an /etc/fstab that would result in remounting after boot? Why wouldn't specifying "rw" on the kernel cmdline suffice for that? 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] path: conditionally depend on the triggered unit
On Mon, 29.12.14 14:07, Jouke Witteveen (j.wittev...@gmail.com) wrote: heya, sorry for the late review, still busy catching up with all the queued mail. > Path units having either PathExists=, PathExistsGlob=, or > DirectoryNotEmpty= want the service they trigger when the condition is > met. This way it becomes meaningful to include StopWhenUnneeded=true in > the triggered service. Hmm, I see how this could be useful, but the patch like this is not OK. Dependencies in systemd are strictly additive. The only way to get rid of dependencies is by doing a full reload of the configuration. We coalesce dependencies from a variety of sources, and if we really wanted to allow dynamically dropping deps again we'd couldn't do that anymore and would have to track precisely the reason for each dep that is added. I wonder if we can find a better way to handle this... So far the issue never came up since we expected that services would exit-in-idle on their own, so that we never need an external trigger to automatically shut something down, but the daemons would do so on their own. Can you elaborate on your precise usecase for this? I mean, even if we added the facility you propose this would require the services to operate in a certain way to be fully safe and race-free. But if that's the case, then they might as well shut down on their own at the right time? 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] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
Hi On Tue, Feb 3, 2015 at 3:41 PM, Lennart Poettering wrote: > Hmm, so, I thought a lot about this in the past weeks. I think the way > I'd really like to see this work in the end is that we never have to > persist the UID mappings. This could work if the kernel would provide > us with the ability to bind mount a file system into the container > applying a fixed UID shift. That way, the shifted UIDs would never hit > the actual disk, and hence we wouldn't have to persist their mappings. An alternative would be to map UIDs to the owning user-namespace of the current mount-namespace when accessing disks (which is the user-namespace active at the time the mount-namespace was created). Anyway, this all depends on kernel people to accept this.. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
On Tue, 03.02.15 15:03, Daniel P. Berrange (berra...@redhat.com) wrote: > > Hmm, so, I thought a lot about this in the past weeks. I think the way > > I'd really like to see this work in the end is that we never have to > > persist the UID mappings. This could work if the kernel would provide > > us with the ability to bind mount a file system into the container > > applying a fixed UID shift. That way, the shifted UIDs would never hit > > the actual disk, and hence we wouldn't have to persist their mappings. > > > > Instead on each container startup we'd look for a new UID range, and > > release it entirely when the container shuts down. The bind mount with > > UID shift would then shift the UIDs up, the userns stuff would shift > > it down from inside the container again. > > > > Of course, this all depends on whether the kernel will get an > > extension to apply uid shifts to bind mounts. I hear they want to > > provide this, but let's see. > > I would dearly love to see that happen. Having to recursively change > the UID/GID on entire filesystem sub-trees given to containers with > userns is a real unpleasant thing to have to deal with. I'd not want > the filesystem UID shift to only apply to bind mounts though. It is > not uncommon to use a disk image[1] for a container's filesystem, so > being able to request a UID shift on *any* filesystem mount is pretty > desirable, rather than having to mount the image and then bind mount > it onto itself just to apply the UID shift. Well, you can always change the bind mount flags without creating a new bind mount with MS_BIND|MS_REMOUNT. > [1] Using a separate disk image per container means a container can't > DOS other containers by exhausting inodes for example with $millions > of small files. Indeed. I'd claim that without such a concept of mount point uid shifting the whole userns story is not very useful IRL... 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] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
On Tue, Feb 03, 2015 at 03:41:22PM +0100, Lennart Poettering wrote: > On Tue, 30.12.14 06:49, Simon Peeters (peeters.si...@gmail.com) wrote: > > > 2014-12-29 14:14 GMT+00:00 Tom Gundersen : > > > On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering > > > wrote: > > > > >> I am open to adding support for this, but I think the allocation of > > >> the UID ranges should really happen automatically, and not be > > >> something the admin has to manually assign. > > >> > > >> Which means we'd enter dynamic UID allocation terroritory, and that > > >> opens a huge can of worms... > > > > > > Would we not also need to support explicit assignment, in case someone > > > has a preexisting image they want to match in a specific way? In that > > > case we could start off without the dynamic allocation and add that > > > later. It certainly would make testing a lot simpler if we had userns > > > support sooner rather than later (at least in the case of netlink it > > > appears to be quite a mess). > > > > Inspired by this topic I wrote a quick'n'dirty uid allocator[1] > > this allocator manages the upper 2G uid's, which using Matthias Urlichs > > example > > of 2048 uid's per container, still allows for 1M containers. > > > > It curently can't persist these allocations, but that is on my > > "0.0.1" todolist. > > Hmm, so, I thought a lot about this in the past weeks. I think the way > I'd really like to see this work in the end is that we never have to > persist the UID mappings. This could work if the kernel would provide > us with the ability to bind mount a file system into the container > applying a fixed UID shift. That way, the shifted UIDs would never hit > the actual disk, and hence we wouldn't have to persist their mappings. > > Instead on each container startup we'd look for a new UID range, and > release it entirely when the container shuts down. The bind mount with > UID shift would then shift the UIDs up, the userns stuff would shift > it down from inside the container again. > > Of course, this all depends on whether the kernel will get an > extension to apply uid shifts to bind mounts. I hear they want to > provide this, but let's see. I would dearly love to see that happen. Having to recursively change the UID/GID on entire filesystem sub-trees given to containers with userns is a real unpleasant thing to have to deal with. I'd not want the filesystem UID shift to only apply to bind mounts though. It is not uncommon to use a disk image[1] for a container's filesystem, so being able to request a UID shift on *any* filesystem mount is pretty desirable, rather than having to mount the image and then bind mount it onto itself just to apply the UID shift. Regards, Daniel [1] Using a separate disk image per container means a container can't DOS other containers by exhausting inodes for example with $millions of small files. -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)
On Tue, 30.12.14 06:49, Simon Peeters (peeters.si...@gmail.com) wrote: > 2014-12-29 14:14 GMT+00:00 Tom Gundersen : > > On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering > > wrote: > > >> I am open to adding support for this, but I think the allocation of > >> the UID ranges should really happen automatically, and not be > >> something the admin has to manually assign. > >> > >> Which means we'd enter dynamic UID allocation terroritory, and that > >> opens a huge can of worms... > > > > Would we not also need to support explicit assignment, in case someone > > has a preexisting image they want to match in a specific way? In that > > case we could start off without the dynamic allocation and add that > > later. It certainly would make testing a lot simpler if we had userns > > support sooner rather than later (at least in the case of netlink it > > appears to be quite a mess). > > Inspired by this topic I wrote a quick'n'dirty uid allocator[1] > this allocator manages the upper 2G uid's, which using Matthias Urlichs > example > of 2048 uid's per container, still allows for 1M containers. > > It curently can't persist these allocations, but that is on my > "0.0.1" todolist. Hmm, so, I thought a lot about this in the past weeks. I think the way I'd really like to see this work in the end is that we never have to persist the UID mappings. This could work if the kernel would provide us with the ability to bind mount a file system into the container applying a fixed UID shift. That way, the shifted UIDs would never hit the actual disk, and hence we wouldn't have to persist their mappings. Instead on each container startup we'd look for a new UID range, and release it entirely when the container shuts down. The bind mount with UID shift would then shift the UIDs up, the userns stuff would shift it down from inside the container again. Of course, this all depends on whether the kernel will get an extension to apply uid shifts to bind mounts. I hear they want to provide this, but let's see. I kinda would prefer to see how that works out before we add any infrastructure for automatic allocation to systemd, since only then we have the full picture to consider. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
