[systemd-devel] systemd-nspawn old guests

[Thomas S Hatch]

I have been having trouble running nspawn containers that don't have
systemd (centos 6, Ubuntu 14.04, debian wheezy etc), I imagine I am just
not finding the solution online.
The container seems to start without issue but never presents a login
prompt. I added audit=0 to the kernel arguments as the manpage suggested
but to no avail.

I am using systemd 217 on Arch Linux.
Any suggestions as to where I should look to solve this?

Thomas S. Hatch  |  Founder, CTO

3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043
tha...@saltstack.com | www.saltstack.com 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Lennart Poettering]

On Fri, 05.12.14 10:58, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> That's not how I actually understood it. enable/disable still applies
> only to units with [Install] section as it is now. Just that
> 
> systemctl disable
> 
> means that if there are links in /usr/lib, they are masked in /etc.
> I.o. unit foo.service is enabled if
> 
> 1. [Install] section exists
> 2. Links from [Install] section are present either in /usr/lib or
> in /etc
> 
> unit foo.service is disabled if
> 
> 1. [Install] section exists
> 2. There are no links from [Install] in /usr/lib or /etc *OR* there are
> links in /usr/lib which are masked in /etc.
> 
> Units without [Install] section remains static as they are today.
> 
> This will allow to cleanly separate distribution default (/usr/lib) and
> admin decision (/etc). Also this will allow systemctl list-unit-files to
> supply information like
> 
> enabled (default)/enabled (admin)
> 
> depending on whether link in /usr/lib or /etc exists.
> 
> IOW - /usr/lib keeps default state and /etc keeps overrides for default
> state.

Hmm, I figure I could live with such a scheme. Not enthusiastic about
the idea, but I see the value, hence I'd merge a good patch for it.

Masking dependency symlinks is certainly OK, the part I am not overly
enthusiastic about is the changes to "systemctl enable" and "systemctl
disable" you propose. But given that behaviour of these commands
wouldn't change unless you actually have symlinks in /usr + [Install]
in the unit file, which doesn't really happen so far, I am fine with it.

Lennart

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

Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?

[Greg KH]

On Fri, Dec 05, 2014 at 01:42:29PM -0800, Lee Duncan wrote:
> On 12/05/2014 01:14 PM, Greg KH wrote:
> > On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote:
> >> Hi:
> >>
> >> I am trying to figure out how to use libudev to monitor for new iSCSI
> >> boot targets.
> >>
> >> For Emulex CNA cards, a new directory gets created of the form
> >> /sys/firmware/iscsi_bootN.
> > 
> > Really?  That's horrid, what kernel driver is doing that?
> 
> Why is it horrid? drivers/scsi/iscsi_boot_sysfs.c does that, and it
> looks like it's been doing it for quite a while.
> 
> The code in open-iscsi that looks for firmware iSCSI boot targets knows
> to look in both "/sys/firmware/iscsi_boot%d, and in /sys/firmware/ibft.
> iBFT is actually the standard, but many iSCSI CNA cards don't follow the
> standard.

Why is this a "firmware" thing at all?  These are devices, and
attributes for different devices, how are they related to firmware like
ACPI and PnP?

> >> I am new to libudev, but it looks like it's set up to monitor for new
> >> devices. Can I use it to monitor for non-device events? There must be
> >> some better way than polling.
> > 
> > Yes, go kick some kernel developers to do this "properly", which does
> > not mean using "raw" kobjects.  If you want, I will be glad to do that,
> > just point me at them...
> 
> Feel free to kick away, though I'm still not sure why (or who). The
> '/sys/firmware' subsystem seems like a good place to me for iSCSI CNA
> cards to place their firmware target information. But I obviously have
> much to learn about it.
> 
> And, for the record, I believe you are saying that my interpretation of
> libudev was right: it's not the tool to detect new iSCSI boot target
> presence, at least using the current /sys/firmware/iscsi_boot%d
> architecture. Correct?

That is correct, and that is why it's not a good idea for the kernel to
be placing code in such a location where no tool will ever be able to
see it.  It is making your life harder than it has to be, but now that
it is in that location, the odds of being able to move it out is slim.

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

Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?

[Lee Duncan]

On 12/05/2014 01:14 PM, Greg KH wrote:
> On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote:
>> Hi:
>>
>> I am trying to figure out how to use libudev to monitor for new iSCSI
>> boot targets.
>>
>> For Emulex CNA cards, a new directory gets created of the form
>> /sys/firmware/iscsi_bootN.
> 
> Really?  That's horrid, what kernel driver is doing that?

Why is it horrid? drivers/scsi/iscsi_boot_sysfs.c does that, and it
looks like it's been doing it for quite a while.

The code in open-iscsi that looks for firmware iSCSI boot targets knows
to look in both "/sys/firmware/iscsi_boot%d, and in /sys/firmware/ibft.
iBFT is actually the standard, but many iSCSI CNA cards don't follow the
standard.

> 
>> I am new to libudev, but it looks like it's set up to monitor for new
>> devices. Can I use it to monitor for non-device events? There must be
>> some better way than polling.
> 
> Yes, go kick some kernel developers to do this "properly", which does
> not mean using "raw" kobjects.  If you want, I will be glad to do that,
> just point me at them...

Feel free to kick away, though I'm still not sure why (or who). The
'/sys/firmware' subsystem seems like a good place to me for iSCSI CNA
cards to place their firmware target information. But I obviously have
much to learn about it.

And, for the record, I believe you are saying that my interpretation of
libudev was right: it's not the tool to detect new iSCSI boot target
presence, at least using the current /sys/firmware/iscsi_boot%d
architecture. Correct?

> 
> thanks,
> 
> greg k-h
> .
> 

-- 
Lee Duncan

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

Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?

[Greg KH]

On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote:
> Hi:
> 
> I am trying to figure out how to use libudev to monitor for new iSCSI
> boot targets.
> 
> For Emulex CNA cards, a new directory gets created of the form
> /sys/firmware/iscsi_bootN.

Really?  That's horrid, what kernel driver is doing that?

> I am new to libudev, but it looks like it's set up to monitor for new
> devices. Can I use it to monitor for non-device events? There must be
> some better way than polling.

Yes, go kick some kernel developers to do this "properly", which does
not mean using "raw" kobjects.  If you want, I will be glad to do that,
just point me at them...

thanks,

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

[systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?

[Lee Duncan]

Hi:

I am trying to figure out how to use libudev to monitor for new iSCSI
boot targets.

For Emulex CNA cards, a new directory gets created of the form
/sys/firmware/iscsi_bootN.

I am new to libudev, but it looks like it's set up to monitor for new
devices. Can I use it to monitor for non-device events? There must be
some better way than polling.

Thanks.
-- 
Lee Duncan

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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

[Benjamin Marzinski]

On Fri, Dec 05, 2014 at 11:07:35AM +0100, Harald Hoyer wrote:
> On 05.12.2014 08:20, Andrei Borzenkov wrote:
> > В Thu, 04 Dec 2014 18:24:11 +0100
> > Harald Hoyer  пишет:
> > 
> >> On 04.12.2014 18:19, Andrei Borzenkov wrote:
> >>> В Thu, 04 Dec 2014 15:14:00 +0100
> >>> Harald Hoyer  пишет:
> >>>
>  On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
> >> From: Harald Hoyer 
> >>
> >> If ID_FS_TYPE of a parent is already set,
> >> then it's something like "linux_raid_member" or "mpath_member"
> >> and the disk is already in use, so don't handle the partitions
> > Is this trying to fix an existing problem?
> 
>  yes, for "mpath_member" disk partitions, we should never ever advertise 
>  the
>  /dev/disk/by* symlinks or set SYSTEMD_READY for it.
> >>>
> >>> How is it going to work? I mean, first we get device, then it is
> >>> processed by multipathd. At the time rules are processed by udev, we
> >>> have no idea whether it will be added to mpath later.
> >>
> >> For the disk, we should/must the flag set immediately in 
> >> 62-multipath.rules.
> >>
> > 
> > OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to
> > "none", but the effect should be the same. I do not see this rule in
> > multipath-tools ... should not it be unified across distros?
> 
> Yeah, should be ...

The redhat multipath rules assume that you are using find_multipaths.
This isn't upstream yet. Hannes has rejected the patch twice, for
reasons I don't really understand. He recently requested that I push it
again, and I have in my last batch of patches.  But Christophe hasn't
pulled them, or any of my recent patches.  But that isn't a big deal.
It just involes changing "multipath -c" to "multipath -i -c" to ignore
the wwids file and just use the blacklist, when claiming a block device.

The bigger reason I've held off from pushing the rules is that, in order
to keep from doing all the 'multipath -c' work on every change event
(which could cause problems for udev if there were a large number of
events coming in at the same time) I added a timestamp that lets
multipathd know if /etc/multipath.conf or /etc/multipath/wwids has
changed.  However theres no way to compare db values in udev rules.

for instance

ENV{TEST_A}="$env{TEST_B}"  lets you assign the value of TEST_B to TEST_A

and

ENV{TEST_A}=="foo"  lets you compare the value of TEST_A to "foo"

however

ENV{TEST_A}=="$env{TEST_B}"  doesn't work.  You can't compare
the value of TEST_B to the value of TEST_A

So multipath has to hackily work around this in the udev rules.  I filed
a bug for this,

https://bugzilla.redhat.com/show_bug.cgi?id=1007650

and I don't want to push in hacky code without at least an answer why
this can't be solved in udev.

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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Uoti Urpala]

On Fri, 2014-12-05 at 02:39 +0100, Lennart Poettering wrote:
> On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
> > > On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
> > > > WantedBy=multi-user.target
> > > > 
> > > > and version B has
> > > > [Install]
> > > > WantedBy=foo.target
> > > 
> > > Package installs should probably not try to do something about this
> > > case, just leave things as is.
> > 
> > I think this would be a very bad idea. Installing a system and then
> > upgrading it should give you the same state as installing a newer system
> > directly; silently leaving outdated configuration in use almost ensures
> > that systems will fail/degrade over time.
> 
> Well, things are not that easy.
> 
> If distro Foobarix decides one day that from this day on sendmail
> should be enabled again by default, what is the "right" upgrade path
> for old installs? Should it be enabled now, because that's the new
> default for new installs? Or should it stay disabled, since that's
> what the user is accustomed to?

The context here was a package changing its install target, not changing
default enable/disable behavior as in your example. The latter is a less
clear-cut case: if the unit has a [Install] section, then presumably the
packager considers both enabled and disabled state supported at least to
some degree, and thus both are explicitly valid choices even on newly
installed systems. By contrast, leaving symlinks from targets that do
not match the [Install] section of the current service file anymore is
more arbitrary reconfiguration, which cannot be expected to work in
general (as in linking arbitrary units from arbitrary targets is not
expected to work), and it's the admin's responsibility to investigate
what he needs to do to make such configurations work and keep them
working.

Keeping such obsolete configuration would mean that systems rot over
time. Package configuration files are not handled that way, and package
startup configuration shouldn't be either, for the same reasons.

Just leaving the symlinks would not give good behavior even in the case
where the admin wants to keep the old target: temporary disable + then
re-enable would now change the target. Perhaps the recommended way to
change targets in local configuration should be to override the
[Install] section, instead of just leaving different symlinks?


> units towards statically enabled ones anyway. But again: if something
> was optional before, and is optional after, then be conservative,
> don't change things...

IMO in the changing-targets case it's not "conservative" at all to
silently leave the system in a state where it has obsolete configuration
which does not match anything supported by the current packaging. Such
behavior is almost 100% guaranteed to break things at some point.
"Conservative" would be something like refusing to upgrade until the
admin resolves possible conflicts manually. If no local configuration
can be detected, using the new packaging defaults has a better chance of
avoiding breakage than leaving obsolete configuration.


> Sure, if you know that changes in your unit files actively break a
> previous default, then you should do something about it, but I think
> cases like this are best handled with careful, manually written
> postinst scripts, that do the right thing in the most defensive
> possible way. But blindly enabling all kinds of stuff just because the
> upstream default changed is really not a good idea I think.

The new defaults could enable more things, or they could disable parts
that are now deemed insecure or unnecessary, or just generally fix bugs.
The sane default assumption is that later package versions are better
than earlier ones, and leaving the system using old default
configuration is worse than new configuration. And that's assuming the
old configuration even works anymore given changes elsewhere.


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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Lennart Poettering]

On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote:

> >Whenever the preset db is queried we'll no longer just return the
> >verdict boolean, but also a numeric overall line number, of the line
> >we found the verdict on. Then, when "preset-all" is invoked, we
> >determine all the operations to execute for everything. Then, before
> >applying them, we check if there are any conflicting operations. If
> >so, we remove the ones with the higher line number.
> >
> >In effect this would mean: if you list to DMs as "enable" in the
> >preset file, and both are to be installed, then the one that is
> >enabled "earlier" will win in case of "preset-all". To me this appears
> >quite a natural extension of the logic already in place.
> 
> And I guess the default behavior (enable *) has a lower priority than
> overrides? (enable/disable). Also, I guess you concatenate all preset files
> as if it was a single one (ascii ordered?) to build that list.

Yeah, the default policy of "enable *" would have the largest possible
line number, so that any other line number wins.

> So, retaking the display-manager (on the principle they all have:
> Alias=display-manager.service) example, that would mean:
> * ubuntu-desktop would ship 99-defaults with:
> enable lightdm
> 
> * If someone, install the gnome-ubuntu-desktop metapackage on the same
> install, they would get an additional preset file 50-gnome-ubuntu with:
> enable gdm
> 
> And so, lightdm would be removed on a preset-all call as conflicting with
> gdm (due to sharing the same Alias) and having higher line number.

correct.

> Sounds like a nice way to handle Alias. Happy to have a look at
> this.

Would love to take a patch for this.

> >>Only preinst can (getting the "install" or "upgrade" argument), not postinst
> >>(getting "configure" in both case). And we need to run the preset/enable in
> >>postinst (meaning: after unpacking).
> >This sounds quite a limitation. Maybe you can keep a couple of touch files
> >in /var/lib/ somewhere where you store whether you already applied
> >"systemctl preset" before?
> 
> This is possible, but really not encouraged (due to some possibility to have
> unpacking or other intermediate states failing).
> This would also only "fix" the newly installed case, not the upgrade with
> new distro defaults or various purge vs remove ones. That's why I think some
> kind of previous state db can help getting all those requirements met as you
> propose, and doing some comparisons between states (only when they deviated
> from defaults).
> Then, we can run preset on packages that matches previous defaults (meaning:
> where the admin didn't override the default choice) as a dpkg trigger (when
> new units are installed/upgraded and on a new/updated preset file shipped).
> Would that makes sense?

Not sure I grok what you are proposing. I'd be very careful with
keeping yet another layer of service enablement states (even if just
as "history") in systemd upstream.

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] user environment variables

[Mantas Mikulėnas]

On Fri, Dec 5, 2014 at 5:20 PM, Daniele Nicolodi  wrote:

> On 05/12/14 16:13, arnaud gaboury wrote:
> > Now:
> > --
> > $ echo 'lolo=4 lala=5' | tee test
> > lolo=4 lala=5
> > $ systemctl --user set-environment 'cat test'
> > Failed to set environment: Invalid environment assignments
> > ---
> >
> > No idea what I do wrong.
>
> This is invalid shell syntax. This should work:
>
> $ systemctl --user set-environment `cat test`
>
> or, if you are using bash, I find this more readable:
>
> $ systemctl --user set-environment $(cat test)
>

As the variables sometimes have spaces, this might be more reliable:

xargs systemctl --user set-environment < test

(With -d '\n' or without, depending on chosen syntax.)

It's possible to emulate "import-environment" using:

xargs -d '\0' systemctl --user set-environment < /proc/self/environ

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

Re: [systemd-devel] user environment variables

[arnaud gaboury]

>
> $ systemctl --user set-environment `cat test`
>
Damned. Thank you
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user environment variables

[Daniele Nicolodi]

On 05/12/14 16:13, arnaud gaboury wrote:
> Now:
> --
> $ echo 'lolo=4 lala=5' | tee test
> lolo=4 lala=5
> $ systemctl --user set-environment 'cat test'
> Failed to set environment: Invalid environment assignments
> ---
> 
> No idea what I do wrong.

This is invalid shell syntax. This should work:

$ systemctl --user set-environment `cat test`

or, if you are using bash, I find this more readable:

$ systemctl --user set-environment $(cat test)


Cheers,
Daniele

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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

[Benjamin Marzinski]

On Fri, Dec 05, 2014 at 11:07:35AM +0100, Harald Hoyer wrote:
> On 05.12.2014 08:20, Andrei Borzenkov wrote:
> > В Thu, 04 Dec 2014 18:24:11 +0100
> > Harald Hoyer  пишет:
> > 
> >> On 04.12.2014 18:19, Andrei Borzenkov wrote:
> >>> В Thu, 04 Dec 2014 15:14:00 +0100
> >>> Harald Hoyer  пишет:
> >>>
>  On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
> >> From: Harald Hoyer 
> >>
> >> If ID_FS_TYPE of a parent is already set,
> >> then it's something like "linux_raid_member" or "mpath_member"
> >> and the disk is already in use, so don't handle the partitions
> > Is this trying to fix an existing problem?
> 
>  yes, for "mpath_member" disk partitions, we should never ever advertise 
>  the
>  /dev/disk/by* symlinks or set SYSTEMD_READY for it.
> >>>
> >>> How is it going to work? I mean, first we get device, then it is
> >>> processed by multipathd. At the time rules are processed by udev, we
> >>> have no idea whether it will be added to mpath later.
> >>
> >> For the disk, we should/must the flag set immediately in 
> >> 62-multipath.rules.
> >>
> > 
> > OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to
> > "none", but the effect should be the same. I do not see this rule in
> > multipath-tools ... should not it be unified across distros?
> 
> Yeah, should be ...
> 
> Upstream does not even ship a rule, which sets ID_FS_TYPE.
> 
> I don't know why we have 100 patches in Fedora rawhide on
> top of upstream for the multipath tools.
> 
> Seems like nobody is pushing patches upstream, or upstream is not accepting 
> any.

Since multipath upstream doesn't have a stable branch.  The safest thing
to do is to pick a point and pull then, and just apply known stable
patches on top of it, instead of trying to keep in sync with upstream,
and repeatedly pulling down patches that break things.

But, yes, upstream currently doesn't appear to be taking patches.
Christophe hasn't responded to any of my emails recently, and and the
last patch of mine he's accepted (or even commented on) was IIRC in
September. I assume this is just temporary, and was planning to wait
until January to see if he came back.

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

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

[Tom Gundersen]

On Fri, Dec 5, 2014 at 2:21 PM, Lennart Poettering
 wrote:
> On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote:
>
>> Hi Lennart,
>>
>>  Moreover, if we
>>  give people this feature I'm pretty sure we'll get lots of people
>>  expecting it to work also for any other sort of name and getting
>>  confused when it doesn't.
>> >>>
>> >>> Well, this is something we can fix by documentation, no?
>> >>>
>> >>> Or maybe name the match option differently, maybe OriginalName= or
>> >>> KernelName= or so, and then only matching interfaces where you know
>> >>> that the name was selected by userspace in the first place?
>> >>
>> >> I like the idea of OriginalName, much less likely to get people
>> >> confused. I now implemented that, with the restriction that we cannot
>> >> match on renamed names. For now I left it open to match on ethX style
>> >> names, as people in principle could do sensible things like
>> >> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
>> >> only one interface.
>> >>
>> >> One thing to consider would be to disallow renaming from a .link file
>> >> where the OriginalName was used to match. That way we don't have the
>> >> somewhat odd situation that a .link file can only be applied once (we
>> >> do not remember the original name, so cannot match on that the second
>> >> time around, as that would be a mess)...
>> >
>> > Maybe we should even store the original name in a udev property, so
>> > that we can make this fully idempotent simply because we can always
>> > check this new property for the original name passed down from the
>> > kernel?
>>
>> you do realize that once the kernel renamed the name, it is free to
>> reuse that name again. So eth0 as OriginalName can then be present
>> multiple times.
>>
>> I think that you can only have OriginalName matching if a renaming
>> has never occurred. Otherwise this is really not
>> deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed
>> from eth0) will both match OriginalName=eth0. The difference is only
>> timing and that is inhering racy of course.
>
> Well, sure, if you use OriginalName= for such names, it's your own
> fault. I think using OriginalName= is primarily useful for things like
> veth links where the names are chosen by userspace anyway.
>
> Hmm, now that the naming policy is exposed by the kernel, can we
> detect the cases where naming happens like "eth0", "eth1", and print a
> nice warning or so, if people then match against that?

I added some warnings to git now. Still need to push some more kernel
patches to get more stuff tagged correctly, but at least the systemd
side is now good.

Cheers,

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

[systemd-devel] [PATCH] journal: Fix navigating backwards missing entries

[Olivier Brunel]

With DIRECTION_UP (i.e. navigating backwards) in generic_array_bisect() when the
needle was found as the last item in the array, it wasn't actually processed as
match, resulting in entries being missed.

https://bugs.freedesktop.org/show_bug.cgi?id=86855
---
This was a good excuse for me to dive in and learn about journal's internals,
but someone with actual knowledge of said internals should review this, in case
I missed something.

 src/journal/journal-file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 7858435..c5d2d19 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -1657,7 +1657,7 @@ static int generic_array_bisect(
 }
 }
 
-if (k > n) {
+if (k >= n) {
 if (direction == DIRECTION_UP) {
 i = n;
 subtract_one = true;
-- 
2.1.3

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

Re: [systemd-devel] user environment variables

[arnaud gaboury]

>
> systemctl set-environment `cat FILE` should work, no?
>
> Lennart
>

I am messing with it.


$ systemctl --user set-environment toto=3 tata=4
$ systemctl --user show-environment
..
tata=4
toto=3
-

Now:
--
$ echo 'lolo=4 lala=5' | tee test
lolo=4 lala=5
$ systemctl --user set-environment 'cat test'
Failed to set environment: Invalid environment assignments
---

No idea what I do wrong.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Didier Roche]

Le 05/12/2014 14:52, Lennart Poettering a écrit :

On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote:


It seems maintaining this list in sync for all flavors would be a growing
pain (this is a positive effect of the disable by default: you don't have to
maintain such a list), or do you think we can come with something
better?

Hmm, yuck. No good suggestion. I figure this problem doesn't exist
with the fedora default of everything is disabled by default...

All open to ideas...

Can we maybe extend the preset dictionary by having an alias (or
alias-default) keyword taking a pair of arguments, like:
alias display-manager.service lightdm.service

Then, the preset command, for each alias, will stop at the first one it
encounters. If the service doesn't exist, it's a noop, if it's there, it
enables (--force in case something else was enabled for that Alias?)
lightdm.service. It means of course that lightdm.service should contain:
[Install]
Alias=display-manager.service

or preset would then generates a warning.

So far this is not how presets work: they are just a database you pass
in as key a service name, and it tells you whether to enable it or
not, in a simple boolean way. It is something where you pass in the
name of a unit you want to enable/disable, and after you got that, you
do that, but you do not verify again the individual steps
enabling/disabling precisely entail.

It also is currently entirely stateless: you could in theory ask a web
server for such a preset question, and it will always tell you the
same answer, because it does *not* take your local configuration and
set of packages into consideration... This kind of "disconnected" logic
I'd really like to keep.

Hmm, what about this proposal:

Whenever the preset db is queried we'll no longer just return the
verdict boolean, but also a numeric overall line number, of the line
we found the verdict on. Then, when "preset-all" is invoked, we
determine all the operations to execute for everything. Then, before
applying them, we check if there are any conflicting operations. If
so, we remove the ones with the higher line number.

In effect this would mean: if you list to DMs as "enable" in the
preset file, and both are to be installed, then the one that is
enabled "earlier" will win in case of "preset-all". To me this appears
quite a natural extension of the logic already in place.


And I guess the default behavior (enable *) has a lower priority than 
overrides? (enable/disable). Also, I guess you concatenate all preset 
files as if it was a single one (ascii ordered?) to build that list.


So, retaking the display-manager (on the principle they all have: 
Alias=display-manager.service) example, that would mean:

* ubuntu-desktop would ship 99-defaults with:
enable lightdm

* If someone, install the gnome-ubuntu-desktop metapackage on the same 
install, they would get an additional preset file 50-gnome-ubuntu with:

enable gdm

And so, lightdm would be removed on a preset-all call as conflicting 
with gdm (due to sharing the same Alias) and having higher line number.


Sounds like a nice way to handle Alias. Happy to have a look at this.




How does this all precisely work on  on ?

Most of them shipped a conffile like /etc/default/ file with
an ENABLED=true/false keyword. This doesn't really map in the systemd world
(repetition of enablement/disablement states)
* "apt-get remove" keeps conffiles
* "apt-get remove --purge" deletes them.
* When an upgrade occurs:
   - if the package conffile didn't change -> kept with the modifications if
any
   - if the package conffile did change -> infamous debconf prompt about "a
maintainer configuration file changes, do you want to apply maintainer
changes/keep as it is/see the diff…"

That's how all those use cases are handled on sysvinit.
Of course, we could introduce that back with ExecStartPre=`grep …` but well,
2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't
really appealing nor wanted :)

To be honest I find the entire stuff with ENABLED=true/false really
questionnable, I think it would be agreat step ahead to get rid of
it. (But then again, I cannot make Debian's decisions there...)


Agreed, I already removed it from some ubuntu-only packages like 
whoopsie, xdiagnose… and I'm trying to investigate the right way to get 
a systemd-oriented solutions (while still being compatible with older 
init system for debian)



Only preinst can (getting the "install" or "upgrade" argument), not postinst
(getting "configure" in both case). And we need to run the preset/enable in
postinst (meaning: after unpacking).

This sounds quite a limitation. Maybe you can keep a couple of touch files
in /var/lib/ somewhere where you store whether you already applied
"systemctl preset" before?


This is possible, but really not encouraged (due to some possibility to 
have unpacking or other intermediate states failing).
This would also only "fix" the newly installed case, not the up

Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Karel Zak]

On Fri, Dec 05, 2014 at 01:46:06AM +0100, Lennart Poettering wrote:
> With such an API you have the liberty to change later on what
> precisely you expose there. The fact that you watch a file would be
> entirely opaque, it could one day be a pipe or socket, or even an fd
> on some kernel fd, where you just tell us the kind of events you want
> the user code to listen on.
> 
> This is how we wrap a lot of our own APIs, to allow integration into
> arbitrary main loops, without restricting us to decide how precisely
> the event is generated.
> 
> Does this make sense?

Yep.

> Would love to get an API in place for this in libmount, because I
> don't really want to release systemd with the current code.

Implemented.

I have added struct libmnt_monitor to make this new interface easy to
extend and usable for more resources (I'll probably also add mountinfo
fd for findmnt(8), but this is irrelevant for systemd;-)

All you need is:

mn = mnt_new_monitor();
fd = mnt_monitor_userspace_get_fd(mn, NULL);/* utab monitor fd */

mnt_monitor_get_events(mn, fd, &ev.events); /* EPOLLIN ... */

efd = epoll_create1(EPOLL_CLOEXEC);
epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ev);


n = epoll_wait(efd, events, 1, -1);
id (n == 1 && mnt_monitor_is_changed(mn, fd) == 1)
printf("%s: change detected\n", mnt_monitor_get_filename(mn, 
fd));


mnt_unref_monitor(mn);
close(efd);


I guess it's enough to add the 'fd' to systmed sd_event_add_io() and
call mnt_table_parse_mtab() when a change is detected. (As already
implemeted in the original Chris' patch.)



usable example:

https://github.com/karelzak/util-linux/blob/master/libmount/src/monitor.c#L345


Karel

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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Colin Guthrie]

Lennart Poettering wrote on 05/12/14 13:52:
>> > Only preinst can (getting the "install" or "upgrade" argument), not 
>> > postinst
>> > (getting "configure" in both case). And we need to run the preset/enable in
>> > postinst (meaning: after unpacking).
> This sounds quite a limitation. Maybe you can keep a couple of touch files
> in /var/lib/ somewhere where you store whether you already applied
> "systemctl preset" before?

For what it's worth, this is the technique I used when migrating
sysvinit -> native units.

For a while, we had both sysvinit script and systemd units shipped in
the same package (to allow a choice of init system - but we dropped
support for sysvinit ages ago - in fact the last distro version that
supported this went EOL the other day!).

When the systemd unit was first introduced in the package (assuming the
user was upgrading) we would migrate the enablement state of the
sysvinit script to the systemd unit - if sysvinit was enabled, then so
should the systemd unit; if it was disabled then so should the systemd
unit. We only did this the first time the systemd unit showed up in the
package and touched a file in /var/lib to track this. After this initial
transition, their enablement state (whether it be sysvinit or native)
was in the hands of the admin.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Lennart Poettering]

On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote:

> >>It seems maintaining this list in sync for all flavors would be a growing
> >>pain (this is a positive effect of the disable by default: you don't have to
> >>maintain such a list), or do you think we can come with something
> >>better?
> >Hmm, yuck. No good suggestion. I figure this problem doesn't exist
> >with the fedora default of everything is disabled by default...
> >
> >All open to ideas...
> 
> Can we maybe extend the preset dictionary by having an alias (or
> alias-default) keyword taking a pair of arguments, like:
> alias display-manager.service lightdm.service
> 
> Then, the preset command, for each alias, will stop at the first one it
> encounters. If the service doesn't exist, it's a noop, if it's there, it
> enables (--force in case something else was enabled for that Alias?)
> lightdm.service. It means of course that lightdm.service should contain:
> [Install]
> Alias=display-manager.service
> 
> or preset would then generates a warning.

So far this is not how presets work: they are just a database you pass
in as key a service name, and it tells you whether to enable it or
not, in a simple boolean way. It is something where you pass in the
name of a unit you want to enable/disable, and after you got that, you
do that, but you do not verify again the individual steps
enabling/disabling precisely entail.

It also is currently entirely stateless: you could in theory ask a web
server for such a preset question, and it will always tell you the
same answer, because it does *not* take your local configuration and
set of packages into consideration... This kind of "disconnected" logic
I'd really like to keep.

Hmm, what about this proposal:

Whenever the preset db is queried we'll no longer just return the
verdict boolean, but also a numeric overall line number, of the line
we found the verdict on. Then, when "preset-all" is invoked, we
determine all the operations to execute for everything. Then, before
applying them, we check if there are any conflicting operations. If
so, we remove the ones with the higher line number.

In effect this would mean: if you list to DMs as "enable" in the
preset file, and both are to be installed, then the one that is
enabled "earlier" will win in case of "preset-all". To me this appears
quite a natural extension of the logic already in place.

> >How does this all precisely work on  on ?
> 
> Most of them shipped a conffile like /etc/default/ file with
> an ENABLED=true/false keyword. This doesn't really map in the systemd world
> (repetition of enablement/disablement states)
> * "apt-get remove" keeps conffiles
> * "apt-get remove --purge" deletes them.
> * When an upgrade occurs:
>   - if the package conffile didn't change -> kept with the modifications if
> any
>   - if the package conffile did change -> infamous debconf prompt about "a
> maintainer configuration file changes, do you want to apply maintainer
> changes/keep as it is/see the diff…"
> 
> That's how all those use cases are handled on sysvinit.
> Of course, we could introduce that back with ExecStartPre=`grep …` but well,
> 2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't
> really appealing nor wanted :)

To be honest I find the entire stuff with ENABLED=true/false really
questionnable, I think it would be agreat step ahead to get rid of
it. (But then again, I cannot make Debian's decisions there...)

> Only preinst can (getting the "install" or "upgrade" argument), not postinst
> (getting "configure" in both case). And we need to run the preset/enable in
> postinst (meaning: after unpacking).

This sounds quite a limitation. Maybe you can keep a couple of touch files
in /var/lib/ somewhere where you store whether you already applied
"systemctl preset" before?

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-nspawn@.service is unusable

[Peter Lemenkov]

2014-12-05 16:25 GMT+03:00 Lennart Poettering :
> On Fri, 05.12.14 16:58, Peter Lemenkov (lemen...@gmail.com) wrote:
>
>> Ok, now I've got something. Here is a a diff between good (1st,
>> commandline) and bad (2nd, systemd service) sessions:
>>
>> * https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff
>>
>> More specifically I found these pieces interesting:
>>
>> * 
>> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258
>>
>> Notice "open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
>> (Permission denied)" when started as systemd service:
>>
>> * 
>> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700
>>
>> Notice "unlink("/run/systemd/journal/dev-log")  = -1 EACCES
>> (Permission denied)" followed by "bind(7, {sa_family=AF_LOCAL,
>> sun_path="/run/systemd/journal/dev-log"}, 30) = -1 EADDRINUSE (Address
>> already in use)".
>>
>> Looks like systemd-nspawn either doesn't mounts (bind mounts) a
>> necessary devices or doesn't create them properly.
>
> Hmm, do you have SELinux enabled and in enforcing mode?
>
> nspawn mounts a tmpfs to /run, very early on, before invoking the
> first binary, it should definitely be writable.

Yes! That's a SELinux denial. I'm sorry for bothering you and for not
trying switching selinux off and on again - I actually thought that
all the SELinux issues are gone already.

In case you're interested - here is a dump of dmesg | audit2allow:


#= getty_t ==
allow getty_t devpts_t:chr_file { write getattr setattr read open ioctl };
allow getty_t rpm_var_lib_t:file open;
allow getty_t tmpfs_t:chr_file read;

#= syslogd_t ==
allow syslogd_t tmpfs_t:chr_file { read write ioctl open };
allow syslogd_t tmpfs_t:dir { write create add_name };
allow syslogd_t tmpfs_t:file { create setattr };
allow syslogd_t tmpfs_t:sock_file write;

#= systemd_logind_t ==
allow systemd_logind_t tmpfs_t:filesystem mount;
allow systemd_logind_t tmpfs_t:sock_file write;
allow systemd_logind_t user_tmp_t:dir mounton;

#= systemd_sysctl_t ==

# This avc can be allowed using the boolean 'domain_kernel_load_modules'
allow systemd_sysctl_t kernel_t:system module_request;

#==

And here is a full explanation:

https://paste.fedoraproject.org/156932/78730514/

I'll try to open a bug reports in RHBZ on each issue found.

-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user environment variables

[Lennart Poettering]

On Fri, 05.12.14 14:13, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> Dear all,
> 
> For the user services started by systemctl --user, I sometimes need to
> tell systemd some environment variables values.
> 
> For this purpose, I use drop-in configuration files (MyService.conf)
> in /etc/systemd/system/user@.service.d
> 
> I am wondering if there is another way to pass the variables values.
> I was thinking to some user directory like this :
> ~/.config/systemd/user@.service.d (does not work) or import one only
> file with all these variables values with this command at session
> start up: systemctl --import-environment FILE (does not work), or
> maybe something like systemctl --import-environment 'cat FILE'.

systemctl set-environment `cat FILE` should work, 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] systemd-nspawn@.service is unusable

[Lennart Poettering]

On Fri, 05.12.14 16:58, Peter Lemenkov (lemen...@gmail.com) wrote:

> Ok, now I've got something. Here is a a diff between good (1st,
> commandline) and bad (2nd, systemd service) sessions:
> 
> * https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff
> 
> More specifically I found these pieces interesting:
> 
> * 
> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258
> 
> Notice "open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
> (Permission denied)" when started as systemd service:
> 
> * 
> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700
> 
> Notice "unlink("/run/systemd/journal/dev-log")  = -1 EACCES
> (Permission denied)" followed by "bind(7, {sa_family=AF_LOCAL,
> sun_path="/run/systemd/journal/dev-log"}, 30) = -1 EADDRINUSE (Address
> already in use)".
> 
> Looks like systemd-nspawn either doesn't mounts (bind mounts) a
> necessary devices or doesn't create them properly.

Hmm, do you have SELinux enabled and in enforcing mode?

nspawn mounts a tmpfs to /run, very early on, before invoking the
first binary, it should definitely be writable.

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] networkd: Support setting mtu / mac address by interface name

[Lennart Poettering]

On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote:

> Hi Lennart,
> 
>  Moreover, if we
>  give people this feature I'm pretty sure we'll get lots of people
>  expecting it to work also for any other sort of name and getting
>  confused when it doesn't.
> >>> 
> >>> Well, this is something we can fix by documentation, no?
> >>> 
> >>> Or maybe name the match option differently, maybe OriginalName= or
> >>> KernelName= or so, and then only matching interfaces where you know
> >>> that the name was selected by userspace in the first place?
> >> 
> >> I like the idea of OriginalName, much less likely to get people
> >> confused. I now implemented that, with the restriction that we cannot
> >> match on renamed names. For now I left it open to match on ethX style
> >> names, as people in principle could do sensible things like
> >> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
> >> only one interface.
> >> 
> >> One thing to consider would be to disallow renaming from a .link file
> >> where the OriginalName was used to match. That way we don't have the
> >> somewhat odd situation that a .link file can only be applied once (we
> >> do not remember the original name, so cannot match on that the second
> >> time around, as that would be a mess)...
> > 
> > Maybe we should even store the original name in a udev property, so
> > that we can make this fully idempotent simply because we can always
> > check this new property for the original name passed down from the
> > kernel?
> 
> you do realize that once the kernel renamed the name, it is free to
> reuse that name again. So eth0 as OriginalName can then be present
> multiple times.
> 
> I think that you can only have OriginalName matching if a renaming
> has never occurred. Otherwise this is really not
> deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed
> from eth0) will both match OriginalName=eth0. The difference is only
> timing and that is inhering racy of course.

Well, sure, if you use OriginalName= for such names, it's your own
fault. I think using OriginalName= is primarily useful for things like
veth links where the names are chosen by userspace anyway. 

Hmm, now that the naming policy is exposed by the kernel, can we
detect the cases where naming happens like "eth0", "eth1", and print a
nice warning or so, if people then match against that?

Lennart

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

[systemd-devel] user environment variables

[arnaud gaboury]

Dear all,

For the user services started by systemctl --user, I sometimes need to
tell systemd some environment variables values.

For this purpose, I use drop-in configuration files (MyService.conf)
in /etc/systemd/system/user@.service.d

I am wondering if there is another way to pass the variables values.
I was thinking to some user directory like this :
~/.config/systemd/user@.service.d (does not work) or import one only
file with all these variables values with this command at session
start up: systemctl --import-environment FILE (does not work), or
maybe something like systemctl --import-environment 'cat FILE'.

Thank you for any hint.

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

Re: [systemd-devel] preset enables everything by default

[Lennart Poettering]

On Thu, 04.12.14 18:58, Michael Marineau (michael.marin...@coreos.com) wrote:

> > We use the machine-id file as check whether /etc is populated or
> > not. If people pre-populate /etc, and don't wan't the full
> > "first-boot" logic of systemd to take action, then they should also
> > add machine-id file there (they can even just touch it if they want,
> > which will disable the first-boot logic, but still initialize the file
> > either directly if writable or overmounted if not).
> 
> So when assembling a machine image that will be used to create a bunch
> of pre-configured hosts the correct thing to do is 'echo >
> machine-id', not 'rm machine-id'?

Well, it's up to you:

a) install a "disable *" preset file in your /usr, and use "rm /etc/machine-id"

b) don't install any preset file and use "echo > /etc/machine-id"

If you opt for a, then this has the benefit that the first bootup is
still special, and ConditionFirstBoot= will still trigger for it,
which might be useful for a number of services.

If I were you I'd opt for a).

> >> This behavior is probably ok in the case of interactively using
> >> systemctl preset and preset-all when it is known that the user
> >> explicitly asked the system to do something and can see what it did.
> >> In the case of the system booting I would expect "do nothing" to be
> >> the default when no preset file explicitly sates otherwise.
> >
> > Then ship a "disable *" preset file in /sr. In this case, nothing will
> > be enabled by default. THis is what we do on Fedora.
> 
> And I've added this to CoreOS too. The gist of my rambling email was
> why is this not the default?

Well, for simplicity reasons, outside of the stateless machines
business it is kinda useful being able to ignore the entire complexity
of presets, enabling, disabling, and just consider the RPM scriptlets
as something that truns on what is being installed, end of story.

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-nspawn@.service is unusable

[Peter Lemenkov]

2014-12-05 4:43 GMT+03:00 Lennart Poettering :
> On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote:
>
>> Hello All!
>>
>> I'm playing with systemd-nspawn@.service and cannot make it work. It
>> seems that similar issues were discussed (and addressed upstream) in
>> Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
>> believe I've hit by something else.
>>
>> What I've done so far:
>>
>> * Ensured that /var/lib/container exists
>> * Created both  /var/log/journal/ and
>> /var/lib/container//var/log/journal/
>> * Ensured that Storage=persistent is set in
>> /var/lib/container//etc/systemd/journald.conf
>>
>> Every my attempt to run "systemctl status
>> systemd-nspawn@" ended up like this:
>>
>> https://paste.fedoraproject.org/156640/14177088/
>>
>> Please note that systemd-journald fails so I can't find out what's
>> going on there. I'm stuck right here. Some other services failed as
>> well, and I can't login using "machinectl login" but that's another
>> story I believe.
>>
>> Any advice on how to debug this and make
>> systemd-nspawn@ usable are highly appreciate!
>
> What happens if you run the same nspawn command from the command line?
> Does journald then start up correctly in it?
>
> What happens if you add "debug" to the end of the nspawn cmdline? Do
> you see anything interesting in the additional log output this
> generates?
>
> If it fails then, too. Can you "strace -ff -o ~/nspawnlogs" the whole nspawn 
> process
> (and hence also its child processes), then find the strace log this
> created for journald, and check what the last bits are that it does.

Ok, now I've got something. Here is a a diff between good (1st,
commandline) and bad (2nd, systemd service) sessions:

* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff

More specifically I found these pieces interesting:

* 
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258

Notice "open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
(Permission denied)" when started as systemd service:

* 
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700

Notice "unlink("/run/systemd/journal/dev-log")  = -1 EACCES
(Permission denied)" followed by "bind(7, {sa_family=AF_LOCAL,
sun_path="/run/systemd/journal/dev-log"}, 30) = -1 EADDRINUSE (Address
already in use)".

Looks like systemd-nspawn either doesn't mounts (bind mounts) a
necessary devices or doesn't create them properly.

-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn@.service is unusable

[Peter Lemenkov]

2014-12-05 12:41 GMT+03:00 Peter Lemenkov :
> 2014-12-05 4:43 GMT+03:00 Lennart Poettering :
>> On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote:
>>
>>> Hello All!
>>>
>>> I'm playing with systemd-nspawn@.service and cannot make it work. It
>>> seems that similar issues were discussed (and addressed upstream) in
>>> Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
>>> believe I've hit by something else.
>>>
>>> What I've done so far:
>>>
>>> * Ensured that /var/lib/container exists
>>> * Created both  /var/log/journal/ and
>>> /var/lib/container//var/log/journal/
>>> * Ensured that Storage=persistent is set in
>>> /var/lib/container//etc/systemd/journald.conf
>>>
>>> Every my attempt to run "systemctl status
>>> systemd-nspawn@" ended up like this:
>>>
>>> https://paste.fedoraproject.org/156640/14177088/
>>>
>>> Please note that systemd-journald fails so I can't find out what's
>>> going on there. I'm stuck right here. Some other services failed as
>>> well, and I can't login using "machinectl login" but that's another
>>> story I believe.
>>>
>>> Any advice on how to debug this and make
>>> systemd-nspawn@ usable are highly appreciate!
>>
>> What happens if you run the same nspawn command from the command line?
>> Does journald then start up correctly in it?
>
> Yes, it works perfectly fine if I run it as
>
> $ sudo /usr/bin/systemd-nspawn  --keep-unit --boot
> --directory=/var/lib/container/earlyannounce
>
> I can login and see logs. Unfortunately no logs from the previous boot
> are available (due to failed systemd-journald.service).
>
>> What happens if you add "debug" to the end of the nspawn cmdline? Do
>> you see anything interesting in the additional log output this
>> generates?
>
> Can't say for sure. Here is a diff between two logs (with whitespace
> ignored) - first one is successful boot, second one is the failed boot
> (using systemd service):
>
> * https://paste.fedoraproject.org/156867/77223114/raw/
>
> And here are actual boot logs:
>
> * https://paste.fedoraproject.org/156862/17770249/ (from the service-file)
> * https://paste.fedoraproject.org/156862/17770249/ (using the command
> mentioned above)

Wrong last link, sorry. Here is a proper one:

* https://paste.fedoraproject.org/156894/79578141/ (using the command
mentioned above)

-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

[Tom Gundersen]

On 5 Dec 2014 10:07, "Marcel Holtmann"  wrote:
>
> Hi Lennart,
>
>  Moreover, if we
>  give people this feature I'm pretty sure we'll get lots of people
>  expecting it to work also for any other sort of name and getting
>  confused when it doesn't.
> >>>
> >>> Well, this is something we can fix by documentation, no?
> >>>
> >>> Or maybe name the match option differently, maybe OriginalName= or
> >>> KernelName= or so, and then only matching interfaces where you know
> >>> that the name was selected by userspace in the first place?
> >>
> >> I like the idea of OriginalName, much less likely to get people
> >> confused. I now implemented that, with the restriction that we cannot
> >> match on renamed names. For now I left it open to match on ethX style
> >> names, as people in principle could do sensible things like
> >> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
> >> only one interface.
> >>
> >> One thing to consider would be to disallow renaming from a .link file
> >> where the OriginalName was used to match. That way we don't have the
> >> somewhat odd situation that a .link file can only be applied once (we
> >> do not remember the original name, so cannot match on that the second
> >> time around, as that would be a mess)...
> >
> > Maybe we should even store the original name in a udev property, so
> > that we can make this fully idempotent simply because we can always
> > check this new property for the original name passed down from the
> > kernel?
>
> you do realize that once the kernel renamed the name, it is free to reuse
that name again. So eth0 as OriginalName can then be present multiple times.
>
> I think that you can only have OriginalName matching if a renaming has
never occurred. Otherwise this is really not deterministic. Since foo0
(renamed from eth0) and and bar0 (renamed from eth0) will both match
OriginalName=eth0. The difference is only timing and that is inhering racy
of course.

Well, matching on kernel names is not sane, and I put a warning in the
manpage.

The reason I left it in was that you could match on eth0 of you know it is
the only ethX device on your system, or you could match on eth* which would
also be  deterministic.

Cheers,

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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

[Harald Hoyer]

On 05.12.2014 08:20, Andrei Borzenkov wrote:
> В Thu, 04 Dec 2014 18:24:11 +0100
> Harald Hoyer  пишет:
> 
>> On 04.12.2014 18:19, Andrei Borzenkov wrote:
>>> В Thu, 04 Dec 2014 15:14:00 +0100
>>> Harald Hoyer  пишет:
>>>
 On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
>> From: Harald Hoyer 
>>
>> If ID_FS_TYPE of a parent is already set,
>> then it's something like "linux_raid_member" or "mpath_member"
>> and the disk is already in use, so don't handle the partitions
> Is this trying to fix an existing problem?

 yes, for "mpath_member" disk partitions, we should never ever advertise the
 /dev/disk/by* symlinks or set SYSTEMD_READY for it.
>>>
>>> How is it going to work? I mean, first we get device, then it is
>>> processed by multipathd. At the time rules are processed by udev, we
>>> have no idea whether it will be added to mpath later.
>>
>> For the disk, we should/must the flag set immediately in 62-multipath.rules.
>>
> 
> OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to
> "none", but the effect should be the same. I do not see this rule in
> multipath-tools ... should not it be unified across distros?

Yeah, should be ...

Upstream does not even ship a rule, which sets ID_FS_TYPE.

I don't know why we have 100 patches in Fedora rawhide on
top of upstream for the multipath tools.

Seems like nobody is pushing patches upstream, or upstream is not accepting any.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Didier Roche]

Le 05/12/2014 02:13, Lennart Poettering a écrit :

On Tue, 02.12.14 12:50, Didier Roche (didro...@ubuntu.com) wrote:


Just to sum up other branches of this thread: we are trying to avoid having
systemctl calls in debian/ubuntu postinst (or duplicated manual symlinks
logic as we currently have).
systemctl preset seems the cleanest path, but we want to ensure corner cases
can be handled.

d/u policy is to enable newly installed package by default (difference from
other distributions)

Le 02/12/2014 01:59, Lennart Poettering a écrit :

I don't think we should have systemctl preset  running under
any condition as a wipe of /etc and then "systemctl preset-all" would give a
potential different result (I'm not even sure how this will work with those
alias, the first matching the alias wins and get the symlinks?)

Dont follow? "wipe"?

I meant deleting the entire "/etc" content (or I guess as you told using
systemctl preset-all to reset to default):

1. lightdm and gdm were installed on my system.
2. gdm was enabled as the default display-manager.
3. I then use "systemctl preset-all"
-> how the behavior of selecting the display-manager will be determined? See
below implementing this with presets where enabling all services is the
default.

Hmm, this is actually undefined currently. THe code for preset-all
iterates through the unit paths and processes the files in the order
they are read by readdir(), which is pretty much undefined. We really
should investigate what to do about that. Probably just order things
lexicographically. I added this to the TODO list for now.


See my suggestion below.




So we need for any services shipping Aliases to have a preset list per
flavor (if their behaviors differs) with:
99-ubuntu-desktop.preset:
enable lightdm.service
disable kdm.service
disable gdm.service
disable nodm.service
(and whatnot… dm files in distro)

Hmm, indeed I guess...


Then, we would have 01-ubuntu-gnome.preset:
enable gdm.service
disable lightdm.service
disable kdm.service
…

It seems maintaining this list in sync for all flavors would be a growing
pain (this is a positive effect of the disable by default: you don't have to
maintain such a list), or do you think we can come with something
better?

Hmm, yuck. No good suggestion. I figure this problem doesn't exist
with the fedora default of everything is disabled by default...

All open to ideas...


Can we maybe extend the preset dictionary by having an alias (or 
alias-default) keyword taking a pair of arguments, like:

alias display-manager.service lightdm.service

Then, the preset command, for each alias, will stop at the first one it 
encounters. If the service doesn't exist, it's a noop, if it's there, it 
enables (--force in case something else was enabled for that Alias?) 
lightdm.service. It means of course that lightdm.service should contain:

[Install]
Alias=display-manager.service

or preset would then generates a warning.





Finally, on the "know what the administrator did on this machine", here are
two cases that we can identify:

I. if the administrator removes the service package, we usually keep current
service state (enabled/disabled) on reinstall.
So:
 enabled by default
1. systemctl disable foo.service
2. apt-get remove foo
3. apt-get install foo
-> foo should still be disabled. However, that won't be the case as on
reinstall, systemctl preset will re-enable the service as of the preset
policy.
Indeed, we don't have any record that the admin disabled it compared default
distro policy as there is no difference between: "no previous installation
state" and "service being disabled state" (no symlink).

Yeah, not sure how you can provide that with the scheme we devised
there in systemd. Sorry!

All ears for ideas...


So, I think we should really be able to fix case I.

I mean, you can fix case I, by explicitly storing the state away
before you remove a package.


Or storing only the previous *default* state?
Then, we can have a trigger updating that previous distro state 
(combining services installed and default preset) everytime we 
install/update a package containing a preset file or a an unit file?




How does this all precisely work on  on ?


Most of them shipped a conffile like /etc/default/ file 
with an ENABLED=true/false keyword. This doesn't really map in the 
systemd world (repetition of enablement/disablement states)

* "apt-get remove" keeps conffiles
* "apt-get remove --purge" deletes them.
* When an upgrade occurs:
  - if the package conffile didn't change -> kept with the 
modifications if any
  - if the package conffile did change -> infamous debconf prompt about 
"a maintainer configuration file changes, do you want to apply 
maintainer changes/keep as it is/see the diff…"


That's how all those use cases are handled on sysvinit.
Of course, we could introduce that back with ExecStartPre=`grep …` but 
well, 2 places (systemd symlinks + a /etc/default/ file) to decide one 
thing isn't really appealing nor wanted :)

Re: [systemd-devel] systemd-nspawn@.service is unusable

[Peter Lemenkov]

2014-12-05 4:43 GMT+03:00 Lennart Poettering :
> On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote:
>
>> Hello All!
>>
>> I'm playing with systemd-nspawn@.service and cannot make it work. It
>> seems that similar issues were discussed (and addressed upstream) in
>> Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
>> believe I've hit by something else.
>>
>> What I've done so far:
>>
>> * Ensured that /var/lib/container exists
>> * Created both  /var/log/journal/ and
>> /var/lib/container//var/log/journal/
>> * Ensured that Storage=persistent is set in
>> /var/lib/container//etc/systemd/journald.conf
>>
>> Every my attempt to run "systemctl status
>> systemd-nspawn@" ended up like this:
>>
>> https://paste.fedoraproject.org/156640/14177088/
>>
>> Please note that systemd-journald fails so I can't find out what's
>> going on there. I'm stuck right here. Some other services failed as
>> well, and I can't login using "machinectl login" but that's another
>> story I believe.
>>
>> Any advice on how to debug this and make
>> systemd-nspawn@ usable are highly appreciate!
>
> What happens if you run the same nspawn command from the command line?
> Does journald then start up correctly in it?

Yes, it works perfectly fine if I run it as

$ sudo /usr/bin/systemd-nspawn  --keep-unit --boot
--directory=/var/lib/container/earlyannounce

I can login and see logs. Unfortunately no logs from the previous boot
are available (due to failed systemd-journald.service).

> What happens if you add "debug" to the end of the nspawn cmdline? Do
> you see anything interesting in the additional log output this
> generates?

Can't say for sure. Here is a diff between two logs (with whitespace
ignored) - first one is successful boot, second one is the failed boot
(using systemd service):

* https://paste.fedoraproject.org/156867/77223114/raw/

And here are actual boot logs:

* https://paste.fedoraproject.org/156862/17770249/ (from the service-file)
* https://paste.fedoraproject.org/156862/17770249/ (using the command
mentioned above)
-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

[Marcel Holtmann]

Hi Lennart,

 Moreover, if we
 give people this feature I'm pretty sure we'll get lots of people
 expecting it to work also for any other sort of name and getting
 confused when it doesn't.
>>> 
>>> Well, this is something we can fix by documentation, no?
>>> 
>>> Or maybe name the match option differently, maybe OriginalName= or
>>> KernelName= or so, and then only matching interfaces where you know
>>> that the name was selected by userspace in the first place?
>> 
>> I like the idea of OriginalName, much less likely to get people
>> confused. I now implemented that, with the restriction that we cannot
>> match on renamed names. For now I left it open to match on ethX style
>> names, as people in principle could do sensible things like
>> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
>> only one interface.
>> 
>> One thing to consider would be to disallow renaming from a .link file
>> where the OriginalName was used to match. That way we don't have the
>> somewhat odd situation that a .link file can only be applied once (we
>> do not remember the original name, so cannot match on that the second
>> time around, as that would be a mess)...
> 
> Maybe we should even store the original name in a udev property, so
> that we can make this fully idempotent simply because we can always
> check this new property for the original name passed down from the
> kernel?

you do realize that once the kernel renamed the name, it is free to reuse that 
name again. So eth0 as OriginalName can then be present multiple times.

I think that you can only have OriginalName matching if a renaming has never 
occurred. Otherwise this is really not deterministic. Since foo0 (renamed from 
eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The 
difference is only timing and that is inhering racy of course.

Regards

Marcel

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

Re: [systemd-devel] shutdown

[Tom Deblauwe]

On 12/04/2014 04:26 PM, Lennart Poettering wrote:

On Fri, 31.10.14 18:50, Tom Deblauwe (deblauwe...@gmail.com) wrote:

Hmm, this smells like 4b5d8d0f22ae61ceb45a25391354ba53b43ee992 might
fix your issue? Could you verify that this is the issue you are
running into?



Hello,

Thanks for the reply.

I am using buildroot with systemd and after searching and trying out 
many things, I decided to just override the systemd-shutdown.service and 
systemd-reboot.service by changing in both cases the "ExecStart=" line 
to this:


ExecStart=/sbin/reboot -f

and

ExecStart=/sbin/poweroff -f

And this works for me.

So I was searching for some hanging jobs, but it turned out no jobs were 
hanging and it was just the shutdown that didn't work ok.


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