Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container

[James Lott]

I am using a setup which retains the CAP_NET_ADMIN capability inside the 
container and allows openvpn to setup the device. No persistent devices are 
involved. Below, I have included a snippet from a shell session which shows 
the command used to invoke nspawn and then the openvpn command executed within 
the container which fails. 

[root@host01 ~]# systemctl status lanvpn | grep -A1 CGroup
   CGroup: /system.slice/lanvpn.service
   `-2169 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD 
/home/lanvpn
[root@host01 ~]# ssh lanvpn
Last login: Thu Oct  9 15:01:42 2014 from host01.lottspot.vpn
[root@lanvpn ~]# openvpn --config /etc/openvpn/vpngate.conf | tail -n2
Thu Oct  9 23:40:45 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: 
Operation not permitted (errno=1)
Thu Oct  9 23:40:45 2014 Exiting due to fatal error

This same VPN configuration will successfully connect within the host 
environment.

[root@lanvpn ~]# exit
logout
Connection to lanvpn closed.
[root@host01 ~]# curl icanhazip.com
23.243.158.241
[root@host01 ~]# openvpn --daemon --config 
/home/lanvpn/etc/openvpn/vpngate.conf 
[root@host01 ~]# curl icanhazip.com
111.255.23.34

On Friday 10 October 2014 08:12:02 you wrote:
> On Fri, Oct 10, 2014 at 12:13 AM, James Lott  wrote:
> > Trying to start up an openvpn connection yields the following error:
> > 
> > Thu Oct  9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun:
> > Operation not permitted (errno=1)
> > 
> > As requested by Lennart, attached you will find an strace of the openvpn
> > process as it attempts to setup the connection. Please let me know if
> > there's anything else I can provide to be helpful, and thanks again for
> > the help!
> Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN
> (which depends on how you start nspawn, e.g. passing --network-veth
> will give you this) or the tun device must be created persistently by
> someone else and openvpn must have the right uid/gid to take control
> of it.
> 
> Which setup are you using? Could you send the commandline you used to
> invoke nspawn and the openvpn config file you are using? (And also the
> same for whatever method you are using to create the persistent tun
> netdev, if this is what you do).
> 
> Cheers,
> 
> Tom

-- 
James Lott
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [question] networkd: Any support for hooks?

[Tom Gundersen]

On Fri, Oct 10, 2014 at 3:38 AM, Cameron Norman
 wrote:
> udev was indeed my first thought for ethtool, however how would the ethtool
> commands be hooked in on containers? Or is ethtool not relevant there?

In a container you'll either have devices that you have moved in from
the outside (these should be configured (by udev) before moving them
inside), or virtual devices that are created from inside the container
(which should be just created in the "right way" in the first place
without the need to change their settings after they appear), so in
general I would say that ethtool is not relevant in containers.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container

[Tom Gundersen]

On Fri, Oct 10, 2014 at 12:13 AM, James Lott  wrote:
> Trying to start up an openvpn connection yields the following error:
>
> Thu Oct  9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun:
> Operation not permitted (errno=1)
>
> As requested by Lennart, attached you will find an strace of the openvpn
> process as it attempts to setup the connection. Please let me know if there's
> anything else I can provide to be helpful, and thanks again for the help!

Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN
(which depends on how you start nspawn, e.g. passing --network-veth
will give you this) or the tun device must be created persistently by
someone else and openvpn must have the right uid/gid to take control
of it.

Which setup are you using? Could you send the commandline you used to
invoke nspawn and the openvpn config file you are using? (And also the
same for whatever method you are using to create the persistent tun
netdev, if this is what you do).

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 09, 2014 at 07:01:11PM +0530, Susant Sahani wrote:
> CID 1237543 (#1 of 1): Unchecked return value from library
> (CHECKED_RETURN)
> ---
>  src/socket-proxy/socket-proxyd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/socket-proxy/socket-proxyd.c 
> b/src/socket-proxy/socket-proxyd.c
> index ff2b24f..3041903 100644
> --- a/src/socket-proxy/socket-proxyd.c
> +++ b/src/socket-proxy/socket-proxyd.c
> @@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int 
> buffer[2], size_t *sz) {
>  return -errno;
>  }
>  
> -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
> +(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
>  
>  r = fcntl(buffer[0], F_GETPIPE_SZ);
>  if (r < 0) {
For the sake of ML archives...

this was pushed by David.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] units: remove unnecessary ordering dependencies in systemd-hibernate-resume@.service

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 27, 2014 at 08:32:56PM +0400, Ivan Shapovalov wrote:
> -Before=local-fs-pre.target systemd-remount-fs.service 
> systemd-fsck-root.service
> +Before=local-fs-pre.target

Applied.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 08, 2014 at 08:58:53PM +0200, Jan Janssen wrote:
> On 2014-10-08 14:59, Zbigniew Jędrzejewski-Szmek wrote:
> >On Wed, Oct 08, 2014 at 08:24:49AM +0200, Jan Janssen wrote:
> >>
> >>
> >>>Gesendet: Mittwoch, 08. Oktober 2014 um 01:40 Uhr
> >>>Von: "Zbigniew Jędrzejewski-Szmek" 
> >>>An: "Jan Janssen" 
> >>>Cc: systemd-devel@lists.freedesktop.org
> >>>Betreff: Re: [systemd-devel] [PATCH] journal: Fix 
> >>>sd_journal_enumerate_unique skipping values
> >>>
> >>>On Mon, Oct 06, 2014 at 06:57:38PM +0200, Zbigniew Jędrzejewski-Szmek 
> >>>wrote:
> On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote:
> >*bump*
> Sorry, I'll look into this.
> >>>
> >>>Doesn't work. Both without or with your other patch
> >>>sd_journal_enumerate_unique I get bogus results on my test case. It
> >>>seems the issue is more complicated.
> >>>
> >>
> >>That's odd. Care to elaborate what bogus results means? Are you even 
> >>affected by the
> >>bug in question without the patch?
> >
> >Yes, I have a VM where I get a smaller number from -F _BOOT_ID than from 
> >--list-boots
> >(w/o your patches), and then the same smaller number with one or two of your 
> >patches.
> >So results become consistent, but equally bad.
> >
> >Of course I can't know if this is exactly the same bug, but it certainly 
> >looks
> >like it.
> >
> 
> Sounds like maybe one of those calls end up interleaving journals
> from different machines?
> 
> Also, does removing the call to journal_file_object_release() in
> sd_journal_enumerate_unique() improve things or not? How about
> moving it after the if(found) where it was before the patch?
> 
> I'd love to investigate this, but I sadly don't have any journals
> that triggers this :(
Hi,

I now pushed your patch to add release_cookie. I found that the
problem I saw was with sd_j_enumerate_unique getting confused by
removal of corrupted files. See the commit message for longer
explanation. You were right that there's a problem with interleaving
sd_j_e_u and sd_j_next in list_boots(), because this triggered the
issue. I decided to fix this and still allow interleaving.

To reproduce my issue, it is enough to have a file which is corrupted
and this corruption gets detected in sd_j_next(), but the file is in
good enough shape to be opened and pass sd_j_enumerate_unique().
If the file is not the first in hashmap, the problem should occur.

I was inclined to merge your other patch (to remove the interleaving,
especially that it makes the code shorter and simpler), but ultimately
decided against that. It makes the listing noticably slower (1.5 → 1.9 s
in my case). I imagine that on a slower disk this would be even more
visible, as we essentially iterate over the file list twice.

Please test, but note that 'journalctl -F_BOOT_ID' might return *more*
items than 'journalctl --list-boots' because the latter will remove
the files for which it detects corruption. So it is even possible
that simply looking at the journal with normal sequential access
(i.e. plain 'journalctl') can show partial data for boots that
--list-boots will not show. I'm not sure how significant this is
and what to do with that.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] clarify what microsoft and oracle stands for

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 09, 2014 at 10:14:36PM -0400, Rahul Sundaram wrote:
> ---
>  man/systemd-detect-virt.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
> index 1e8230c..4f9980a 100644
> --- a/man/systemd-detect-virt.xml
> +++ b/man/systemd-detect-virt.xml
> @@ -68,8 +68,8 @@
>  virtualization technology. The following technologies
>  are currently identified: qemu,
>  kvm, vmware,
> -microsoft,
> -oracle, xen,
> +microsoft (Hyper-V),
> +oracle (VirtualBox), 
> xen,
>  bochs, chroot,
>  uml,
>  openvz, lxc,

Hi,
I merged this and Dale's descriptions and pushed.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] clarify what microsoft and oracle stands for

[Rahul Sundaram]

---
 man/systemd-detect-virt.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
index 1e8230c..4f9980a 100644
--- a/man/systemd-detect-virt.xml
+++ b/man/systemd-detect-virt.xml
@@ -68,8 +68,8 @@
 virtualization technology. The following technologies
 are currently identified: qemu,
 kvm, vmware,
-microsoft,
-oracle, xen,
+microsoft (Hyper-V),
+oracle (VirtualBox), xen,
 bochs, chroot,
 uml,
 openvz, lxc,
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [question] networkd: Any support for hooks?

[Cameron Norman]

El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann 
 escribió:

Hi Cameron,

 ifupdown [1], NetworkManager, and WICD all support hooks for 
when a
 network interface is configured or deconfigured (before and 
after

 these actions).

 Are there any plans to support something along these lines? If 
so,

 what will that look like?

 If there are no plans, how do networkd's developers feel about 
adding

 the feature (will not merge, or will accept patches, etc.) ?


 I am sceptical to adding hooks, so would need a lot of 
convincing.
 What we do, however, is to expose the configuration state using 
the
 sd-network C API, which external programs can watch and react on 
(see

 how timesyncd and resolved currently works).


 Does the C API allow programs to temporarily stall bringing up or 
down

 the interface, or does it only deliver signals of if state?


 No it does not allow synchronous hooks. Only asynchronous 
notification

 is supported.

 Out of curiosity, where does your aversion to hooks come from? 
Does it
 add significant complication code wise, or is it more with 
respect to
 using networkd before any filesystems are mounted (thus the hook 
files

 would not be present)?


 Well, we want networkd to be clean and properly written, and I 
simply
 have the suspicion that if start allowing glueing in badly 
integrated

 stuff via shell scripts, we'll have a hard time to ever fix this
 again. I mean, network management solutions that shell out to 
external
 tools we have enough, but networkd is really not supposed to be 
like

 that. It shouldn't just be a glued together thing, but somewhat
 uniform.


 Ok, that is a good reason, what I had slightly imagined.

 Now that I have looked in the hook dirs of ifupdown more closely, I
 have noticed pretty much only async stuff, except for some ethtool,
 wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one 
seems

 like it may be misplaced, and is probably just fine in post-down
 (which is async, compared to down).


actually not using avahi-autoipd is the way you really want to go. 
Especially since networkd will do IPv4LL setup for you anyway. Same 
applies to ethtool hooks since they should be done by link files and 
configured by udev.


udev was indeed my first thought for ethtool, however how would the 
ethtool commands be hooked in on containers? Or is ethtool not relevant 
there?


Thanks,
--
Cameron
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote:
> The ExecStart=/bin/true we just add because current systemd versions
> refuse to run service units that have no ExecStart= set. It is on the
> TODO list to allow services also when they have no ExecStart= but with
> an ExecStop=, but this has not been implemented yet.
Isn't this it:

commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
Author: Lennart Poettering 
Date:   Thu Aug 21 18:50:42 2014 +0200

service: allow services of Type=oneshot that specify no ExecStart= commands

This is useful for services that simply want to run something on
shutdown, but not at bootup. They should only set ExecStop= but leave
ExecStart= unset.

Confused,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag

[James Lott]

Whoops.. Meant to send the message:

Installing the latest systemd from git fixed this issue. Thanks again for 
pointing that out!

On Thursday 09 October 2014 15:14:18 James Lott wrote:
> Hi Lennart!
> 
> Thanks for your response! I observed this issue on Arch Linux ARM running
> systemd-216-3, which it appears uses sources from about a week before that
> patch was committed. Thanks for pointing out the commit! I'll compile from
> HEAD and test again
> 
> On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote:
> > On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote:
> > > Hello,
> > > 
> > > A little bit back I wrote in about having some difficulties adding
> > > network
> > > devices to containers. With some help from the list, I figured out how
> > > to
> > > add my network devices to an already running container using 'iw phy'
> > > and
> > > 'ip link'.
> > > 
> > > However, I have not yet successfully added an interface to a container
> > > by
> > > way of the --network-interface flag. Attempting to add any ethernet
> > > devices by this method meets with the error:
> > > 
> > > [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1
> > > Spawning container lanvpn on /home/lanvpn.
> > > Press ^] three times within 1s to kill container.
> > > Failed to move interface eth1 to namespace: File exists
> > > 
> > > According to the systemd-nspawn documentation, it seems like this
> > > invocation should work
> > > 
> > >--network-interface=
> > >
> > >Assign the specified network interface to the container. This
> > >will
> > > 
> > > remove the specified interface from the calling namespace and place it
> > > in
> > > the container.
> > > 
> > >When the container terminates, it is moved back to the host
> > > 
> > > namespace. Note that --network-interface= implies --private-network.
> > > This
> > > option may be used more
> > > 
> > >than once to add multiple network interfaces to the
> > >container.
> > > 
> > > If I'm doing something wrong, then it seems like the documentation may
> > > desire revisiting. If I'm not, then this could be unintended behavior.
> > 
> > Which version of systemd-nspawn are you trying this with? Note that
> > there was a recent fix in the code handling --network-interface=, that
> > might make work what you are trying to do:
> > 
> > http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id=
> > 31 25b3ef5db70d45882c7d6f617705802c5f939e
> > 
> > Lennart
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag

[James Lott]

Hi Lennart!

Thanks for your response! I observed this issue on Arch Linux ARM running 
systemd-216-3, which it appears uses sources from about a week before that 
patch was committed. Thanks for pointing out the commit! I'll compile from 
HEAD and test again 

On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote:
> On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote:
> > Hello,
> > 
> > A little bit back I wrote in about having some difficulties adding network
> > devices to containers. With some help from the list, I figured out how to
> > add my network devices to an already running container using 'iw phy' and
> > 'ip link'.
> > 
> > However, I have not yet successfully added an interface to a container by
> > way of the --network-interface flag. Attempting to add any ethernet
> > devices by this method meets with the error:
> > 
> > [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1
> > Spawning container lanvpn on /home/lanvpn.
> > Press ^] three times within 1s to kill container.
> > Failed to move interface eth1 to namespace: File exists
> > 
> > According to the systemd-nspawn documentation, it seems like this
> > invocation should work
> > 
> >--network-interface=
> >
> >Assign the specified network interface to the container. This
> >will
> > 
> > remove the specified interface from the calling namespace and place it in
> > the container.
> > 
> >When the container terminates, it is moved back to the host
> > 
> > namespace. Note that --network-interface= implies --private-network. This
> > option may be used more
> > 
> >than once to add multiple network interfaces to the container.
> > 
> > If I'm doing something wrong, then it seems like the documentation may
> > desire revisiting. If I'm not, then this could be unintended behavior.
> 
> Which version of systemd-nspawn are you trying this with? Note that
> there was a recent fix in the code handling --network-interface=, that
> might make work what you are trying to do:
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id=31
> 25b3ef5db70d45882c7d6f617705802c5f939e
> 
> Lennart

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container

[James Lott]

Hey there Tom,

No problem! Many thanks for taking the time to check this out and write up a 
patch!

I compiled the latest systemd with the patch you pushed, and my container is 
now able to create a /dev/net/tun device with no problems. However, there 
appears to be a problem with the container being able to actually utilize this 
device. Trying to start up an openvpn connection yields the following error:

Thu Oct  9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: 
Operation not permitted (errno=1)

As requested by Lennart, attached you will find an strace of the openvpn 
process as it attempts to setup the connection. Please let me know if there's 
anything else I can provide to be helpful, and thanks again for the help!

On Wednesday 08 October 2014 15:59:03 you wrote:
> On Fri, Oct 3, 2014 at 7:46 PM, James Lott  wrote:
> > Hello, list!
> > 
> > In some work I've been doing with systemd-nspawn containers, I've been
> > trying to connect one of my containers to an openvpn network. This
> > conteiner is being run with the --network-bridge flag to setup its
> > networking, so according to the documentation, should retain
> > CAP_NET_ADMIN capabilities. However, the container appears to be unable
> > to create a new tun device
> 
> Hi James,
> 
> Thanks for the report, and sorry for the late reply. I just pushed a
> fix to git which creates /dev/net/tun in the container (if it exists
> on the host) and it appears to work for me. Please let me know whether
> this solves your problem.
> 
> Cheers,
> 
> Tom
> 
> > [root@lanvpn ~]# ip tuntap add dev tun0 mode tun
> > open: No such file or directory
> > 
> > I tried retaining the CAP_MKNOD capability for this container using the --
> > capability flag as well, and this met with the same result.
> > 
> > I also tried binding the /dev/net device directory from the parent to the
> > /dev/net device directory of the child container, and added the following
> > line to the systemd-nspawn service file of the container
> > 
> >  [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service
> > 
> > DeviceAllow=/dev/net/tun rwm
> > 
> > This resulted in the error
> > 
> > [root@lanvpn ~]# ip tuntap add tun0 mode tun
> > open: Operation not permitted
> > 
> > Is there any way to run my containers which will allow them to create
> > tun/tap devices? System is arch linux arm, running systemd 216-r3
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
execve("/usr/bin/openvpn", ["/usr/bin/openvpn", "--config", 
"/etc/openvpn/vpngate.conf"], [/* 16 vars */]) = 0
brk(0)  = 0x181f000
uname({sys="Linux", node="lanvpn", ...}) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=23924, ...}) = 0
mmap2(NULL, 23924, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f4
close(3)= 0
open("/usr/lib/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\36\0\0004\0\0\0"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=116240, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6f2
mmap2(NULL, 147604, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb6efb000
mprotect(0xb6f16000, 32768, PROT_NONE)  = 0
mmap2(0xb6f1e000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0xb6f1e000
close(3)= 0
open("/usr/lib/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\\352\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=398287, ...}) = 0
mmap2(NULL, 377668, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb6e9e000
mprotect(0xb6eed000, 32768, PROT_NONE)  = 0
mmap2(0xb6ef5000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4f000) = 0xb6ef5000
close(3)= 0
open("/usr/lib/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200\260\3\0004\0\0\0"..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1770726, ...}) = 0
mmap2(NULL, 1500716, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb6d2f000
mprotect(0xb6e7f000, 28672, PROT_NONE)  = 0
mmap2(0xb6e86000, 86016, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000) = 0xb6e86000
mmap2(0xb6e9b000, 9772, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e9b000
close(3)= 0
open("/usr/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\214\t\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9824, ...}) = 0
mmap2(NULL, 41144, PROT_READ|PROT

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Jóhann B. Guðmundsson]

On 10/09/2014 08:28 PM, "Jóhann B. Guðmundsson" wrote:


What I dont understand what's the usecase for somekind of ExecStop= 
modfications, why do we need to do that? 


Note that the Before= in the test script is failing to pass which 
indicates something is borked in the ordering


I added the Before= line in shutdown-test.service

[Unit]
Description=My Shutdown Test
Before=httpd.service shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown test-4"

[Install]
WantedBy=shutdown.target

And added this line to the httpd.service

ExecStop=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown 
test-4 after shutdown-test.service"


Rebooted and as you can see the shutdown-test.service is being run 
*after* the httpd.service not before...


Oct 09 21:11:15 localhost.localdomain SHUTDOWN[2098]: Systemd shutdown 
test-4 after shutdown-test.service
Oct 09 21:11:16 localhost.localdomain SHUTDOWN[2108]: Systemd shutdown 
test-4


Expected result,  shutdown-test.service being run before httpd.service 
as in...


Oct 09 21:11:15 localhost.localdomain SHUTDOWN[2108]: Systemd shutdown 
test-4
Oct 09 21:11:16 localhost.localdomain SHUTDOWN[2098]: Systemd shutdown 
test-4 after shutdown-test.service
( systemd-208-22.fc20.x86_64 which probably means the dracut and alsa 
units that are tied to the shutdown.target aren't working as expected )


Perhaps that bug is the reason you think we need somekind of ExecStop= 
modfications?


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Jóhann B. Guðmundsson]

On 10/09/2014 02:26 PM, Lennart Poettering wrote:

On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


On 10/08/2014 11:41 PM, Lennart Poettering wrote:

TODO list to allow services also when they have no ExecStart= but with
an ExecStop=, but this has not been implemented yet.

What's the usecase for this behaviour?

Precisely cases like the one described earlier in this thread: when
you want to run something only at shutdown, properly ordered against
other units that are also shut down.


To me that already works just fine.

[Unit]
Description=My Shutdown Test
Before=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown test-2"

[Install]
WantedBy=shutdown.target


 journalctl SYSLOG_IDENTIFIER=SHUTDOWN
-- Logs begin at Thu 2013-10-24 11:47:22 GMT, end at Thu 2014-10-09 
20:00:17 GMT. --
Oct 09 19:57:51 localhost.localdomain SHUTDOWN[1968]: Systemd shutdown 
test-1

-- Reboot --
Oct 09 19:59:19 localhost.localdomain SHUTDOWN[1898]: Systemd shutdown 
test-2

( the former log is from when I initially tested the unit before reboot )

If I wanted to order it after an service I added After=httpd.service

[Unit]
Description=My Shutdown Test
Before=shutdown.target
After=httpd.service
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown test-3"

[Install]
WantedBy=shutdown.target


In my test I added this line to httpd.service
ExecStop=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown 
test-3 Apache Stopped"


Then I rebooted and as you can see things seem to work perfectly as in 
the test case was stopped after apache had stopped make the shutdown 
order correct


# journalctl SYSLOG_IDENTIFIER=SHUTDOWN

-- Reboot --
Oct 09 20:16:37 localhost.localdomain SHUTDOWN[1972]: Systemd shutdown 
test-3 Apache Stopped
Oct 09 20:16:38 localhost.localdomain SHUTDOWN[1985]: Systemd shutdown 
test-3


What I dont understand what's the usecase for somekind of ExecStop= 
modfications, why do we need to do that?


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Fast User Switching does not seem to work

[constantine]

Hello all!

I am not sure this is the appropriate mailing list, and I have also
posted to  intel-...@lists.freedesktop.org (without any solution) and
 arch-gene...@archlinux.org
Please indicate if you recommend me posting the problem to another list.

I am encountering a peculiar problem with Fast User Switching or
Kernel Mode Setting and I do not know how to troubleshoot it.

Suppose the following tty2,3 or VTs:
1. Ctrl+Alt+F2:logged in user in console (no X)
2. Ctrl+Alt+F3:logged in user in console (no X)
3. Ctrl+Alt+F4:logged in user in Desktop Environment (X)
4. Ctrl+Alt+F5:logged in user in Desktop Environment (X)

>From 1 to 2, or 2 to 1 there is no delay.
>From 1,2 to 3, or 1,2 to 4 there is no delay.
>From 3,4 to 1,2 there **is** delay.
>From 3 to 4, or 4 to 3, there **is**delay.

In words: when I run two (or more) Virtual Terminals switching between
them (Ctrl+Alt+F4-5, etc.) takes 2+ seconds. (The VTs are either
simply initiated with startx  from tty2 and tty3 and having only TWM,
xorg-clock and xterm as their open windows OR as different displays
with KDisplay Manager (kdm) in :0 and :1)

I am using an intel graphics driver so I suppose KMS should be enabled
by default and this seems to be the case, but there still are delays
swithing between VTs.

I have followed the instructions at
http://carlosbecker.com/posts/how-to-enable-kms-on-i915-graphiccard-archlinux/
https://wiki.archlinux.org/index.php/kernel_mode_setting
https://wiki.archlinux.org/index.php/Intel_graphics after a fresh Arch
Linux installation, but I am still experiencing the problem.

I am certain it is not a hardware related issue, because I can fast
switch in ubuntu, but not in Arch linux.

My Arch uses systemd and Ubuntu upstart.

Last, I am aware of the systemd's on-demand "feature" of spawning
terminals but I think it is not related to this, since I think I
correctly "pre-spawned" them.

How can I make switching between VTs as instantaneous as possible?




PS:
$ sudo cat /sys/module/i915/parameters/modeset
1

### Note: ### Before starting the "process" of enabling KMS (which I
suppose it should be enabled in the first place, right?) this value
was:-1

$ uname -a
Linux myhostname 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST
2014 x86_64 GNU/Linux

$ lsmod | grep -e drm -e 915 -e kms
crc32_pclmul12915 0
scsi_mod  142915   4 uas,usb_storage,libata,sd_mod
i915   864879  8
button129091 i915
i2c_algo_bit   127441 i915
video  179951 i915
drm_kms_helper492621 i915
drm 258005  10 i915,drm_kms_helper
i2c_core  501525
drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit
intel_gtt   178482 i915,intel_agp

$ sudo lspci -vvnn | head -28 | tail -21
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon
E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev
09) (prog-if 00 [VGA controller])
Subsystem: ASRock Incorporation Device [1849:0152]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c  Data: 4181
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
Kernel modules: i915

$ head -10 /var/log/Xorg.0.log
[ 4.919]
X.Org X Server 1.16.1
Release Date: 2014-09-21
[ 4.919] X Protocol Version 11, Revision 0
[ 4.919] Build Operating System: Linux 3.16.1-1-ARCH x86_64
[ 4.919] Current Operating System: Linux myhostname 3.16.4-1-ARCH
#1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64
[ 4.919] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux
root=UUID=af9a90ee-5db2-4abf-b8be-006a65e9f09e rw quiet
video=SVIDEO-1:d
[ 4.920] Build Date: 21 September 2014  10:53:13AM
[ 4.920]
[ 4.920] Current version of pixman: 0.32.6

### Note: ### As kernel parameters I have also tried video=SVIDEO-1:d,
i915.modeset=1, and nothing, but neither works.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Honor mount.usr*= on kernel command line

[Tobias Hunger]

Lennart, Harald: I did check the kernel sources for the string "\"mount\"":
As expected that string does show up in a couple of places, but it does not
seem to be in use as a module name at this time.

Tobias G-R: Thanks for the instructions on how to use git-send-email:-)

Tobias Hunger (1):
  fstab-generator: Honor mount.usr*= on kernel command line

 man/systemd-fstab-generator.xml   | 76 -
 src/fstab-generator/fstab-generator.c | 90 +--
 2 files changed, 160 insertions(+), 6 deletions(-)

-- 
2.1.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] fstab-generator: Honor mount.usr*= on kernel command line

[Tobias Hunger]

This allows to configure boot loader entries for systems where the
root and usr filesystems are in different subvolumes (or even on
different drives).
---
 man/systemd-fstab-generator.xml   | 76 -
 src/fstab-generator/fstab-generator.c | 90 +--
 2 files changed, 160 insertions(+), 6 deletions(-)

diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml
index e3cf5d2..65b48ee 100644
--- a/man/systemd-fstab-generator.xml
+++ b/man/systemd-fstab-generator.xml
@@ -104,9 +104,83 @@
 (initrd) while
 fstab= is
 honored by both the main system and
-the initrd.  
+the initrd.
 
+
+root=
+
+Takes the root filesystem to 
mount
+in the initrd.
+root= is
+honored by the initrd.
+
+
+rootfstype=
+
+Takes the root filesystem type 
that
+will be passed to the mount command.
+rootfstype= is
+honored by the initrd.
+
+
+rootflags=
+
+Takes the root filesystem 
mount options
+to use. rootflags= is
+honored by the initrd.
+
+
+mount.usr=
+
+Takes the 
/usr
+filesystem to be mounted by the initrd. If
+mount.usrfstype= or
+mount.usrflags= is set, then
+mount.usr= will default to 
the value set in
+root=.
+
+Otherwise this parameter defaults to the
+/usr entry
+found in /etc/fstab on 
the root
+filesystem.
+
+mount.usr= is honored 
by the initrd.
+
+
+
+
mount.usrfstype=
+
+Takes the 
/usr
+filesystem type that will be passed to the 
mount
+command. If mount.usr= or
+mount.usrflags= is set, then
+mount.usrfstype= will 
default to the value set in
+rootfstype=.
+
+Otherwise this value will be read from 
the
+/usr entry in
+/etc/fstab on the root 
filesystem.
+
+mount.usrfstype= is
+honored by the initrd.
+
+
+mount.usrflags=
+
+Takes the 
/usr
+filesystem mount options to use. If
+mount.usr= or
+mount.usrfstype= is set, 
then
+mount.usrflages= will 
default to the value set in
+rootflags=.
 
+Otherwise this value will be read from 
the
+/usr entry in
+/etc/fstab on the root 
filesystem.
+
+mount.usrflags= is
+honored by the initrd.
+
 
 
 
diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index b75bbb7..32a8f9b 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -43,6 +43,9 @@ static char *arg_root_what = NULL;
 static char *arg_root_fstype = NULL;
 static char *arg_root_options = NULL;
 static int arg_root_rw = -1;
+static char *arg_usr_what = NULL;
+static char *arg_usr_fstype = NULL;
+static char *arg_usr_options = NULL;
 
 
 static int mount_find_pri(struct mntent *me, int *ret) {
@@ -494,12 +497,64 @@ static int add_root_mount(void) {
  "/proc/cmdline");
 }
 
+static int add_usr_mount(void) {
+_cleanup_free_ char *what = NULL;
+const char *opts;
+
+if (!arg_usr_what && !arg_usr_fstype && !arg_usr_options)
+  

Re: [systemd-devel] [feature request] allow instances in file.preset

[Damien Robert]

>From Lennart Poettering, Thu 09 Oct 2014 at 16:44:42 (+0200) :
> > > > > But this means it
> > > > > would only find the template, and the instance would have to come from
> > > > > somewhere else, but where?
> > > > From the preset file?
> > > No, we enumerate the installed unit files, and then look them up in
> > > the preset files. 
> > Yes, I meant you can't do the otherway around anyway (enumerate lines in
> > preset files and enable/disable them accordingly) because the preset
> > information is given by globs.
> This feels wrong. The preset files are actually globs, not full file
> names. They are not really suitable as a list of filenames, but only
> as something to match file names against...

Yes, this is exactly what I was saying, sorry for the miscommunication...

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 09/25] shared/socket-util: don't fail if libc doesn't support IDN

[Lennart Poettering]

On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote:

> ---
>  src/shared/socket-util.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c
> index e3e54e8..d4a1679 100644
> --- a/src/shared/socket-util.c
> +++ b/src/shared/socket-util.c
> @@ -41,6 +41,16 @@
>  #include "missing.h"
>  #include "fileio.h"
>  
> +/* Don't fail if the standard library
> + * doesn't support IDN */
> +#ifndef NI_IDN
> +#define NI_IDN 0
> +#endif
> +
> +#ifndef NI_IDN_USE_STD3_ASCII_RULES
> +#define NI_IDN_USE_STD3_ASCII_RULES 0
> +#endif

If glibc supports building in a way that these are no defined I am
willing to merge this (though it would belong in missing.h, not into
sockt-util.c). However, I am pretty sure that glibc defines this even
if IDN is disabled in the build, and if that's the case then your libc
should really do the same.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.

[Daniel Buch]

Cool, seems fixed.

okt 09 19:18:34 dbuch-laptop systemd[1]: Starting Hostname Service...
okt 09 19:18:34 dbuch-laptop systemd[1]: Started Hostname Service.
okt 09 19:20:34 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping
timed out. Terminating.
okt 09 19:20:34 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service
entered failed state.
okt 09 19:20:34 dbuch-laptop systemd[1]: systemd-hostnamed.service failed.
okt 09 19:20:57 dbuch-laptop systemd[1]: Starting Hostname Service...
okt 09 19:20:57 dbuch-laptop systemd[1]: Started Hostname Service.
okt 09 19:22:57 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping
timed out. Terminating.
okt 09 19:22:57 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service
entered failed state.
okt 09 19:22:57 dbuch-laptop systemd[1]: systemd-hostnamed.service failed.
-- Reboot --
okt 09 19:49:34 dbuch-laptop systemd[1]: Starting Hostname Service...
okt 09 19:49:34 dbuch-laptop systemd[1]: Started Hostname Service.
dbuch@dbuch-laptop ~ % date
tor okt  9 19:55:13 CEST 2014
dbuch@dbuch-laptop ~ % systemctl --failed
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

They used to timeout after 2 minutes so this looks promising.

2014-10-09 18:23 GMT+02:00 Lennart Poettering :

> On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote:
>
> > Hi,
> >
> > With current git and since 430e21c2f7e77d600257ead56419f51 i keep on
> > getting timeout on these units
> >
> > dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed
> >   UNIT  LOAD   ACTIVE SUBDESCRIPTION
> > ● systemd-hostnamed.service loaded failed failed Hostname Service
> > ● systemd-localed.service   loaded failed failed Locale Service
> > ● systemd-timedated.service loaded failed failed Time & Date Service
> >
> >
> > My build config looks like this:
> >   --libexecdir=/usr/lib \
> >   --localstatedir=/var \
> >   --sysconfdir=/etc \
> >   --enable-introspection \
> >   --enable-gtk-doc \
> >   --enable-kdbus \
> >   --enable-compat-libs \
> >   --enable-timesyncd \
> >   --enable-lz4 \
> >   --enable-terminal \
> >   --enable-resolved \
> >   --disable-audit \
> >   --disable-ima \
> >   --disable-multi-seat-x \
> >   --disable-smack \
> >   --with-sysvinit-path= \
> >   --with-sysvrcnd-path= \
> >   --with-firmware-path="/usr/lib/firmware/updates:/usr/lib/firmware"
> \
> >
> >
> > Am i missing something? I havn't yet found any solution yet, and journal
> > isn't helping me much here.
>
> I think Michal just fixed this with this commit:
>
>
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=6041a7ee2c1bbff6301082f192fc1b0882400d42
>
> Could you check, please?
>
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Tobias Geerinckx-Rice]

On 9 October 2014 17:30, Tobias Hunger  wrote:

> PS: How do you send patches to this list via gmail? I pasted the output from
> git format-patch into the mail client, bit there got to be a better way:-)

Using "git send-email" works surprisingly well with Gmail [1].

Regards,

T G-R

[1] See https://coderwall.com/p/dp-gka for an example
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.

[Lennart Poettering]

On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote:

> Hi,
> 
> With current git and since 430e21c2f7e77d600257ead56419f51 i keep on
> getting timeout on these units
> 
> dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed
>   UNIT  LOAD   ACTIVE SUBDESCRIPTION
> ● systemd-hostnamed.service loaded failed failed Hostname Service
> ● systemd-localed.service   loaded failed failed Locale Service
> ● systemd-timedated.service loaded failed failed Time & Date Service
> 
> 
> My build config looks like this:
>   --libexecdir=/usr/lib \
>   --localstatedir=/var \
>   --sysconfdir=/etc \
>   --enable-introspection \
>   --enable-gtk-doc \
>   --enable-kdbus \
>   --enable-compat-libs \
>   --enable-timesyncd \
>   --enable-lz4 \
>   --enable-terminal \
>   --enable-resolved \
>   --disable-audit \
>   --disable-ima \
>   --disable-multi-seat-x \
>   --disable-smack \
>   --with-sysvinit-path= \
>   --with-sysvrcnd-path= \
>   --with-firmware-path="/usr/lib/firmware/updates:/usr/lib/firmware" \
> 
> 
> Am i missing something? I havn't yet found any solution yet, and journal
> isn't helping me much here.

I think Michal just fixed this with this commit:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=6041a7ee2c1bbff6301082f192fc1b0882400d42

Could you check, please?


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Lennart Poettering]

On Thu, 09.10.14 17:30, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> I will update the patch as soon as I get home :-)
> 
> Best Regards,
> Tobias
> 
> PS: How do you send patches to this list via gmail? I pasted the output
> from git format-patch into the mail client, bit there got to be a better
> way:-)

It's OK to just attach the git-format-patch formatted patches to your
mail, even if it isn't the "wahre Lehre".

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Tobias Hunger]

I will update the patch as soon as I get home :-)

Best Regards,
Tobias

PS: How do you send patches to this list via gmail? I pasted the output
from git format-patch into the mail client, bit there got to be a better
way:-)
On Oct 9, 2014 4:08 PM, "Lennart Poettering"  wrote:

> On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
> > On Oct 8, 2014 2:15 PM, "Harald Hoyer"  wrote:
> > > > What is the rationale of this patch?
> > > > Supporting systems without /etc/fstab in the root device?
> > > > Overriding the /etc/fstab settings?
> > > >
> > > > In a systemd initrd (e.g. in dracut) as soon as
> initrd-root-fs.target is
> > > > reached, initrd-parse-etc.service is executed, which retriggers the
> > > > fstab-generator and reads fstab from the real root and generates
> units
> > for /usr.
> >
> > Hello Harald,
> >
> > The use case is exactly the one Lennart described in his blog about
> > deploying Linux in the future.
> >
> > My setup now looks like this: I got a Btrfs partition for my Linux
> > installations. This partition has a subvol root:somename:someid:x86_64
> > containing a Linux installation minus /use.
> >
> > Then I have several versions of /use for that distribution in more
> > subvolumes named usr:someid:x86_64:version (all with different versions,
> > basically getting incremented whenever a new set of packages gets
> > installed).
> >
> > The idea is to now be able to write bootloader entries for all versions
> the
> > somename-installation.
> >
> > For that the initrd needs to know which /usr to mount on top of the root
> > partition.
> >
> > I can not use the fstab from the root drive here, because that would
> always
> > point to the same version of /use, preventing me to roll back/forward
> when
> > something breaks during an upgrade.
> >
> > What I could do instead is to put the information about which subvol to
> > mount at /use into the initrd. But I actually think the way of passing
> this
> > into initrd in the same way as the rootfs is more consistent and it also
> > saves me from having a new initrd in /boot when libreoffice gets updated.
> > That *might* be necessary when using secure boot, but only then.
> >
> > Does this explain my motivation for this patch sufficiently?
>
> Hmm, so I think this should be merged, but I'd like to ask for one
> more change. We really want to avoid inventing new non-namespaced
> kernel command line options, that's really something we should leave
> to the kernel guys...
>
> Hence, I'd propose using "mount.usr=", "mount.usrflags=" and
> "mount.usrfstype="... Or maybe "fs." as prefix? Or "mnt."? But I think
> "mount." is the nicest one, even if it is slightly more to type.
>
> Hope that make sense?
>
> (OTOH I just yesterday merged a patch that introduced a new
> un-namespaced kernel cmdline option "rescue", so I am not totall fair
> here, but I think that's a special case...)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [feature request] allow instances in file.preset

[Lennart Poettering]

On Thu, 09.10.14 11:42, Damien Robert (damien.olivier.rob...@gmail.com) wrote:

> >From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) :
> > On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) 
> > wrote:
> > > > But this means it
> > > > would only find the template, and the instance would have to come from
> > > > somewhere else, but where?
> > > From the preset file?
> > No, we enumerate the installed unit files, and then look them up in
> > the preset files. 
> 
> Yes, I meant you can't do the otherway around anyway (enumerate lines in
> preset files and enable/disable them accordingly) because the preset
> information is given by globs.

This feels wrong. The preset files are actually globs, not full file
names. They are not really suitable as a list of filenames, but only
as something to match file names against...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Harald Hoyer]

On 09.10.2014 16:24, Harald Hoyer wrote:
> On 09.10.2014 16:08, Lennart Poettering wrote:
>> On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>>
>>> On Oct 8, 2014 2:15 PM, "Harald Hoyer"  wrote:
> What is the rationale of this patch?
> Supporting systems without /etc/fstab in the root device?
> Overriding the /etc/fstab settings?
>
> In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
> reached, initrd-parse-etc.service is executed, which retriggers the
> fstab-generator and reads fstab from the real root and generates units
>>> for /usr.
>>>
>>> Hello Harald,
>>>
>>> The use case is exactly the one Lennart described in his blog about
>>> deploying Linux in the future.
>>>
>>> My setup now looks like this: I got a Btrfs partition for my Linux
>>> installations. This partition has a subvol root:somename:someid:x86_64
>>> containing a Linux installation minus /use.
>>>
>>> Then I have several versions of /use for that distribution in more
>>> subvolumes named usr:someid:x86_64:version (all with different versions,
>>> basically getting incremented whenever a new set of packages gets
>>> installed).
>>>
>>> The idea is to now be able to write bootloader entries for all versions the
>>> somename-installation.
>>>
>>> For that the initrd needs to know which /usr to mount on top of the root
>>> partition.
>>>
>>> I can not use the fstab from the root drive here, because that would always
>>> point to the same version of /use, preventing me to roll back/forward when
>>> something breaks during an upgrade.
>>>
>>> What I could do instead is to put the information about which subvol to
>>> mount at /use into the initrd. But I actually think the way of passing this
>>> into initrd in the same way as the rootfs is more consistent and it also
>>> saves me from having a new initrd in /boot when libreoffice gets updated.
>>> That *might* be necessary when using secure boot, but only then.
>>>
>>> Does this explain my motivation for this patch sufficiently?
>>
>> Hmm, so I think this should be merged, but I'd like to ask for one
>> more change. We really want to avoid inventing new non-namespaced
>> kernel command line options, that's really something we should leave
>> to the kernel guys...
>>
>> Hence, I'd propose using "mount.usr=", "mount.usrflags=" and
>> "mount.usrfstype="... Or maybe "fs." as prefix? Or "mnt."? But I think
>> "mount." is the nicest one, even if it is slightly more to type.
>>
>> Hope that make sense?
>>
>> (OTOH I just yesterday merged a patch that introduced a new
>> un-namespaced kernel cmdline option "rescue", so I am not totall fair
>> here, but I think that's a special case...)
>>
>> Lennart
>>
> 
> Just be careful choosing the prefix. It must not be the name of a kernel
> module, otherwise this kernel module is presented with all those options, 
> which
> might freak out that module.
> 
> I accidentally chose "rd." not knowing that "rd" is a module alias for the brd
> kernel module.
> 
> Just check with a recent kernel:
> # modinfo ""

Oh, that might not work with builtin modules and not shipped modules. So you
have to manually check the kernel source code :-/

> 
> I have the feeling, we should somehow register a namespace for userspace on 
> the
> kernel command line or have global list. :-/
> 
> I just don't want to end with something like
> org.freedesktop.systemd.log_level=... :-)
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Lennart Poettering]

On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> 
> On 10/08/2014 11:41 PM, Lennart Poettering wrote:
> >TODO list to allow services also when they have no ExecStart= but with
> >an ExecStop=, but this has not been implemented yet.
> 
> What's the usecase for this behaviour?

Precisely cases like the one described earlier in this thread: when
you want to run something only at shutdown, properly ordered against
other units that are also shut down.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Harald Hoyer]

On 09.10.2014 16:08, Lennart Poettering wrote:
> On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> 
>> On Oct 8, 2014 2:15 PM, "Harald Hoyer"  wrote:
 What is the rationale of this patch?
 Supporting systems without /etc/fstab in the root device?
 Overriding the /etc/fstab settings?

 In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
 reached, initrd-parse-etc.service is executed, which retriggers the
 fstab-generator and reads fstab from the real root and generates units
>> for /usr.
>>
>> Hello Harald,
>>
>> The use case is exactly the one Lennart described in his blog about
>> deploying Linux in the future.
>>
>> My setup now looks like this: I got a Btrfs partition for my Linux
>> installations. This partition has a subvol root:somename:someid:x86_64
>> containing a Linux installation minus /use.
>>
>> Then I have several versions of /use for that distribution in more
>> subvolumes named usr:someid:x86_64:version (all with different versions,
>> basically getting incremented whenever a new set of packages gets
>> installed).
>>
>> The idea is to now be able to write bootloader entries for all versions the
>> somename-installation.
>>
>> For that the initrd needs to know which /usr to mount on top of the root
>> partition.
>>
>> I can not use the fstab from the root drive here, because that would always
>> point to the same version of /use, preventing me to roll back/forward when
>> something breaks during an upgrade.
>>
>> What I could do instead is to put the information about which subvol to
>> mount at /use into the initrd. But I actually think the way of passing this
>> into initrd in the same way as the rootfs is more consistent and it also
>> saves me from having a new initrd in /boot when libreoffice gets updated.
>> That *might* be necessary when using secure boot, but only then.
>>
>> Does this explain my motivation for this patch sufficiently?
> 
> Hmm, so I think this should be merged, but I'd like to ask for one
> more change. We really want to avoid inventing new non-namespaced
> kernel command line options, that's really something we should leave
> to the kernel guys...
> 
> Hence, I'd propose using "mount.usr=", "mount.usrflags=" and
> "mount.usrfstype="... Or maybe "fs." as prefix? Or "mnt."? But I think
> "mount." is the nicest one, even if it is slightly more to type.
> 
> Hope that make sense?
> 
> (OTOH I just yesterday merged a patch that introduced a new
> un-namespaced kernel cmdline option "rescue", so I am not totall fair
> here, but I think that's a special case...)
> 
> Lennart
> 

Just be careful choosing the prefix. It must not be the name of a kernel
module, otherwise this kernel module is presented with all those options, which
might freak out that module.

I accidentally chose "rd." not knowing that "rd" is a module alias for the brd
kernel module.

Just check with a recent kernel:
# modinfo ""

I have the feeling, we should somehow register a namespace for userspace on the
kernel command line or have global list. :-/

I just don't want to end with something like
org.freedesktop.systemd.log_level=... :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Lennart Poettering]

On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> On Oct 8, 2014 2:15 PM, "Harald Hoyer"  wrote:
> > > What is the rationale of this patch?
> > > Supporting systems without /etc/fstab in the root device?
> > > Overriding the /etc/fstab settings?
> > >
> > > In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
> > > reached, initrd-parse-etc.service is executed, which retriggers the
> > > fstab-generator and reads fstab from the real root and generates units
> for /usr.
> 
> Hello Harald,
> 
> The use case is exactly the one Lennart described in his blog about
> deploying Linux in the future.
> 
> My setup now looks like this: I got a Btrfs partition for my Linux
> installations. This partition has a subvol root:somename:someid:x86_64
> containing a Linux installation minus /use.
> 
> Then I have several versions of /use for that distribution in more
> subvolumes named usr:someid:x86_64:version (all with different versions,
> basically getting incremented whenever a new set of packages gets
> installed).
> 
> The idea is to now be able to write bootloader entries for all versions the
> somename-installation.
> 
> For that the initrd needs to know which /usr to mount on top of the root
> partition.
> 
> I can not use the fstab from the root drive here, because that would always
> point to the same version of /use, preventing me to roll back/forward when
> something breaks during an upgrade.
> 
> What I could do instead is to put the information about which subvol to
> mount at /use into the initrd. But I actually think the way of passing this
> into initrd in the same way as the rootfs is more consistent and it also
> saves me from having a new initrd in /boot when libreoffice gets updated.
> That *might* be necessary when using secure boot, but only then.
> 
> Does this explain my motivation for this patch sufficiently?

Hmm, so I think this should be merged, but I'd like to ask for one
more change. We really want to avoid inventing new non-namespaced
kernel command line options, that's really something we should leave
to the kernel guys...

Hence, I'd propose using "mount.usr=", "mount.usrflags=" and
"mount.usrfstype="... Or maybe "fs." as prefix? Or "mnt."? But I think
"mount." is the nicest one, even if it is slightly more to type.

Hope that make sense?

(OTOH I just yesterday merged a patch that introduced a new
un-namespaced kernel cmdline option "rescue", so I am not totall fair
here, but I think that's a special case...)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] Added test for unit file state returned by unit_file_get_state and unit_file_get_list. Made test-enabled units more basic, removing superfluous fields. Cleaned up test p

[David Timothy Strauss]

It looks like newlines at the end of the new files are inconsistent
("No newline at end of file").

Other than that +1. It's great to add tests, have them pass on master,
optimize master (the next patch), and then still have them pass.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Susant Sahani]

CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
 src/socket-proxy/socket-proxyd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..3041903 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int 
buffer[2], size_t *sz) {
 return -errno;
 }
 
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
 
 r = fcntl(buffer[0], F_GETPIPE_SZ);
 if (r < 0) {
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Susant Sahani]

On 10/03/2014 12:21 AM, Lennart Poettering wrote:

On Fri, 19.09.14 13:27, Susant Sahani (sus...@redhat.com) wrote:


CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
  src/socket-proxy/socket-proxyd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..7b0714d 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,11 @@ static int connection_create_pipes(Connection *c, int 
buffer[2], size_t *sz) {
  return -errno;
  }

-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+if (r < 0) {
+log_error("Failed to set pipe buffer size: %m");
+return -errno;
+}


If this is about making coverity shut up: doesn't coverity undestand a
syntax like the following?

(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);

I.e. by explicitly casting the result of fcntl into void, coverity
should really understand that we don't really care about the result.


Sorry for the late reply. Casting with void indeed works. Tested with 
splint.

Thanks for the tip.


Would be happy to take a patch for that (if coverity groks this...)


Re-sending.



Lennart




Susant
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)

[Jóhann B. Guðmundsson]

On 10/08/2014 11:41 PM, Lennart Poettering wrote:

TODO list to allow services also when they have no ExecStart= but with
an ExecStop=, but this has not been implemented yet.


What's the usecase for this behaviour?

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate

[Lennart Poettering]

On Thu, 09.10.14 12:55, Jan Synacek (jsyna...@redhat.com) wrote:

> Lennart Poettering  writes:
> > On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote:
> >
> >> I didn't dare fix this in zsh completion (not sure if it's required, 
> >> though, so
> >> I didn't even remove the TODO entry that mentions this fix is required).
> >> 
> >> Jan Synacek (1):
> >>   bash-completion: fix systemctl isolate
> >> 
> >>  shell-completion/bash/systemctl.in | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > Hmm, the actual patch is missing?
> 
> Nope, I can see it in my mail and it the systemd-devel archives as
> well. This is just a cover letter I used to explain additional stuff.

Hmm, there's something wrong with mail delivery on fdo as it seems.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [HEADS-UP] A schedule for the systemd hackfest next week?

[Lennart Poettering]

Heya!

Next week we'll have the next systemd hackfest, at the Linux Plumbers
Conference 2014, in Düsseldorf Germany. Please consider signing up
here if you haven't done so:

https://plus.google.com/u/0/events/c9d1h0i18rt47v42bqku24u6f38

Given that we have a room for two days in parallel to most of LPC, and
a lot of things to discuss and hack on, I figured it might be useful
to have a rough schedule so that people can drop in and leave
depending on the topic we will focus on.

I put an initial attempt for such a schedule up here:

https://docs.google.com/document/d/1eKbEbVtJf5PfWpMMlEwqQrjdhq9-rrRo3TSP4eKGBZg/pub

Any suggestions for changes in the schedule? Other relevant topics
that should be added?

Feedback very welcome!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate

[Jan Synacek]

Lennart Poettering  writes:
> On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote:
>
>> I didn't dare fix this in zsh completion (not sure if it's required, though, 
>> so
>> I didn't even remove the TODO entry that mentions this fix is required).
>> 
>> Jan Synacek (1):
>>   bash-completion: fix systemctl isolate
>> 
>>  shell-completion/bash/systemctl.in | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> Hmm, the actual patch is missing?

Nope, I can see it in my mail and it the systemd-devel archives as
well. This is just a cover letter I used to explain additional stuff.

-- 
Jan Synacek
Software Engineer, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats

[Lennart Poettering]

On Thu, 09.10.14 09:58, Daniel P. Berrange (berra...@redhat.com) wrote:

> > Hmm, also, we already have a really bad formatter in place for the
> > journal catalog files (which only replaces @foo@ by the value of field
> > foo). We should probably use the same code for this new journalctl
> > formatter and the catalog code. In fact the catalog formatter could
> > really use some improvement...
> 
> Ok, I didn't know about the catalog files until now, so I'll
> investigate that and see what I can do about unifying the code
> for these two options.

That would be fantastic!

> Do you consider the catalog file format to be part of the stable
> ABI ?  ie, do we need to preserve support for @foo@  if we took
> the "%s{FOO}" approach ?

I figure the @xyz@ syntax needs to stay. I mean, I doubt this is
widely used yet (we never really advertised it that much), but then
again it has been in place for a while now. So I figure we should
change the catalog files we ship to the new syntax, but still
alternatively support the old syntax, but only in the catalog files...

> > Maybe something like this:
> > 
> > journalctl -O "%t %s{CODE_FILE}:%s{CODE_LINE} 
> > %d{_SOURCE_REALTIME_TIMESTAMP}"
> > 
> > or something like that, where %t would simply map to the timestamp,
> > and %s{} maps to a field name, and %d{} the same, but reformats the
> > field as timestamp, assuming it is a UNIX timestamp formatted as
> > number...
> > 
> > Or something like that...
> 
> Yep, that would work for me. I'll cook up another patch to demonstrate
> that approach along with catalog support.

Thanks! That'd be lovely!

> I'm about to be travelling for KVM Forum / LinuxCon so probably won't get
> a chance to send an updated patch for a week or two.

See you in Düsseldorf!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bash-completion: fix systemctl isolate

[Lennart Poettering]

On Thu, 09.10.14 12:03, Jan Synacek (jsyna...@redhat.com) wrote:

> I didn't dare fix this in zsh completion (not sure if it's required, though, 
> so
> I didn't even remove the TODO entry that mentions this fix is required).
> 
> Jan Synacek (1):
>   bash-completion: fix systemctl isolate
> 
>  shell-completion/bash/systemctl.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Hmm, the actual patch is missing?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] bash-completion: fix systemctl isolate

[Jan Synacek]

I didn't dare fix this in zsh completion (not sure if it's required, though, so
I didn't even remove the TODO entry that mentions this fix is required).

Jan Synacek (1):
  bash-completion: fix systemctl isolate

 shell-completion/bash/systemctl.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
1.9.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] booting A/B rootfs

[Lennart Poettering]

On Thu, 09.10.14 06:13, Darko Luketic (i...@icod.de) wrote:

> Hi,
> 
> I have limited knowledge of the boot process.
> I'm wondering if the following is possible with systemd.
> 
> Imagine you have 2 rootfs partitions.
> You build a new rootfs on a security update or when a new version of a
> listed package that has dependencies is released and extract this on
> either A or B partition (A if B is the current rootfs, B if A is the
> current rootfs)
> The idea is, with systemd you can isolate targets. I assume you could
> shutdown all services so that nothing but systemd is running.
> Then unmount the current rootfs and mount the new rootfs and boot to
> default target.
> All without needing to poweroff or physically reboot the system.
> Only if you install a new kernel a "real" reboot would be required.
> Would this be possible with systemd in its current state?

This has been requested before, but is currently not nicely supported,
but I am open to adding some support for this. Note though that you
probably need to do more than just stopping all services, you need to
at least flush out /run, too, plus some other things like /dev/shm, or
the sysvipc objects.

The part of this that I think might be suitable for direct integration
into systemd is the above plus maybe high-level support in "systemctl"
to get a new verb for rebooting this way. The swapping of the
partitions though probably something to do externally, integrated in
the same way as the current dracut/initrd shutdown logic is
integrated, which disassembles the root disk: after systemd did
everything it could do it transitions back into the initrd which then
does what it needs to do.

In fact, you probably could use the initrd logic for this already,
just place a script /run/initramfs/shutdown, do the flushing of
/run+sysv manually, and then simply reexec systemd again. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] logind: mount per-user tmpfs with 'smackfsroot=*' for smack enabled systems

[Lennart Poettering]

On Thu, 09.10.14 11:02, Lukasz Skalski (l.skal...@samsung.com) wrote:

Applied! Thanks!

> ---
>  src/login/logind-user.c | 8 +++-
>  units/systemd-logind.service.in | 2 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/login/logind-user.c b/src/login/logind-user.c
> index d48eca4..3847496 100644
> --- a/src/login/logind-user.c
> +++ b/src/login/logind-user.c
> @@ -37,6 +37,7 @@
>  #include "conf-parser.h"
>  #include "clean-ipc.h"
>  #include "logind-user.h"
> +#include "smack-util.h"
>  
>  User* user_new(Manager *m, uid_t uid, gid_t gid, const char *name) {
>  User *u;
> @@ -325,7 +326,12 @@ static int user_mkdir_runtime_path(User *u) {
>  
>  mkdir(p, 0700);
>  
> -if (asprintf(&t, "mode=0700,uid=" UID_FMT ",gid=" GID_FMT 
> ",size=%zu", u->uid, u->gid, u->manager->runtime_dir_size) < 0) {
> +if (use_smack())
> +r = asprintf(&t, "mode=0700,smackfsroot=*,uid=" 
> UID_FMT ",gid=" GID_FMT ",size=%zu", u->uid, u->gid, 
> u->manager->runtime_dir_size);
> +else
> +r = asprintf(&t, "mode=0700,uid=" UID_FMT ",gid=" 
> GID_FMT ",size=%zu", u->uid, u->gid, u->manager->runtime_dir_size);
> +
> +if (r < 0) {
>  r = log_oom();
>  goto fail;
>  }
> diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in
> index c6cbd1c..f087e99 100644
> --- a/units/systemd-logind.service.in
> +++ b/units/systemd-logind.service.in
> @@ -23,7 +23,7 @@ ExecStart=@rootlibexecdir@/systemd-logind
>  Restart=always
>  RestartSec=0
>  BusName=org.freedesktop.login1
> -CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL 
> CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
> +CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL 
> CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER 
> CAP_SYS_TTY_CONFIG
>  WatchdogSec=1min
>  
>  # Increase the default a bit in order to allow many simultaneous
> -- 
> 1.9.3
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shell expressions in EnvironmentFile

[Lennart Poettering]

On Thu, 09.10.14 10:00, Damien Robert (damien.olivier.rob...@gmail.com) wrote:

> >From Lennart Poettering, Wed 08 Oct 2014 at 20:48:55 (+0200) :
> > SyslogIdentifier= should do it.
> 
> It works, thanks!
> 
> > See systemd.exec(5) for details.
> 
> When I was looking for something like that in the doc, I was confused by
> this passage: "This option is only useful when StandardOutput= or
> StandardError= are set to syslog or kmsg.", but it apparently actually
> works with StandardOutput=journal.

Oh, indeed. That's a bug in the man page. Fixed now. Thanks for the pointer!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked

[Lennart Poettering]

On Thu, 09.10.14 07:21, Jan Synacek (jsyna...@redhat.com) wrote:

> >> > > A related thing: there's a mapping bus-error <-> errno implemented,
> >> > > but it only works for the errors defined in the library itself. It
> >> > > would be nice to extend this mapping to the "user" defined errors,
> >> > > e.g. in core/.  Would you be amenable to adding a mechianism to
> >> > > register additional mappings like bus-error-mapping.gperf so that they
> >> > > are used by the library?
> >> > 
> >> > Maybe have internal versions of the conversion calls that allow
> >> > passing in an additional table?
> >> That is not as convenient. E.g. sd_bus_error_set
> >> internally calls bus_error_name_to_errno. Currently, this always
> >> returns EIO for errors unknown to the library, and then the caller
> >> does it own lookup (e.g. looking at 
> >> transaction_add_job_and_dependencies()).
> >
> > What precisely are you proposing instead?
> 
> What about "extending" usage of errno with systemd specific errors?
> Something like EUNITMASKED or E?  Plus,
> implementing extended version of strerror(), which would use the
> standard stderror() for the standard errno?

Well, using errno-style errors is certainly handy, but let's face it,
it's not particularly descriptive. Before attempting to extending it
we should probably look at other options, such as adopting
sd_bus_error at more places, which allows more flexible identifiers as
well as descriptive strings.

Also, we return these errnos in many of our public APIs. We really
should never return something there that cannot be made sense of
externally, since people might (and should be able to) escalate the
errors unmodified up the chain, where the immediate systemd context is
lost or unknown. (Also, just think what would happen if multiple
libraries would extend errno that way! how confusing would that get).

So, my suggestion is to either accept the limited vocabulary of errno
for this case (which I don't think is such a loss here), or to go for
sd_bus_error, but some entirely new concept sounds less than ideal.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] logind: mount per-user tmpfs with 'smackfsroot=*' for smack enabled systems

[Lukasz Skalski]

---
 src/login/logind-user.c | 8 +++-
 units/systemd-logind.service.in | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index d48eca4..3847496 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -37,6 +37,7 @@
 #include "conf-parser.h"
 #include "clean-ipc.h"
 #include "logind-user.h"
+#include "smack-util.h"
 
 User* user_new(Manager *m, uid_t uid, gid_t gid, const char *name) {
 User *u;
@@ -325,7 +326,12 @@ static int user_mkdir_runtime_path(User *u) {
 
 mkdir(p, 0700);
 
-if (asprintf(&t, "mode=0700,uid=" UID_FMT ",gid=" GID_FMT 
",size=%zu", u->uid, u->gid, u->manager->runtime_dir_size) < 0) {
+if (use_smack())
+r = asprintf(&t, "mode=0700,smackfsroot=*,uid=" 
UID_FMT ",gid=" GID_FMT ",size=%zu", u->uid, u->gid, 
u->manager->runtime_dir_size);
+else
+r = asprintf(&t, "mode=0700,uid=" UID_FMT ",gid=" 
GID_FMT ",size=%zu", u->uid, u->gid, u->manager->runtime_dir_size);
+
+if (r < 0) {
 r = log_oom();
 goto fail;
 }
diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in
index c6cbd1c..f087e99 100644
--- a/units/systemd-logind.service.in
+++ b/units/systemd-logind.service.in
@@ -23,7 +23,7 @@ ExecStart=@rootlibexecdir@/systemd-logind
 Restart=always
 RestartSec=0
 BusName=org.freedesktop.login1
-CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL 
CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
+CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN 
CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
 WatchdogSec=1min
 
 # Increase the default a bit in order to allow many simultaneous
-- 
1.9.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Harald Hoyer]

On 09.10.2014 09:37, Tobias Hunger wrote:
> 
> On Oct 8, 2014 2:15 PM, "Harald Hoyer"  > wrote:
>> > What is the rationale of this patch?
>> > Supporting systems without /etc/fstab in the root device?
>> > Overriding the /etc/fstab settings?
>> >
>> > In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
>> > reached, initrd-parse-etc.service is executed, which retriggers the
>> > fstab-generator and reads fstab from the real root and generates units for
> /usr.
> 
> Hello Harald,
> 
> The use case is exactly the one Lennart described in his blog about deploying
> Linux in the future.
> 
> My setup now looks like this: I got a Btrfs partition for my Linux
> installations. This partition has a subvol root:somename:someid:x86_64
> containing a Linux installation minus /use.
> 
> Then I have several versions of /use for that distribution in more subvolumes
> named usr:someid:x86_64:version (all with different versions, basically 
> getting
> incremented whenever a new set of packages gets installed).
> 
> The idea is to now be able to write bootloader entries for all versions the
> somename-installation.
> 
> For that the initrd needs to know which /usr to mount on top of the root 
> partition.
> 
> I can not use the fstab from the root drive here, because that would always
> point to the same version of /use, preventing me to roll back/forward when
> something breaks during an upgrade.
> 
> What I could do instead is to put the information about which subvol to mount
> at /use into the initrd. But I actually think the way of passing this into
> initrd in the same way as the rootfs is more consistent and it also saves me
> from having a new initrd in /boot when libreoffice gets updated. That *might*
> be necessary when using secure boot, but only then.
> 
> Does this explain my motivation for this patch sufficiently?

Yes :) Sounds legit.

Lennart, approved from my side (didn't look at the code, though).


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Tobias Hunger]

On Oct 8, 2014 2:15 PM, "Harald Hoyer"  wrote:
> > What is the rationale of this patch?
> > Supporting systems without /etc/fstab in the root device?
> > Overriding the /etc/fstab settings?
> >
> > In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
> > reached, initrd-parse-etc.service is executed, which retriggers the
> > fstab-generator and reads fstab from the real root and generates units
for /usr.

Hello Harald,

The use case is exactly the one Lennart described in his blog about
deploying Linux in the future.

My setup now looks like this: I got a Btrfs partition for my Linux
installations. This partition has a subvol root:somename:someid:x86_64
containing a Linux installation minus /use.

Then I have several versions of /use for that distribution in more
subvolumes named usr:someid:x86_64:version (all with different versions,
basically getting incremented whenever a new set of packages gets
installed).

The idea is to now be able to write bootloader entries for all versions the
somename-installation.

For that the initrd needs to know which /usr to mount on top of the root
partition.

I can not use the fstab from the root drive here, because that would always
point to the same version of /use, preventing me to roll back/forward when
something breaks during an upgrade.

What I could do instead is to put the information about which subvol to
mount at /use into the initrd. But I actually think the way of passing this
into initrd in the same way as the rootfs is more consistent and it also
saves me from having a new initrd in /boot when libreoffice gets updated.
That *might* be necessary when using secure boot, but only then.

Does this explain my motivation for this patch sufficiently?

Best Regards,
Tobias
On 08.10.2014 14:13, Harald Hoyer wrote:
> On 24.09.2014 22:08, Tobias Hunger wrote:
>> From f3a193de94959875cd1d83f941ed8fc8275c82eb Mon Sep 17 00:00:00 2001
>> From: Tobias Hunger 
>> Date: Wed, 24 Sep 2014 21:57:00 +0200
>> Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on
>>  kernel command line
>>
>> This allows to configure boot loader entries for systems where the
>> root and usr filesystems are in different subvolumes (or even on
>> different drives).
>
> What is the rationale of this patch?
> Supporting systems without /etc/fstab in the root device?
> Overriding the /etc/fstab settings?
>
> In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is
> reached, initrd-parse-etc.service is executed, which retriggers the
> fstab-generator and reads fstab from the real root and generates units
for /usr.
>
>

doh.. didn't sent to mailing list... resent to list only.. sorry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel