Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf

[Andrei Borzenkov]

В Thu, 14 May 2015 21:23:38 +0200
Evert  пишет:

> Hi,
> 
> According to the systemd documentation, Requisite disallows starting a
> unit unless the specified unit has been started. This seems to work
> fine, however, if the specified unit has been restarted, this unit will
> be started too!
> This is not what should happen and it doesn't happen with a stop and
> start of the specified unit, so clearly, restart behaves different than
> stop followed by start.
> 
> This can easily be reproduced using 2 dummy service units:
> 
> 
> # dummy-1.service:
> [Unit]
> Description=dummy one
> DefaultDependencies=false
> After=local-fs.target
> Before=basic.target
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecReload=/bin/true
> ExecStop=/bin/true
> 
> [Install]
> WantedBy=sysinit.target multi-user.target
> Also=dummy-2.service
> 
> 
> # dummy-2.service
> [Unit]
> Description=dummy TWO
> DefaultDependencies=no
> After=dummy-1.service
> Before=shutdown.target
> Requisite=dummy-1.service
> 
> [Service]
> Type=oneshot
> RemainAfterExit=no
> ExecStart=/bin/true
> 
> [Install]
> WantedBy=shutdown.target
> 
> 
> # systemctl daemon-reload
> # systemctl enable dummy-1
> Created symlink from
> /etc/systemd/system/sysinit.target.wants/dummy-1.service to
> /etc/systemd/system/dummy-1.service.
> Created symlink from
> /etc/systemd/system/multi-user.target.wants/dummy-1.service to
> /etc/systemd/system/dummy-1.service.
> Created symlink from
> /etc/systemd/system/shutdown.target.wants/dummy-2.service to
> /etc/systemd/system/dummy-2.service.
> 
> In another window I follow the journal which output I pasted after the
> commands I execute:
> # journalctl -f |grep dummy
> 
> # systemctl start dummy-1
> mei 14 19:58:20 joker systemd[1]: Started dummy one.
> 
> # systemctl stop dummy-1
> mei 14 19:58:25 joker systemd[1]: Stopping dummy one...
> mei 14 19:58:25 joker systemd[1]: Stopped dummy one.
> 
> # systemctl start dummy-1
> mei 14 19:58:30 joker systemd[1]: Starting dummy one...
> mei 14 19:58:30 joker systemd[1]: Started dummy one.
> 
> # systemctl restart dummy-1
> mei 14 19:58:34 joker systemd[1]: Stopping dummy one...
> mei 14 19:58:34 joker systemd[1]: Starting dummy one...
> mei 14 19:58:34 joker systemd[1]: Started dummy one.
> mei 14 19:58:34 joker systemd[1]: Starting dummy TWO...
> mei 14 19:58:34 joker systemd[1]: Started dummy TWO.
> 
> # systemctl stop dummy-1
> mei 14 19:58:39 joker systemd[1]: Stopping dummy one...
> mei 14 19:58:39 joker systemd[1]: Stopped dummy one.
> 
> # systemctl restart dummy-1
> mei 14 19:58:43 joker systemd[1]: Starting dummy one...
> mei 14 19:58:43 joker systemd[1]: Started dummy one.
> mei 14 19:58:43 joker systemd[1]: Starting dummy TWO...
> mei 14 19:58:43 joker systemd[1]: Started dummy TWO.
> 
> As you can see, dummy-2 is not triggered by start or stop of dummy-1.
> However, it *is* triggered by restart of dummy-1 (no matter if dummy-1
> has been started or not). Am I missing something here or did I find a bug?
> 
> IMHO restart should be no different than "stop ; start" and it should
> certainly not trigger a unit which has a Requisite on that unit.


I do not see it on openSUSE 13.2 with (heavily patched) systemd-210 so
it appears to be a regression, unless there is some distro-specific
patch.

Reverse dependency for Requisite is Required-By and I have feeling it
had already been discussed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: introduce --now for enable, disable and mask

[Cam Hutchison]

jsyna...@redhat.com writes:

>diff --git a/man/systemctl.xml b/man/systemctl.xml
>index 4dbdfe1..951ce4d 100644
>--- a/man/systemctl.xml
>+++ b/man/systemctl.xml
>@@ -456,6 +456,17 @@
>   
> 
>   
>+--now
>+
>+
>+  When used with enable, the units
>+  will also be started. When used with disable
>+  or mask, the units will additionally be

Just a small nit: s/additionally/also/. You used the word "also" in the
previous sentence, and when I see different language being used in
different places in documentation, I wonder whether there is something
different about the cases.

>+  stopped.

Could you elaborate on ordering here? Is the unit first enabled then started,
and first stopped then disabled? Some other order? Indeterminate?

>+
>+  
>+
>+  
> --root=
> 
> 
>@@ -921,11 +932,12 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
>systemd-udevd.service
> the changes are taken into account immediately. Note that
> this does not have the effect of also
> starting any of the units being enabled. If this
>-is desired, a separate start command must
>-be invoked for the unit. Also note that in case of instance
>-enablement, symlinks named the same as instances are created in
>-the install location, however they all point to the same
>-template unit file.
>+is desired, either --now should be used
>+together with this command, or a separate start

Similar to my nit above - this uses "separate", the disable paragraph uses
"additional". (I realise this is pre-existing language, but while you're here
it can be fixed).

>+command must be invoked for the unit. Also note that in case of
>+instance enablement, symlinks named the same as instances
>+are created in the install location, however they all point to the
>+same template unit file.
> 
> This command will print the actions executed. This
> output may be suppressed by passing --quiet.
>@@ -980,9 +992,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
>systemd-udevd.service
> enable. This call implicitly reloads the
> systemd daemon configuration after completing the disabling
> of the units. Note that this command does not implicitly
>-stop the units that are being disabled. If this is desired,
>-an additional stop command should be
>-executed afterwards.
>+stop the units that are being disabled. If this is desired, either
>+--now should be used together with this command, 
>or
>+an additional stop command should be executed

"additional" used here. See previous comment.

>+afterwards.
> 
> This command will print the actions executed. This
> output may be suppressed by passing --quiet.
>@@ -1128,7 +1141,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
>systemd-udevd.service
> activation of the unit, including enablement and manual
> activation. Use this option with care. This honors the
> --runtime option to only mask temporarily
>-until the next reboot of the system.
>+until the next reboot of the system. The --now
>+can be additionally used to ensure that the units are also
>+stopped.

Drop the word "additionally" since there is an "also" later in the sentence
(and options by their nature are additional).

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

Re: [systemd-devel] Booting to systemd in a chroot

[Colin Walters]

On Thu, May 14, 2015, at 04:30 PM, JT Olds wrote:
>
>> Since you are reinstalling anyways, I'd suggest trying out btrfs
>> as your
>>
filesystem. Create separate subvolumes for each OS and you can
get rid of
>>
chrooting anything. Plus, you can share your home subvolume if you like.
>
> To be totally honest, I was trying this out mainly because we're
> evaluating how to do an inplace upgrade for a bunch of consumer
> devices we run that use Wheezy to Jessie. My laptop happened to be
> Wheezy so I took the plunge with our planned upgrade path.
>
> I work at Space Monkey and we have all these little NAS devices that
> are on Wheezy and we were dumb and didn't leave space for another full
> os-root partition anywhere.
>
> So repartitioning is off the table (we could brick users' devices with
> users power cycling due to being upset with waiting), but Wheezy ain't
> gonna last forever, and we'd love to get some Jessie systemd hotness.
> We're looking for a way to do a full system upgrade that can happen
> relatively atomically, and I think we might be on to something with
> pivot_root.

This is one of the use cases that https://live.gnome.org/Projects/OSTree
is designed for.

A recent thread is:
https://mail.gnome.org/archives/ostree-list/2015-May/msg00013.html

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

Re: [systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

[Lennart Poettering]

On Sat, 09.05.15 22:14, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

> Building with address sanitizer enabled on GCC 5.1.x a memory leak
> is reported because we never close the bus, fix it by using
> cleanup variable attribute.

Thanks! Applied!

> ---
>  src/libsystemd/sd-bus/test-bus-chat.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/libsystemd/sd-bus/test-bus-chat.c 
> b/src/libsystemd/sd-bus/test-bus-chat.c
> index 99261fa..1e50dfc 100644
> --- a/src/libsystemd/sd-bus/test-bus-chat.c
> +++ b/src/libsystemd/sd-bus/test-bus-chat.c
> @@ -262,7 +262,7 @@ fail:
>  
>  static void* client1(void*p) {
>  _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
> -sd_bus *bus = NULL;
> +_cleanup_bus_close_unref_ sd_bus *bus = NULL;
>  sd_bus_error error = SD_BUS_ERROR_NULL;
>  const char *hello;
>  int r;
> @@ -345,8 +345,6 @@ finish:
>  else
>  sd_bus_send(bus, q, NULL);
>  
> -sd_bus_flush(bus);
> -sd_bus_unref(bus);
>  }
>  
>  sd_bus_error_free(&error);
> -- 
> 2.3.7
> 
> ___
> 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] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Lennart Poettering]

On Thu, 07.05.15 04:37, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote:
> > On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> > 
> > > I still think that being able to define and start group of units 
> > > as one
> > > unit (pun unintended) is better in the long run.
> > > 
> > > This really far exceeds original scope of systemd-run which was
> > > "quickly start something under systemd supervision". When we have
> > > complex set of units with interdependency either systemd-run is the
> > > wrong tool for it or it should do it right, not paper over.
> > 
> > Hmm, you actually have a point, and we already *do* support queuing
> > groups of units, and that should suffice for this usecase, so that we
> > don't need to allow definiton of reverse deps.
> > 
> > This is actually already used for the time-based systemd-run stuff,
> > where we create both a transient timer and a transient service unit
> > and then start the timer unit.
> > 
> > Ivan, what you are trying to do hence should already work just fine 
> > in
> > the lower level apis, using the "auxiliary" list of units that the
> > StartTransientUnt() bus call takes. systemd-run doesn't generically
> > open this up yet though (and i dont know how it could do so nicely).
> 
> Yeah, auxiliary units could help here, though they suffer from the same
> kind of problem: either auxiliary units are read from message and
> created before the main one, or vice versa. The problems are the same
> as with two consecutive StartTransientUnit calls.

Hmm, if , I think this should be fixable though. Already, allocating a
unit, loading a unit and starting a unit are three separate steps. It
shouldn't be too hard to fix PID 1 to allow allocating all transient
units to create in a group first, then in a second step load all of
them, and finally start one of them. With such an order in place it
should be easily possible to do what you want to do, no?

Lennart

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

Re: [systemd-devel] Booting to systemd in a chroot

[JT Olds]

> Since you are reinstalling anyways, I'd suggest trying out btrfs as your
> filesystem. Create separate subvolumes for each OS and you can get rid of
> chrooting anything. Plus, you can share your home subvolume if you like.
>

To be totally honest, I was trying this out mainly because we're evaluating
how to do an inplace upgrade for a bunch of consumer devices we run that
use Wheezy to Jessie. My laptop happened to be Wheezy so I took the plunge
with our planned upgrade path.

I work at Space Monkey and we have all these little NAS devices that are on
Wheezy and we were dumb and didn't leave space for another full os-root
partition anywhere.

So repartitioning is off the table (we could brick users' devices with
users power cycling due to being upset with waiting), but Wheezy ain't
gonna last forever, and we'd love to get some Jessie systemd hotness. We're
looking for a way to do a full system upgrade that can happen relatively
atomically, and I think we might be on to something with pivot_root.


> The cool factor is, BTW, that you could deduplicate all your OS
> installations so file systems blocks become shared that are equal
> throughout
> the OS set, resulting in lower disk space usage.
>

Yeah that is pretty swanky. I might do that on my laptop after I'm done
figuring out what we're going to do for our consumer devices.

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

Re: [systemd-devel] systemd-socket-proxyd usage: remote's directly ping-/telnet-able, but via proxy "Network is unreachable"?

[Lennart Poettering]

On Thu, 14.05.15 10:02, PGNd (d...@pgnd.us) wrote:

> > The PrivateNetwork=yes will lock your service into its own virtual
> > network without any connectivity outside (it will contain only a
> > single loopback device). Drop this like and it should
> > work.
> 
> Yep, Thanks.
> 
> Inbound traffic via the staticIP now works exactly as intended -- mail is 
> received at/by the mailserver @ its LAN ip.
> 
> Outbound from the mailserver, however, does not send via the proxy link.
> 
> IIUC, the proxy link IS bi-directional.  But I suspect I've made an invalid 
> assumption about what that means and what gets set up.
> 
> It appears there's link doesn't listen TO the lan IP end -- so as to be able 
> to send/return traffic FROM the mailserver.
> 
> Do I need to additionally add the mirror systemd socket+service on
> the mailserver box (listemstream @ lanip, exec/forward to real IP @
> VPS)? Or is that best dealt with another change on the mailserver
> box -- route, vpn forward, NAT rule etc?

I really don't know how your system is set up and I am not sure this
would even be the right forum to discuss this.

Sorry, but I cannot help you on this I fear...

Lennart

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

Re: [systemd-devel] Booting to systemd in a chroot

[Kai Krakow]

JT Olds  schrieb:

> Thanks Lennart,
> 
> I tried pivot_root briefly last night after emailing but my initial
> attempt didn't work. Unfortunately I next tried switch_root, which, lol,
> wiped my root partition.
> 
> I'll try pivot_root when I get a working computer again.

Since you are reinstalling anyways, I'd suggest trying out btrfs as your 
filesystem. Create separate subvolumes for each OS and you can get rid of 
chrooting anything. Plus, you can share your home subvolume if you like.

Just take care that btrfs is still under fast development, so both OS should 
run a sufficiently recent kernel. At least I'd advice you to use the oldest 
kernel of the OS set to format btrfs, and not enable incompatible features 
later.

The cool factor is, BTW, that you could deduplicate all your OS 
installations so file systems blocks become shared that are equal throughout 
the OS set, resulting in lower disk space usage.

> Thanks again
> -JT
> 
> On Thu, May 14, 2015, 10:25 AM Lennart Poettering 
> wrote:
> 
>> On Thu, 14.05.15 06:12, JT Olds (jto...@xnet5.com) wrote:
>>
>> > Hey folks!
>> >
>> > I'm getting lots of systemd errors like
>> > `Failed at step NAMESPACE spawning /usr/lib/rtkit/rtkit-daemon: Invalid
>> > argument` and just wondering what I'm doing wrong.
>> >
>> > For background: I have a linux computer that's running Debian Wheezy. I
>> > want to install and dual boot Jessie, but without creating a new
>> partition,
>> > so I want to do it in a chroot (cause why not, I should be able to,
>> > right?).
>>
>> Sorry, but this simply cannot work: a chroot() is too weak, and
>> doesn't mix well with file system namespacing (which triggers the
>> errors you are seeing). Proper file system namespacing hides the fact
>> pretty well that things are namespaced, but chroot does
>> not. Especially if you then mix namespacing and chroot things become
>> ugly...
>>
>> Hence, please do not use chroot for what you are trying to do. Please
>> either use namespacing (i.e. mount --move) or privot_root() for this.
>>
>> > I ran `debootstrap jessie /jessie` and got a full Jessie
>> > installation in that subfolder (via tasksel and everything). I then
>> edited
>> > GRUB to have a menu option that boots linux like this:
>> >
>> > linux /jessie/vmlinuz root=UUID= rw init=/jessie/chrootinit
>> > initrd /jessie/initrd.img
>> >
>> > Last, I created chrootinit that wraps systemd:
>> >
>> > #!/bin/bash
>> > exec chroot /jessie /sbin/init "$@"
>>
>> This should work fine if you use pivot_root instead of chroot. Both
>> tools are part of util-linux.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>>
-- 
Replies to list only preferred.

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

Re: [systemd-devel] [PATCH 0/5] systemd-importd - support for pulling from V2 Dkr registries

[Vincent Batts]

On 11/05/15 11:15 -0400, Vincent Batts wrote:

On 11/05/15 17:07 +0200, Pavel Odvody wrote:

On Mon, 2015-05-11 at 10:32 -0400, Vincent Batts wrote:

On 09/05/15 00:31 +0200, Pavel Odvody wrote:

On Fri, 2015-05-08 at 14:33 -0400, Vincent Batts wrote:

On 08/05/15 11:31 +1000, Daurnimator wrote:
>On 8 May 2015 at 01:46, Pavel Odvody  wrote:
>>  - To access the V2 registry we need to send a special User-Agent
>>docker/1.6.0
>
>Is this really required?
>Can we request they change something server side?

I would have to double check the behavior on their docker hub, but for
local registries this user agent header is not required. It is the
expectation that a docker registry can always be served as a static file
tree (pull only).

vb


Hey,

$ curl -XGET https://registry-1.docker.io/v2/library/node/manifests/latest

404 Not Found
Not Found
The requested URL was not found on the server.  If you entered the URL manually 
please check your spelling and try again.

$ curl -XGET -H"User-Agent: docker/1.6.0" 
https://registry-1.docker.io/v2/library/node/manifests/latest
{"errors":[{"code":"UNAUTHORIZED","message":"access to the requested resource is not 
authorized","detail":[{"Type":"repository","Name":"library/node","Action":"pull"}]}]}

I actually added a little clarification in my 5th patch:

"User-Agent: do" /* otherwise we get load-balanced(!) to a V1 registyry */
(I got this information from Andy G.)

The second request obviously fails due to the bearer token not being provided,
but at least we can see that we're hitting the correct endpoint here.

I think that this is the correct behavior, since the original systemd-pull
workflow was to check the Hub first and obtain the token, which I'm simply
following here, however the token is now obtained from a separate endpoint.

The thing is that the argument is --dkr-index-url, so we're actually specifying
the Hub URL here and there's no way to specify a registry alone.
(the "mirror" registry is received in HTTP headers from the Hub)

Sounds like a topic for another patch?

I hope that the pull-only policy will be relaxed soon :) A lot of roundtrips ...


I understand they've done this on their hub, to route client versions
< 1.6.0 which can not do the v2 api. There ought to be a way not no
require UA headers. Will see what I can do.

vb


I find that solution rather unfortunate, since the endpoints are already
versioned /v1/ and /v2/ respectively.
The clients before 1.6.0 have hardcoded the /v1/ endpoints so really no
additional reason for this. (oh, didn't 1.5.0 ship half-assed
implementation of v2 with old header names?)


My same argument to them. The issue has been raised with them.


Cool. My raised issue was heard and acted on. Now the UA header is not
required on the hub either.

$ curl -XGET https://registry-1.docker.io/v2/library/node/manifests/latest
{"errors":[{"code":"UNAUTHORIZED","message":"access to the requested
resource is not 
authorized","detail":[{"Type":"repository","Name":"library/node","Action":"pull"}]}]}


vb


pgp976fDwuTnv.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf

[Evert]

Hi,

According to the systemd documentation, Requisite disallows starting a
unit unless the specified unit has been started. This seems to work
fine, however, if the specified unit has been restarted, this unit will
be started too!
This is not what should happen and it doesn't happen with a stop and
start of the specified unit, so clearly, restart behaves different than
stop followed by start.

This can easily be reproduced using 2 dummy service units:


# dummy-1.service:
[Unit]
Description=dummy one
DefaultDependencies=false
After=local-fs.target
Before=basic.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
ExecStop=/bin/true

[Install]
WantedBy=sysinit.target multi-user.target
Also=dummy-2.service


# dummy-2.service
[Unit]
Description=dummy TWO
DefaultDependencies=no
After=dummy-1.service
Before=shutdown.target
Requisite=dummy-1.service

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/bin/true

[Install]
WantedBy=shutdown.target


# systemctl daemon-reload
# systemctl enable dummy-1
Created symlink from
/etc/systemd/system/sysinit.target.wants/dummy-1.service to
/etc/systemd/system/dummy-1.service.
Created symlink from
/etc/systemd/system/multi-user.target.wants/dummy-1.service to
/etc/systemd/system/dummy-1.service.
Created symlink from
/etc/systemd/system/shutdown.target.wants/dummy-2.service to
/etc/systemd/system/dummy-2.service.

In another window I follow the journal which output I pasted after the
commands I execute:
# journalctl -f |grep dummy

# systemctl start dummy-1
mei 14 19:58:20 joker systemd[1]: Started dummy one.

# systemctl stop dummy-1
mei 14 19:58:25 joker systemd[1]: Stopping dummy one...
mei 14 19:58:25 joker systemd[1]: Stopped dummy one.

# systemctl start dummy-1
mei 14 19:58:30 joker systemd[1]: Starting dummy one...
mei 14 19:58:30 joker systemd[1]: Started dummy one.

# systemctl restart dummy-1
mei 14 19:58:34 joker systemd[1]: Stopping dummy one...
mei 14 19:58:34 joker systemd[1]: Starting dummy one...
mei 14 19:58:34 joker systemd[1]: Started dummy one.
mei 14 19:58:34 joker systemd[1]: Starting dummy TWO...
mei 14 19:58:34 joker systemd[1]: Started dummy TWO.

# systemctl stop dummy-1
mei 14 19:58:39 joker systemd[1]: Stopping dummy one...
mei 14 19:58:39 joker systemd[1]: Stopped dummy one.

# systemctl restart dummy-1
mei 14 19:58:43 joker systemd[1]: Starting dummy one...
mei 14 19:58:43 joker systemd[1]: Started dummy one.
mei 14 19:58:43 joker systemd[1]: Starting dummy TWO...
mei 14 19:58:43 joker systemd[1]: Started dummy TWO.

As you can see, dummy-2 is not triggered by start or stop of dummy-1.
However, it *is* triggered by restart of dummy-1 (no matter if dummy-1
has been started or not). Am I missing something here or did I find a bug?

IMHO restart should be no different than "stop ; start" and it should
certainly not trigger a unit which has a Requisite on that unit.

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

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Per Bergqvist]

Hej,

The kernel driver in /sys provide little useful information with current 
releases.

Even if the nvme driver is extended in future kernels as proposed by Keith 
Busch this will not solve 
the problem with kernels used today.

NVMe drives are being deployed now (in mass) and it will only increase rapidly 
due to the supreme performance.

I think the most important issue is to define a naming scheme in 
/dev/disk/by-id to ensure consistent 
naming and how to resolve this naming is secondary.

If the kernel can provide the more useful information in 4.2 it is great but we 
need a scheme that is possible 
to create with currently deployed kernels including 2.6.* kernels.

The scsi_id on arch 4.0.1-1 returns a ID_SERIAL of:
ID_SERIAL=SNVMe_INTEL_SSDPEDMD40CVFT504600EE400BGN
or 
ID_VENDOR=NVMe
ID_MODEL=INTEL_SSDPEDMD40
ID_SCSI_SERIAL=CVFT504600EE400BGN

on the same kind of system with SuSE 12 (3.12.28) system what you would get 
(different unit and serial):

ID_SERIAL=365cd2e4080864356494e0001
or
ID_VENDOR=NVMe
ID_MODEL=INTEL_SSDPEDMD40
ID_SCSI_SERIAL=CVFT4324006Z400BGN

A possible scheme to achieve with both is (assuming scsi_id being used):

/dev/disk/by-id/nvme-$ENV{ID_MODEL}_$ENV{ID_SCSI_SERIAL}

Distributions could then add necessary patches to achieve the same result as 
long as we know what 
we want to achieve.
If additional support is added in future kernel releases, systemd/udev can move 
away from use of scsi_id.

BR
Per

On 14 May 2015, at 19:07 , Keith Busch  wrote:

> Kay Sievers  vrfy.org> writes:
>> On Thu, May 14, 2015 at 6:12 PM, Lennart Poettering
>>  poettering.net> wrote:
>>> Well, nothing changed really: we'd like to remove scsi_id from
>>> systemd/udev upstream. Please ask sg_utils to pick it up
>>> instead. We'll continue to support the status quo for a while longer,
>>> but it can't stay this way, and we shouldn't add new features to
>>> it while it's in limbo.
>> 
>> Yeah, not sure how much NVMe has to do with SCSI. It might make more
>> sense to export the primary values to identify these devices by the
>> kernel driver in /sys, instead of excapsulating/emulating the SCSI
>> behavior. The kernel does that for other block device types like mmc
>> too.
> 
> I also like native nvme identification over scsi translation. Is the mmc
> way your preferred method for consuming these? If so, can you provide a
> pointer in that driver for what they're doing? I can probably get it in
> the nvme driver for 4.2.
> 
> Thanks,
> Keith
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Best Regards
Per Bergqvist

Managing Director
Bergqvist Software Technologies 

Mobile: + 352 691 686 600






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

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Keith Busch]

Kay Sievers  vrfy.org> writes:
> On Thu, May 14, 2015 at 6:12 PM, Lennart Poettering
>  poettering.net> wrote:
> > Well, nothing changed really: we'd like to remove scsi_id from
> > systemd/udev upstream. Please ask sg_utils to pick it up
> > instead. We'll continue to support the status quo for a while longer,
> > but it can't stay this way, and we shouldn't add new features to
> > it while it's in limbo.
> 
> Yeah, not sure how much NVMe has to do with SCSI. It might make more
> sense to export the primary values to identify these devices by the
> kernel driver in /sys, instead of excapsulating/emulating the SCSI
> behavior. The kernel does that for other block device types like mmc
> too.

I also like native nvme identification over scsi translation. Is the mmc
way your preferred method for consuming these? If so, can you provide a
pointer in that driver for what they're doing? I can probably get it in
the nvme driver for 4.2.

Thanks,
Keith

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

Re: [systemd-devel] systemd-socket-proxyd usage: remote's directly ping-/telnet-able, but via proxy "Network is unreachable"?

[PGNd]

> The PrivateNetwork=yes will lock your service into its own virtual
> network without any connectivity outside (it will contain only a
> single loopback device). Drop this like and it should
> work.

Yep, Thanks.

Inbound traffic via the staticIP now works exactly as intended -- mail is 
received at/by the mailserver @ its LAN ip.

Outbound from the mailserver, however, does not send via the proxy link.

IIUC, the proxy link IS bi-directional.  But I suspect I've made an invalid 
assumption about what that means and what gets set up.

It appears there's link doesn't listen TO the lan IP end -- so as to be able to 
send/return traffic FROM the mailserver.

Do I need to additionally add the mirror systemd socket+service on the 
mailserver box (listemstream @ lanip, exec/forward to real IP @ VPS)? Or is 
that best dealt with another change on the mailserver box -- route, vpn 
forward, NAT rule etc?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] preset activation on first boot takes too long

[Lennart Poettering]

On Thu, 14.05.15 17:13, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

> Heya,
> 
> I'm looking at bootcharts and it seems like first boot preset
> activation takes too much time...
> 
> So at the moment, we iterate all units, then iterate through presets
> until we find a match and act upon it.
> 
> However, most distros have "disable *" as their last setting, or don't
> use presets at all.
> 
> Furthermore looking at a fully featured system (e.g. my ubuntu laptop):
> * 158 files do not have install section
> * 89 have an install secion
> 
> Also it seems odd to have all of this in the pid one critical path ->
> e.g. these things are being parsed before anything happens.
> 
> Thus I wonder if the presets should be moved into e.g. a generator
> that will do the following on first boot only:

Hmm, generators so far were strictly something that would generate
output in the generator unit paths we pass to them, and nowhere
else. These directories would then be lifecycled by the daemon
runtime, and flushed on daemon reload. The generators would then be
invoked with new, empty generator unit directories on daemon reload.

The preset logic otoh creates persistent changes in /etc, that will
only and exlcusively be run if /etc is unpopulated. They logic is not
rerun on daemon reload, and nothing is ever flushed.

I am pretty sure this should stay that way. We shouldn't turn
generators into more than what they are right now. They should not
have persistent effect.

However, I am all open for optimizing the codepaths here. Maybe we can
cache the preset files in memory or so. And/or we could move the
preset code into its own binary, which we fork off explicitly before
running the generators, and then wait for after the generators (so
that the binary runs in parallel to the generators). Alternatively we
could even run it as thread from PID 1 in parallel to waiting for the
generators, as long as it shares zero state with the rest of PID
1. (That said, I am usually not too fond of threads, and especially
not in PID 1.)

> * parse .preset files
> * construct list of things to enable
> * enable all the units in that list

OK, so this would mean caching the preset file, and then doing pretty
much the same as before? I am fine with that. (But not as a generator,
as mentioned above)

> This should cut I/O and processing time at first boot by a bit, since
> only the units to be activated will be parsed.

Hmm? not following here. are you suggesting to use the preset file
list as base list of units to enable and then search for them in the
file system without ever enumerating unit files in the fs? This will
not really work, as the list contains glob expressions, and more
complicated ones than just "disable *". For examples things like
"enable avahi-daemon.*" which enables both the socket and the service
in one step. But it could also be "enable foo-*.service", for a
project "foo", that has many different services it wants to enable
with a single line... And crazy people could even use more complex
matches...

Hence, I am pretty sure the list of unit files enumerated from disk
needs to be used as basis, and then checked against the preset file,
not the other way round.

One thing you could use for optimizing: a TODO list item has been for
a while to change the first-boot preset logic to operate in a purely
additive way: don't bother with disabling any services then (in most
cases there will be nothing enabled at that time anyway), but only
operate on the "enable" cases. Doing this would allow you to avoid
loading the unit files for the "disable" lines, as you you don't care
for their [Install] section then. 

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] loginctl - multi-seats - lightdm - Xorg

[poma]

To conclude.

$ loginctl 
   SESSIONUID USER SEAT
 1   1000 poma 
c3105 lightdm  seat1 
c4105 lightdm  seat0   

3 sessions listed.

$ ps ax | grep [X]org
 1344 ?Sl 0:00 /usr/libexec/Xorg :0 -seat seat1 -sharevts -auth 
/var/run/lightdm/root/:0 -nolisten tcp
 1347 tty1 Ss+0:00 /usr/libexec/Xorg :1 -seat seat0 -auth 
/var/run/lightdm/root/:1 -nolisten tcp vt1 -novtswitch


$ grep -i LoadModule /var/log/Xorg.0.log
… (II) LoadModule: "glx"
… (II) LoadModule: "modesetting"  <--
… (II) LoadModule: "fbdev"
… (II) UnloadModule: "fbdev"
… (II) LoadModule: "vesa"
… (II) UnloadModule: "vesa"
… (II) LoadModule: "glamoregl"
… (II) LoadModule: "fb"

$ fbset -i -fb /dev/fb1 | grep Name
Name: udldrmfb


$ grep -i LoadModule /var/log/Xorg.1.log
… (II) LoadModule: "glx"
… (II) LoadModule: "nouveau"  <--
… (II) LoadModule: "nv"
… (II) UnloadModule: "nv"
… (II) LoadModule: "modesetting"
… (II) LoadModule: "fbdev"
… (II) UnloadModule: "fbdev"
… (II) LoadModule: "vesa"
… (II) UnloadModule: "vesa"
… (II) LoadModule: "dri2"
… (II) LoadModule: "fb"
… (II) LoadModule: "shadowfb"
… (II) UnloadModule: "modesetting"
… (II) LoadModule: "exa"
… (II) LoadModule: "evdev"

$ fbset -i | grep Name
Name: nouveaufb


# Xorg -version

X.Org X Server 1.17.1
Release Date: 2015-02-10
X Protocol Version 11, Revision 0
...
Build ID: xorg-x11-server 1.17.1-12.fc21 

~

All in all, 
in X.Org X Server 1.17.1 modules are automatically induced in multi-seat 
environment,
therefore additional configuration files for Xorg X server are no longer 
necessary,
and overall *minimum* lightdm's config is:
~

$ lightdm --show-config
   [LightDM]
A  minimum-vt=1

   [SeatDefaults]
A  session-wrapper=/etc/X11/xinit/Xsession


Sources:
A  /etc/lightdm/lightdm.conf



$ lightdm --version
lightdm 1.14.0


That's super cool, isn't it.


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

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Kay Sievers]

On Thu, May 14, 2015 at 6:12 PM, Lennart Poettering
 wrote:
> On Thu, 14.05.15 09:10, Per Bergqvist (p...@bst.lu) wrote:
>
>> There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer 
>> which was
>> sort of rejected by Kay Sievers by referring to “we should find out what to 
>> do for nvme before
>> adding new users of scsi_id”.
>
> Well, nothing changed really: we'd like to remove scsi_id from
> systemd/udev upstream. Please ask sg_utils to pick it up
> instead. We'll continue to support the status quo for a while longer,
> but it can't stay this way, and we shouldn't add new features to
> it while it's in limbo.

Yeah, not sure how much NVMe has to do with SCSI. It might make more
sense to export the primary values to identify these devices by the
kernel driver in /sys, instead of excapsulating/emulating the SCSI
behavior. The kernel does that for other block device types like mmc
too.

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

Re: [systemd-devel] Booting to systemd in a chroot

[JT Olds]

Thanks Lennart,

I tried pivot_root briefly last night after emailing but my initial attempt
didn't work. Unfortunately I next tried switch_root, which, lol, wiped my
root partition.

I'll try pivot_root when I get a working computer again.

Thanks again
-JT

On Thu, May 14, 2015, 10:25 AM Lennart Poettering 
wrote:

> On Thu, 14.05.15 06:12, JT Olds (jto...@xnet5.com) wrote:
>
> > Hey folks!
> >
> > I'm getting lots of systemd errors like
> > `Failed at step NAMESPACE spawning /usr/lib/rtkit/rtkit-daemon: Invalid
> > argument` and just wondering what I'm doing wrong.
> >
> > For background: I have a linux computer that's running Debian Wheezy. I
> > want to install and dual boot Jessie, but without creating a new
> partition,
> > so I want to do it in a chroot (cause why not, I should be able to,
> > right?).
>
> Sorry, but this simply cannot work: a chroot() is too weak, and
> doesn't mix well with file system namespacing (which triggers the
> errors you are seeing). Proper file system namespacing hides the fact
> pretty well that things are namespaced, but chroot does
> not. Especially if you then mix namespacing and chroot things become
> ugly...
>
> Hence, please do not use chroot for what you are trying to do. Please
> either use namespacing (i.e. mount --move) or privot_root() for this.
>
> > I ran `debootstrap jessie /jessie` and got a full Jessie
> > installation in that subfolder (via tasksel and everything). I then
> edited
> > GRUB to have a menu option that boots linux like this:
> >
> > linux /jessie/vmlinuz root=UUID= rw init=/jessie/chrootinit
> > initrd /jessie/initrd.img
> >
> > Last, I created chrootinit that wraps systemd:
> >
> > #!/bin/bash
> > exec chroot /jessie /sbin/init "$@"
>
> This should work fine if you use pivot_root instead of chroot. Both
> tools are part of util-linux.
>
> 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-socket-proxyd usage: remote's directly ping-/telnet-able, but via proxy "Network is unreachable"?

[Lennart Poettering]

On Wed, 13.05.15 21:53, PGNd (d...@pgnd.us) wrote:

> 
>   [Service]
>   ExecStart=/usr/lib/systemd/systemd-socket-proxyd 10.2.2.12:25
>   PrivateTmp=yes
>   PrivateNetwork=yes

The PrivateNetwork=yes will lock your service into its own virtual
network without any connectivity outside (it will contain only a
single loopback device). Drop this like and it should
work.

Lennart

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

Re: [systemd-devel] Booting to systemd in a chroot

[Lennart Poettering]

On Thu, 14.05.15 06:12, JT Olds (jto...@xnet5.com) wrote:

> Hey folks!
> 
> I'm getting lots of systemd errors like
> `Failed at step NAMESPACE spawning /usr/lib/rtkit/rtkit-daemon: Invalid
> argument` and just wondering what I'm doing wrong.
> 
> For background: I have a linux computer that's running Debian Wheezy. I
> want to install and dual boot Jessie, but without creating a new partition,
> so I want to do it in a chroot (cause why not, I should be able to,
> right?). 

Sorry, but this simply cannot work: a chroot() is too weak, and
doesn't mix well with file system namespacing (which triggers the
errors you are seeing). Proper file system namespacing hides the fact
pretty well that things are namespaced, but chroot does
not. Especially if you then mix namespacing and chroot things become
ugly...

Hence, please do not use chroot for what you are trying to do. Please
either use namespacing (i.e. mount --move) or privot_root() for this.

> I ran `debootstrap jessie /jessie` and got a full Jessie
> installation in that subfolder (via tasksel and everything). I then edited
> GRUB to have a menu option that boots linux like this:
> 
> linux /jessie/vmlinuz root=UUID= rw init=/jessie/chrootinit
> initrd /jessie/initrd.img
> 
> Last, I created chrootinit that wraps systemd:
> 
> #!/bin/bash
> exec chroot /jessie /sbin/init "$@"

This should work fine if you use pivot_root instead of chroot. Both
tools are part of util-linux.

Lennart

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

[systemd-devel] preset activation on first boot takes too long

[Dimitri John Ledkov]

Heya,

I'm looking at bootcharts and it seems like first boot preset
activation takes too much time...

So at the moment, we iterate all units, then iterate through presets
until we find a match and act upon it.

However, most distros have "disable *" as their last setting, or don't
use presets at all.

Furthermore looking at a fully featured system (e.g. my ubuntu laptop):
* 158 files do not have install section
* 89 have an install secion

Also it seems odd to have all of this in the pid one critical path ->
e.g. these things are being parsed before anything happens.

Thus I wonder if the presets should be moved into e.g. a generator
that will do the following on first boot only:

* parse .preset files
* construct list of things to enable
* enable all the units in that list

This should cut I/O and processing time at first boot by a bit, since
only the units to be activated will be parsed.

That also kind of means that it will only work if the last fallback
policy is "disable *".

For a reference, preset enabling on first boot accounts for around
6.5% of the first boot time for me on fairly minimal containers / base
VMs.

What do you think about this?

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
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] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Lennart Poettering]

On Thu, 14.05.15 09:10, Per Bergqvist (p...@bst.lu) wrote:

> Hej,
> 
> There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer 
> which was 
> sort of rejected by Kay Sievers by referring to “we should find out what to 
> do for nvme before
> adding new users of scsi_id”.

Well, nothing changed really: we'd like to remove scsi_id from
systemd/udev upstream. Please ask sg_utils to pick it up
instead. We'll continue to support the status quo for a while longer,
but it can't stay this way, and we shouldn't add new features to
it while it's in limbo.

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] dev-root.device is not active, results in an umount spree

[Lennart Poettering]

On Thu, 14.05.15 12:51, Martin Pitt (martin.p...@ubuntu.com) wrote:

> > This is very bad. As a harmless action like following:
> > 
> > # mount --bind /opt /opt
> > 
> > Results in opt.mount unit to be generated which BindsTo
> > dev-root.device, which is inactive, thus systemd tries to stop that
> > unit straight away, and umount fails and is retried infinitely...
> > effectively DoSing init.
> 
> As I mentioned before, simply ignoring /dev/root doesn't help in all
> cases, and hardcoding it in the code is a bit ugly.

It doesn't help in all cases? Which ones? Can you elaborate?

And why is this ugly?

/dev/root is special in the kernel. No sysfs device by that name ever
exists, it's pretty much a fixed string the kernel inserts into the
mount table for the root device specified on the kernel cmdline. It
never exists otherwise and hence it is the right logic to check for it
explicitly and ignore it explicitly. It gets particularly confusing
for btrfs file systems, since those are device-less file systems
nominally, but when you use them as root fs without inird, they
suddenly appear as device backed fs this way...

> The attached patch is a more general solution which stops creating
> dead stub .device units for devices which don't exist at all. I. e.
> while in your case -.mount was probably BindsTo=dev-root.device (or in
> my case, in my container I had mnt.mount BindsTo=dev-sda3.device,
> which exists on the host but not in the container), but with this
> patch it should now not be bound to anything.

The patch is not right, Because it will not load device units for
devices that have not been referenced yet. This would break things for
mount entries that carry no deps on their own, but only reference a
source device.

> Lennart, if you don't like this there is an alternative, and more
> complicated solution: We could instead teach device_found_node() to
> actually do create a proper .device with the passed DeviceFound (which
> is "MOUNT"), resulting in creating a state "tentative" device. I have
> a half-working patch for this, but it's brittle as with pretty much
> any uevent or moutinfo change the status changes back to "dead",
> causing the unmount attempt. IMHO this approach isn't conceptually
> correct either -- in such containers, if don't have the corresponding
> device nodes at all, we shouldn't try to react to hotplug events and
> clean up mounts. I. e. the "tentative" concept does not really apply
> there. But I have misunderstood the intent.

Hmm, not following I must admit.

Note though that for containers we do not longer create any device
dependencies anyway, see 47bc12e1ba35d38.

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] systemctl: introduce --now for enable, disable and mask

[Lennart Poettering]

On Thu, 14.05.15 14:26, jsyna...@redhat.com (jsyna...@redhat.com) wrote:

>  const char *unit_file_preset_mode_to_string(UnitFilePresetMode m) _const_;
>  UnitFilePresetMode unit_file_preset_mode_from_string(const char *s) _pure_;
> +
> +
> +int add_file_change(UnitFileChange **changes, unsigned *n_changes,
>  UnitFileChangeType type, const char *path, const char *source);

No double newlines please.

More importantly though, if you export this function it should really
carry some useful namespace prefix, and not begin with the verb. 

Given that we already have unit_file_changes_free() as public call, it
should probably be called unit_file_changes_add() and be placed next
to it in the header and .c file.

Having good names for static, internal calls is not as important as
for non-static, exported ones, hence the need for the rename.

> +if (arg_now && n_changes > 0 && STR_IN_SET(args[0], "enable", 
> "disable", "mask")) {
> +_cleanup_strv_free_ char **new_args = NULL;
> +unsigned i;
> +
> +r = strv_push(&new_args, streq(args[0], "enable") ? 
> strdup("start") : strdup("stop"));
> +if (r < 0)
> +goto finish;

This will crash on OOM.

strv_extend() internally does strdup() + strv_push() and checks for
OOM, hence that sounds like the better option.

That said, both strv_extend() and strv_push() internally reallocate
the string array. That's fine for small arrays, or when you don't know
how many entries to expect, but in this case you really do know, you
get it passed back in n_changes after all. Hence, please make use of
this, allocate a temporary array (maybe with newa()) then add the
entries to it, use and forget it.

> +
> +for (i = 0; i < n_changes; i++) {
> +r = strv_push(&new_args,
> strdup(strrchr(changes[i].path, '/') + 1));

The strrchr appears to be something where useing basename() is the
better 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] [PATCH v2] fstab-generator: add x-systemd.requires and x-systemd.requires-mounts-for

[Lennart Poettering]

On Thu, 14.05.15 13:27, Karel Zak (k...@redhat.com) wrote:

> +r = fstab_filter_options(opts, "x-systemd.requires\0", NULL, &arg, 
> NULL);
> +if (r < 0)
> +return log_warning_errno(r, "Failed to parse options: %m");
> +if (r == 0)
> +return 0;
> +
> +if (*arg == '/') {
> +r = unit_name_mangle_with_suffix(arg, UNIT_NAME_NOGLOB, 
> ".mount", &unit);
> +if (r < 0)
> +return log_error_errno(r, "Failed to generate unit 
> name: %m");
> +} else
> +unit = arg;

No need to explicitly check *arg for '/', just invoke
unit_name_mangle_with_suffix() immediately, without condition, as it
internally does pretty much the same check anyway. i.e. remove the if
check, remove the second branch, just invoke the function immediatey
and unconditionally, it will already do the right thing...

> +fprintf(f, "After=%1$s\nRequires=%1$s\n", unit);
> +
> +if (unit == arg)
> +unit = NULL;
> +
> +return 0;
> +}
> +
> +#define REQUIRES_MOUNTS_OPT"x-systemd.requires-mounts-for="

I'd just use the literal string everywhere. We only use this in this
one file and the macro isn't really that much shorter than the real
string, there's really no need to define a macro for this... 

> +
> +static int write_requires_mounts_for(FILE *f, const char *opts) {
> +_cleanup_free_ char **optsv = NULL, **paths = NULL, *res = NULL;
> +char **s;
> +
> +assert(f);
> +assert(opts);
> +
> +optsv = strv_split(opts, ",");
> +if (!optsv)
> +return log_oom();
> +
> +STRV_FOREACH(s, optsv) {
> +char *arg;
> +
> +if (!startswith(*s, REQUIRES_MOUNTS_OPT))
> +continue;
> +arg = *s + strlen(REQUIRES_MOUNTS_OPT);
> +if (!*arg)
> +return log_warning("Failed to parse option " 
> REQUIRES_MOUNTS_OPT);
> +if (!paths)
> +paths = strv_new(arg, NULL);
> +else
> +strv_push(&paths, arg);
> +}

I figure this logic should really be made generic and added to
fstab-util.c 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] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Keith Busch]

On Thu, 14 May 2015, Dimitri John Ledkov wrote:

On 14 May 2015 at 08:10, Per Bergqvist  wrote:

+# NVMe
+KERNEL=="nvme*", ENV{ID_SCSI_SERIAL}!="?*", IMPORT{program}="scsi_id
--export --whitelisted -d $devnode"
+KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*",
SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}"
+KERNEL=="nvme*", ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*",
SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}-part%n"
+



This looks odd to me, from NVMe perspective. I would have thought the
stable names would be generated based on the NVMe Namespace UIDs
rather than anything else.

Keith - could you comment on above ^ ?


Hi,

It depends on the nvme controller revision. 1.1 compatible and higher
namespaces export a unique id in EUI64 format. 1.0 devices don't have
this; the serial is as unique as it gets but will create collisions
if the device exports multiple namespaces so we have to append the
namespace identifier.

In either case, the driver provides a scsi translation to obtain
persistent and consistent unique identifiers using inquiry vpd 83h
so I think you want to use ID_SERIAL instead, but it appears scsi_id
doesn't use our vpd 83 with the SCSI string designator type used for
1.0 devices. Do I need to change this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: introduce --now for enable, disable and mask

[systemd github import bot]

Patchset imported to github.
Pull request:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: introduce --now for enable, disable and mask

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 14, 2015 at 02:26:34PM +0200, jsyna...@redhat.com wrote:
> From: Jan Synacek 
> 
> ---
>  Makefile.am  |  1 +
>  man/systemctl.xml| 33 -
>  src/libsystemd/sd-bus/bus-util.c |  6 +-
>  src/libsystemd/sd-bus/bus-util.h |  3 ++-
>  src/machine/machinectl.c |  2 +-
>  src/shared/install.c |  2 +-
>  src/shared/install.h |  3 +++
>  src/systemctl/systemctl.c| 33 +
>  8 files changed, 66 insertions(+), 17 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index e8a329f..861f3b2 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5351,6 +5351,7 @@ machinectl_LDADD = \
>   libsystemd-internal.la \
>   libsystemd-logs.la \
>   libsystemd-journal-internal.la \
> + libsystemd-units.la \
>   libsystemd-shared.la
>  
>  rootbin_PROGRAMS += \
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 4dbdfe1..951ce4d 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -456,6 +456,17 @@
>
>  
>
> +--now
> +
> +
> +  When used with enable, the units
> +  will also be started. When used with disable
> +  or mask, the units will additionally be
> +  stopped.
> +
> +  
> +
> +  
>  --root=
>  
>  
> @@ -921,11 +932,12 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>  the changes are taken into account immediately. Note that
>  this does not have the effect of also
>  starting any of the units being enabled. If this
> -is desired, a separate start command must
> -be invoked for the unit. Also note that in case of instance
> -enablement, symlinks named the same as instances are created in
> -the install location, however they all point to the same
> -template unit file.
> +is desired, either --now should be used
> +together with this command, or a separate 
> start
> +command must be invoked for the unit. Also note that in case of
> +instance enablement, symlinks named the same as instances
> +are created in the install location, however they all point to 
> the
> +same template unit file.
>  
>  This command will print the actions executed. This
>  output may be suppressed by passing --quiet.
> @@ -980,9 +992,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>  enable. This call implicitly reloads the
>  systemd daemon configuration after completing the disabling
>  of the units. Note that this command does not implicitly
> -stop the units that are being disabled. If this is desired,
> -an additional stop command should be
> -executed afterwards.
> +stop the units that are being disabled. If this is desired, 
> either
> +--now should be used together with this 
> command, or
> +an additional stop command should be executed
> +afterwards.
>  
>  This command will print the actions executed. This
>  output may be suppressed by passing --quiet.
> @@ -1128,7 +1141,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>  activation of the unit, including enablement and manual
>  activation. Use this option with care. This honors the
>  --runtime option to only mask temporarily
> -until the next reboot of the system.
> +until the next reboot of the system. The --now
> +can be additionally used to ensure that the units are also
> +stopped.
>
>  
>  
> diff --git a/src/libsystemd/sd-bus/bus-util.c 
> b/src/libsystemd/sd-bus/bus-util.c
> index 7536a96..fe7eb43 100644
> --- a/src/libsystemd/sd-bus/bus-util.c
> +++ b/src/libsystemd/sd-bus/bus-util.c
> @@ -1899,7 +1899,7 @@ int bus_wait_for_jobs_one(BusWaitForJobs *d, const char 
> *path, bool quiet) {
>  return bus_wait_for_jobs(d, quiet);
>  }
>  
> -int bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool 
> quiet) {
> +int bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool 
> quiet, UnitFileChange **changes, unsigned *n_changes) {
>  const char *type, *path, *source;
>  int r;
>  
> @@ -1914,6 +1914,10 @@ int 
> bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool quiet) {
>  else
>  log_info("Removed symlink %s.", path);
>  }
> +
> +r = add_file_change(changes, n_changes, streq(type, 
> "symlink") ? UNIT_FILE_SYMLINK : UNIT_FILE_UNLINK, path, source);
> +if (r < 0)
> +return r;
>  }
>  

Re: [systemd-devel] [PATCH] core: Fix assertion with empty Exec*= paths

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 14, 2015 at 09:15:10AM +0200, Martin Pitt wrote:
> From 10f6ac7c8b3dad0197ce795e33383c24ea2d53b1 Mon Sep 17 00:00:00 2001
> From: Martin Pitt 
> Date: Thu, 14 May 2015 09:06:40 +0200
> Subject: [PATCH] core: Fix assertion with empty Exec*= paths
> 
> An Exec*= line with whitespace after modifiers, like
> 
>   ExecStart=- /bin/true
> 
> is considered to have an empty command path. This is as specified, but causes
> systemd to crash with
> 
>   Assertion 'skip < l' failed at ../src/core/load-fragment.c:607, function 
> config_parse_exec(). Aborting.
>   Aborted (core dumped)
> 
> Fix this by logging an error instead and ignoring the invalid line.
> 
> Add corresponding test cases. Also add a test case for a completely empty 
> value
> which resets the command list.
> 
> https://launchpad.net/bugs/1454173
> ---
>  src/core/load-fragment.c  |  6 +-
>  src/test/test-unit-file.c | 21 +
>  2 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
> index 33d9e27..3865017 100644
> --- a/src/core/load-fragment.c
> +++ b/src/core/load-fragment.c
> @@ -595,7 +595,11 @@ int config_parse_exec(
>  skip = separate_argv0 + ignore;
>  
>  /* skip special chars in the beginning */
> -assert(skip < l);
> +if (l <= skip) {
> +log_syntax(unit, LOG_ERR, filename, 
> line, EINVAL, "Empty path in command line, ignoring: %s", rvalue);
> +r = 0;
> +goto fail;
> +}
>  
>  } else if (strneq(word, ";", MAX(l, 1U)))
>  /* new commandline */
Looks OK, but it'd be nice to add quotes because of spaces: ...\"%s\"...

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

[systemd-devel] [PATCH] systemctl: introduce --now for enable, disable and mask

[jsynacek]

From: Jan Synacek 

---
 Makefile.am  |  1 +
 man/systemctl.xml| 33 -
 src/libsystemd/sd-bus/bus-util.c |  6 +-
 src/libsystemd/sd-bus/bus-util.h |  3 ++-
 src/machine/machinectl.c |  2 +-
 src/shared/install.c |  2 +-
 src/shared/install.h |  3 +++
 src/systemctl/systemctl.c| 33 +
 8 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e8a329f..861f3b2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5351,6 +5351,7 @@ machinectl_LDADD = \
libsystemd-internal.la \
libsystemd-logs.la \
libsystemd-journal-internal.la \
+   libsystemd-units.la \
libsystemd-shared.la
 
 rootbin_PROGRAMS += \
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 4dbdfe1..951ce4d 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -456,6 +456,17 @@
   
 
   
+--now
+
+
+  When used with enable, the units
+  will also be started. When used with disable
+  or mask, the units will additionally be
+  stopped.
+
+  
+
+  
 --root=
 
 
@@ -921,11 +932,12 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 the changes are taken into account immediately. Note that
 this does not have the effect of also
 starting any of the units being enabled. If this
-is desired, a separate start command must
-be invoked for the unit. Also note that in case of instance
-enablement, symlinks named the same as instances are created in
-the install location, however they all point to the same
-template unit file.
+is desired, either --now should be used
+together with this command, or a separate start
+command must be invoked for the unit. Also note that in case of
+instance enablement, symlinks named the same as instances
+are created in the install location, however they all point to the
+same template unit file.
 
 This command will print the actions executed. This
 output may be suppressed by passing --quiet.
@@ -980,9 +992,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 enable. This call implicitly reloads the
 systemd daemon configuration after completing the disabling
 of the units. Note that this command does not implicitly
-stop the units that are being disabled. If this is desired,
-an additional stop command should be
-executed afterwards.
+stop the units that are being disabled. If this is desired, either
+--now should be used together with this command, 
or
+an additional stop command should be executed
+afterwards.
 
 This command will print the actions executed. This
 output may be suppressed by passing --quiet.
@@ -1128,7 +1141,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 activation of the unit, including enablement and manual
 activation. Use this option with care. This honors the
 --runtime option to only mask temporarily
-until the next reboot of the system.
+until the next reboot of the system. The --now
+can be additionally used to ensure that the units are also
+stopped.
   
 
 
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index 7536a96..fe7eb43 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1899,7 +1899,7 @@ int bus_wait_for_jobs_one(BusWaitForJobs *d, const char 
*path, bool quiet) {
 return bus_wait_for_jobs(d, quiet);
 }
 
-int bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool quiet) {
+int bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool quiet, 
UnitFileChange **changes, unsigned *n_changes) {
 const char *type, *path, *source;
 int r;
 
@@ -1914,6 +1914,10 @@ int 
bus_deserialize_and_dump_unit_file_changes(sd_bus_message *m, bool quiet) {
 else
 log_info("Removed symlink %s.", path);
 }
+
+r = add_file_change(changes, n_changes, streq(type, "symlink") 
? UNIT_FILE_SYMLINK : UNIT_FILE_UNLINK, path, source);
+if (r < 0)
+return r;
 }
 if (r < 0)
 return bus_log_parse_error(r);
diff --git a/src/libsystemd/sd-bus/bus-util.h b/src/libsystemd/sd-bus/bus-util.h
index 093b48b..999a372 100644
--- a/src/libsystemd/sd-bus/bus-util.h
+++ b/src/libsystemd/sd-bus/bus-util.h
@@ -24,6 +24,7 @@
 #include "sd-event.h"
 #include "sd-bus.h"
 #

Re: [systemd-devel] [PATCH v2] fstab-generator: add x-systemd.requires and x-systemd.requires-mounts-for

[systemd github import bot]

Patchset imported to github.
Pull request:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] fstab-generator: add x-systemd.requires and x-systemd.requires-mounts-for

[Karel Zak]

On Thu, May 14, 2015 at 01:27:40PM +0200, Karel Zak wrote:
> +static int write_requires_mounts_for(FILE *f, const char *opts) {
> +_cleanup_free_ char **optsv = NULL, **paths = NULL, *res = NULL;

 _cleanup_strv_free_ **optsv = NULL, **paths = NULL;

 Do I need to resend the patch? ;-)

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v2] fstab-generator: add x-systemd.requires and x-systemd.requires-mounts-for

[Karel Zak]

Currently we have no way how to specify dependencies between fstab
entries (or another units) in the /etc/fstab. It means that users are
forced to bypass fstab and write .mount units manually.

The patch introduces new systemd fstab options:

x-systemd.requires=

 - to specify dependence an another mount (PATH is translated to unit name)

x-systemd.requires=

 - to specify dependence on arbitrary UNIT

x-systemd.requires-mounts-for=

 - to specify dependence on another paths, implemented by
   RequiresMountsFor=. The option may be specified more than once.

For example two bind mounts where B depends on A:

 /mnt/test/A/mnt/test/A nonebind,defaults
 /mnt/test/A/mnt/test/B nonebind,x-systemd.requires=/mnt/test/A

More complex example with overlay FS where one mount point depends on
"low" and "upper" directories:

 /dev/sdc1   /mnt/lowext4 defaults
 /dev/sdc2   /mnt/high   ext4 defaults
 overlay /mnt/merged overlay  
lowerdir=/mnt/low,upperdir=/mnt/high/data,workdir=/mnt/high/work,x-systemd.requires-mounts-for=/mnt/low,x-systemd.requires-mounts-for=mnt/high

References: https://bugzilla.redhat.com/show_bug.cgi?id=812826
---

v2:
 - rename x-systemd.after to x-systemd.requires
 - allow to specify x-systemd.requires-mounts-for= more than once
 - propagate errors
 - fix some typos

 man/systemd.mount.xml | 20 +
 src/fstab-generator/fstab-generator.c | 83 +++
 2 files changed, 103 insertions(+)

diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml
index 862f42e..58ad6a6 100644
--- a/man/systemd.mount.xml
+++ b/man/systemd.mount.xml
@@ -139,6 +139,26 @@
 
 
   
+x-systemd.requires=
+
+Configures After= and 
Requires= dependency
+between the mount and another mount or systemd unit. The argument is 
absolute path to
+another mount point or unit name. See After= and 
Requires= in
+
systemd.unit5
+for details.
+  
+
+  
+x-systemd.requires-mounts-for=
+
+Configures RequiresMountsFor= 
dependency between the mount and
+another mount. The argument must be absolute path. This option may be 
specified more than once.
+See RequiresMountsFor= in
+
systemd.unit5
+for details.
+   
+
+  
 x-systemd.automount
 
 An automount unit will be created for the file
diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index 167ec60..29517e7 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -177,6 +177,71 @@ static int write_idle_timeout(FILE *f, const char *where, 
const char *opts) {
 return 0;
 }
 
+static int write_requires_after(FILE *f, const char *opts) {
+_cleanup_free_ char *arg = NULL, *unit = NULL;
+int r;
+
+assert(f);
+assert(opts);
+
+r = fstab_filter_options(opts, "x-systemd.requires\0", NULL, &arg, 
NULL);
+if (r < 0)
+return log_warning_errno(r, "Failed to parse options: %m");
+if (r == 0)
+return 0;
+
+if (*arg == '/') {
+r = unit_name_mangle_with_suffix(arg, UNIT_NAME_NOGLOB, 
".mount", &unit);
+if (r < 0)
+return log_error_errno(r, "Failed to generate unit 
name: %m");
+} else
+unit = arg;
+
+fprintf(f, "After=%1$s\nRequires=%1$s\n", unit);
+
+if (unit == arg)
+unit = NULL;
+
+return 0;
+}
+
+#define REQUIRES_MOUNTS_OPT"x-systemd.requires-mounts-for="
+
+static int write_requires_mounts_for(FILE *f, const char *opts) {
+_cleanup_free_ char **optsv = NULL, **paths = NULL, *res = NULL;
+char **s;
+
+assert(f);
+assert(opts);
+
+optsv = strv_split(opts, ",");
+if (!optsv)
+return log_oom();
+
+STRV_FOREACH(s, optsv) {
+char *arg;
+
+if (!startswith(*s, REQUIRES_MOUNTS_OPT))
+continue;
+arg = *s + strlen(REQUIRES_MOUNTS_OPT);
+if (!*arg)
+return log_warning("Failed to parse option " 
REQUIRES_MOUNTS_OPT);
+if (!paths)
+paths = strv_new(arg, NULL);
+else
+strv_push(&paths, arg);
+}
+
+if (paths) {
+res = strv_join(paths, " ");
+if (!res)
+return log_oom();
+fprintf(f, "RequiresMountsFor=%s\n", res);
+}
+
+return 0;
+}
+
 static int add_mount(
 const char *what,
 const char *where,
@@ -251,6 +316,15 @@ static int add_mount(
 if (post && !noauto && !nofail && !automount)
 fprintf(f, "Before=%s\n", post);
 
+if (!automount && opts) {
+ r

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

[Andrei Borzenkov]

В Thu, 14 May 2015 12:51:37 +0200
Martin Pitt  пишет:

> Hello all,
> 
> Dimitri John Ledkov [2015-05-13 12:48 +0100]:
> > I am booting without initramfs, using a plan9 filesystem as rootfs in a kvm.
> > 
> > Thus my /proc/cmdline has:
> > root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p
> > 
> > # mount
> > /dev/root on / type 9p
> > (rw,relatime,sync,dirsync,rw,trans=virtio,version=9p2000.L)
> > 
> > Yet, dev-root.device is dead:
> > # systemctl status dev-root.device
> > ● dev-root.device
> >Loaded: loaded
> >Active: inactive (dead)
> > 
> > This is very bad. As a harmless action like following:
> > 
> > # mount --bind /opt /opt
> > 
> > Results in opt.mount unit to be generated which BindsTo
> > dev-root.device, which is inactive, thus systemd tries to stop that
> > unit straight away, and umount fails and is retried infinitely...
> > effectively DoSing init.
> 
> As I mentioned before, simply ignoring /dev/root doesn't help in all
> cases, and hardcoding it in the code is a bit ugly.
> 
> The attached patch is a more general solution which stops creating
> dead stub .device units for devices which don't exist at all. I. e.
> while in your case -.mount was probably BindsTo=dev-root.device (or in
> my case, in my container I had mnt.mount BindsTo=dev-sda3.device,
> which exists on the host but not in the container), but with this
> patch it should now not be bound to anything.
> 

Will it be "rebound" when device appears? Otherwise any mount that
happens before udev is started/happens to notice device will not be
associated with device. Most common case is probably mounts inherited
from initrd.

> Lennart, if you don't like this there is an alternative, and more
> complicated solution: We could instead teach device_found_node() to
> actually do create a proper .device with the passed DeviceFound (which
> is "MOUNT"), resulting in creating a state "tentative" device. I have
> a half-working patch for this, but it's brittle as with pretty much
> any uevent or moutinfo change the status changes back to "dead",
> causing the unmount attempt. IMHO this approach isn't conceptually
> correct either -- in such containers, if don't have the corresponding
> device nodes at all, we shouldn't try to react to hotplug events and
> clean up mounts. I. e. the "tentative" concept does not really apply
> there. But I have misunderstood the intent.
> 
> Thanks for considering,
> 
> Martin
> 



pgpgiSEtZoMuz.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] dev-root.device is not active, results in an umount spree

[Martin Pitt]

Hello all,

Dimitri John Ledkov [2015-05-13 12:48 +0100]:
> I am booting without initramfs, using a plan9 filesystem as rootfs in a kvm.
> 
> Thus my /proc/cmdline has:
> root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p
> 
> # mount
> /dev/root on / type 9p
> (rw,relatime,sync,dirsync,rw,trans=virtio,version=9p2000.L)
> 
> Yet, dev-root.device is dead:
> # systemctl status dev-root.device
> ● dev-root.device
>Loaded: loaded
>Active: inactive (dead)
> 
> This is very bad. As a harmless action like following:
> 
> # mount --bind /opt /opt
> 
> Results in opt.mount unit to be generated which BindsTo
> dev-root.device, which is inactive, thus systemd tries to stop that
> unit straight away, and umount fails and is retried infinitely...
> effectively DoSing init.

As I mentioned before, simply ignoring /dev/root doesn't help in all
cases, and hardcoding it in the code is a bit ugly.

The attached patch is a more general solution which stops creating
dead stub .device units for devices which don't exist at all. I. e.
while in your case -.mount was probably BindsTo=dev-root.device (or in
my case, in my container I had mnt.mount BindsTo=dev-sda3.device,
which exists on the host but not in the container), but with this
patch it should now not be bound to anything.

Lennart, if you don't like this there is an alternative, and more
complicated solution: We could instead teach device_found_node() to
actually do create a proper .device with the passed DeviceFound (which
is "MOUNT"), resulting in creating a state "tentative" device. I have
a half-working patch for this, but it's brittle as with pretty much
any uevent or moutinfo change the status changes back to "dead",
causing the unmount attempt. IMHO this approach isn't conceptually
correct either -- in such containers, if don't have the corresponding
device nodes at all, we shouldn't try to react to hotplug events and
clean up mounts. I. e. the "tentative" concept does not really apply
there. But I have misunderstood the intent.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 76d3bc23db5aacd5e153b4472f10795d3b7b5212 Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Thu, 14 May 2015 12:36:44 +0200
Subject: [PATCH 2/2] device: Don't bind to nonexisting devices

In containers, with remote/NFS/other non-device file systems, or with /dev/root
it is common to have mountinfo entries which don't have an actual device node
in /dev, and thus device_found_node() will not create a .device unit for them
(not even a tentative one).

When binding a .mount to a .device, only do that if the .device actually
exists; if not, it would be immediately (attempted to) get unmounted again. The
previously used manager_load_unit() would create stub .device units with state
"dead", causing the above effect; so use manager_get_unit() instead.

Also revert commit 7ba2711d; it's a special case of this, and a rather ugly
hardcoding of a device name.

https://launchpad.net/bugs/102
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031658.html
---
 src/core/mount.c | 6 --
 src/core/unit.c  | 8 +---
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 8853311..e143f6b 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -317,12 +317,6 @@ static int mount_add_device_links(Mount *m) {
 if (!is_device_path(p->what))
 return 0;
 
-/* /dev/root is a really weird thing, it's not a real device,
- * but just a path the kernel exports for the root file system
- * specified on the kernel command line. Ignore it here. */
-if (path_equal(p->what, "/dev/root"))
-return 0;
-
 if (path_equal(m->where, "/"))
 return 0;
 
diff --git a/src/core/unit.c b/src/core/unit.c
index 1c1d9cf..9f028c4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2832,9 +2832,11 @@ int unit_add_node_link(Unit *u, const char *what, bool wants) {
 if (r < 0)
 return r;
 
-r = manager_load_unit(u->manager, e, NULL, NULL, &device);
-if (r < 0)
-return r;
+device = manager_get_unit(u->manager, e);
+if (!device) {
+log_unit_debug(u, "Device %s does not exist, not linking to it", e);
+return 0;
+}
 
 r = unit_add_two_dependencies(u, UNIT_AFTER, u->manager->running_as == MANAGER_SYSTEM ? UNIT_BINDS_TO : UNIT_WANTS, device, true);
 if (r < 0)
-- 
2.1.4



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] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Dimitri John Ledkov]

Hello,

On 14 May 2015 at 08:10, Per Bergqvist  wrote:
> Hej,
>
> There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer
> which was
> sort of rejected by Kay Sievers by referring to “we should find out what to
> do for nvme before
> adding new users of scsi_id”.
>
> More than a year later nothing has happened and recent commits actually
> branch out early
> for nvme drives.
>
> I have been using similar patches to Hal's albeit a little bit different.
>
> +# NVMe
> +KERNEL=="nvme*", ENV{ID_SCSI_SERIAL}!="?*", IMPORT{program}="scsi_id
> --export --whitelisted -d $devnode"
> +KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*",
> SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}"
> +KERNEL=="nvme*", ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*",
> SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}-part%n"
> +
>

This looks odd to me, from NVMe perspective. I would have thought the
stable names would be generated based on the NVMe Namespace UIDs
rather than anything else.

Keith - could you comment on above ^ ?

> I have found that the ID_SCSI_SERIAL is the most reliable since ID_SERIAL
> varies depending on systemd/driver/kernel versions.
> (My primary use for the NVMe drives is zfs log and cache devices. I test the
> zfs pool with different OS:es so I need
> the naming to be consistent over all targets OS:es).
>
> One may argue as Kay that it is not a scsi bus, but I think that the NVMe is
> related close enough to use the
> scsi_id, especially if considering the “NVM Express: SCSI Translation
> Reference”
> (http://www.nvmexpress.org/wp-content/uploads/NVM_Express_-_SCSI_Translation_Reference-1_4_20150116_Gold2.pdf).
>
> There is definitely a need for nvme support in udev and I think
> 60-persistent-storage.rules is the correct place.
>
> The only issue I can see is wether or not to use scsi_id or to introduce a
> new nvme_id utility.
>
> BR
> Per
>
>
>
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
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] [PATCH] sd-bus: fix potential UB in bus_socket_auth_verify_client()

[Lennart Poettering]

On Wed, 13.05.15 19:16, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

> When built with GCC undefined behaviour sanitizer the following problem
> surfaces:
> 
> src/libsystemd/sd-bus/bus-socket.c:180:11: runtime error: null pointer
> passed as argument 1, which is declared to never be null
> 
> Indeed, calling memmem where b->rbuffer == NULL is undefined
> behaviour.

Ah, well, the implementation of memmem() in glibc actually doesn't
have this limitation, only the prototype declares it. That's annoying.

> Fix that by returning if rbuffer is null or rbuffer_size < 2

I have now applied a different fix: memmem_safe() is to memmem() what
qsort_safe() is to qsort(): a small wrapper that allows NULL pointers
to be specified for zero-length buffers. I think this is the better
option here, I hope that makes sense,

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: Fix assertion with empty Exec*= paths

[systemd github import bot]

Patchset imported to github.
Pull request:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: introduce -e and -d for start and stop

[Jan Synacek]

Lennart Poettering  writes:

> On Wed, 13.05.15 15:21, jsyna...@redhat.com (jsyna...@redhat.com) wrote:
>
>> From: Jan Synacek 
>
> Hmm, do we really need two options for this? I mean, since -e would
> only ever be combined with start, and -d only with stop it could as
> well be a single option that works for both?

Makes sense. I actually wanted to implement the one argument version
first, but then decided to make it more explicit. Will fix.

> Also, I am tempted to say that this should be reversed: instead of
> making this options that alter start/stop behaviour, it should be
> options that alter enable/disable behaviour, and actually take into
> account the precise units that were enabled, including everything
> referenced in the [Install] section of the unit files.
>
> hence, I think I would prefer something like this instead:
>
>systemctl enable --now foobar.service
>systemctl disable --now foobar.service
>
> Where "--now" simply means that the service shall be started after
> enabling, and stopped after disabling. 
>
> Does this make sense?

Yes, it does. I'll rewrite the patch.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat


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

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Per Bergqvist]

Not really the point.

I do however prefer to trust an explicit indication in ENV{DEVTYPE} rather than 
to guess device type based on device naming.
And so does the standard scsi rules.

BR
Per

On 14 May 2015, at 9:20 , Robert Milasan  wrote:

> On Thu, 14 May 2015 09:10:40 +0200
> "Per Bergqvist"  wrote:
>> 
>> +KERNEL=="nvme*",ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*",
> 
> Wouldn't this make sense: KERNEL=="nvme*[!0-9]" (this is disk)
> 
>> +KERNEL=="nvme*",ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*",
> 
> and this KERNEL=="nvme*[0-9]" (this is partition) ?
> 
> 
> -- 
> Robert Milasan
> 
> L3 Support Engineer
> SUSE Linux (http://www.suse.com)
> email: rmila...@suse.com
> GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A






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

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Robert Milasan]

On Thu, 14 May 2015 09:10:40 +0200
"Per Bergqvist"  wrote:
> 
> +KERNEL=="nvme*",ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*",

Wouldn't this make sense: KERNEL=="nvme*[!0-9]" (this is disk)

> +KERNEL=="nvme*",ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*",

and this KERNEL=="nvme*[0-9]" (this is partition) ?


-- 
Robert Milasan

L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core: Fix assertion with empty Exec*= paths

[Martin Pitt]

Martin Pitt [2015-05-13 17:01 +0200]:
> I got a report [1] that you can trivially crash systemd (pid1) at boot
> by creating a unit with an Exec= line with a modifier and a space:
> 
> $ cat /tmp/foo.service
> [Service]
> ExecStart=- /bin/echo hello
> 
> $ systemd-analyze verify /tmp/foo.service
> Assertion 'skip < l' failed at ../src/core/load-fragment.c:607, function 
> config_parse_exec(). Aborting.
> Aborted (core dumped)
> 
> systemd pid 1 will crash the same way at boot, but with
> systemd-analyze it's less harmful to test :-)

This patch is a minimally invasive and straighforward fix for this
with the behaviour as discussed.  It is appropriate for the stable
branch and distro updates for stable releases.

I'd like to do the rewriting to unquote_first_word() in a separate
commit; it's easy to miss subtle corner cases. This is already
mentioned in TODO:

  * code cleanup: retire FOREACH_WORD_QUOTED, port to unquote_first_word() 
loops instead

(from the similar recent crash fixed in 470dca63c)

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 10f6ac7c8b3dad0197ce795e33383c24ea2d53b1 Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Thu, 14 May 2015 09:06:40 +0200
Subject: [PATCH] core: Fix assertion with empty Exec*= paths

An Exec*= line with whitespace after modifiers, like

  ExecStart=- /bin/true

is considered to have an empty command path. This is as specified, but causes
systemd to crash with

  Assertion 'skip < l' failed at ../src/core/load-fragment.c:607, function config_parse_exec(). Aborting.
  Aborted (core dumped)

Fix this by logging an error instead and ignoring the invalid line.

Add corresponding test cases. Also add a test case for a completely empty value
which resets the command list.

https://launchpad.net/bugs/1454173
---
 src/core/load-fragment.c  |  6 +-
 src/test/test-unit-file.c | 21 +
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index 33d9e27..3865017 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -595,7 +595,11 @@ int config_parse_exec(
 skip = separate_argv0 + ignore;
 
 /* skip special chars in the beginning */
-assert(skip < l);
+if (l <= skip) {
+log_syntax(unit, LOG_ERR, filename, line, EINVAL, "Empty path in command line, ignoring: %s", rvalue);
+r = 0;
+goto fail;
+}
 
 } else if (strneq(word, ";", MAX(l, 1U)))
 /* new commandline */
diff --git a/src/test/test-unit-file.c b/src/test/test-unit-file.c
index f3f6c29..03ca70a 100644
--- a/src/test/test-unit-file.c
+++ b/src/test/test-unit-file.c
@@ -317,6 +317,27 @@ static void test_config_parse_exec(void) {
 assert_se(r == 0);
 assert_se(c1->command_next == NULL);
 
+log_info("/* invalid space between modifiers */");
+r = config_parse_exec(NULL, "fake", 4, "section", 1,
+  "LValue", 0, "- /path",
+  &c, NULL);
+assert_se(r == 0);
+assert_se(c1->command_next == NULL);
+
+log_info("/* only modifiers, no path */");
+r = config_parse_exec(NULL, "fake", 4, "section", 1,
+  "LValue", 0, "-",
+  &c, NULL);
+assert_se(r == 0);
+assert_se(c1->command_next == NULL);
+
+log_info("/* empty argument, reset */");
+r = config_parse_exec(NULL, "fake", 4, "section", 1,
+  "LValue", 0, "",
+  &c, NULL);
+assert_se(r == 0);
+assert_se(c == NULL);
+
 exec_command_free_list(c);
 }
 
-- 
2.1.4



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

[systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Per Bergqvist]

Hej,

There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer 
which was 
sort of rejected by Kay Sievers by referring to “we should find out what to do 
for nvme before
adding new users of scsi_id”.

More than a year later nothing has happened and recent commits actually branch 
out early
for nvme drives.

I have been using similar patches to Hal's albeit a little bit different.

+# NVMe
+KERNEL=="nvme*", ENV{ID_SCSI_SERIAL}!="?*", IMPORT{program}="scsi_id --export 
--whitelisted -d $devnode"
+KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*", 
SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}"
+KERNEL=="nvme*", ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*", 
SYMLINK+="disk/by-id/nvme-$env{ID_SCSI_SERIAL}-part%n"
+

I have found that the ID_SCSI_SERIAL is the most reliable since ID_SERIAL 
varies depending on systemd/driver/kernel versions.
(My primary use for the NVMe drives is zfs log and cache devices. I test the 
zfs pool with different OS:es so I need
the naming to be consistent over all targets OS:es).

One may argue as Kay that it is not a scsi bus, but I think that the NVMe is 
related close enough to use the
scsi_id, especially if considering the “NVM Express: SCSI Translation 
Reference” 
(http://www.nvmexpress.org/wp-content/uploads/NVM_Express_-_SCSI_Translation_Reference-1_4_20150116_Gold2.pdf).

There is definitely a need for nvme support in udev and I think 
60-persistent-storage.rules is the correct place.

The only issue I can see is wether or not to use scsi_id or to introduce a new 
nvme_id utility.

BR
Per





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