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

[Andrei Borzenkov]

В Tue, 2 Dec 2014 01:46:16 +0100
Lennart Poettering  пишет:

> On Tue, 18.11.14 14:37, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > > We now have:
> > > 
> > > enabeld - [Install] section and symlink in /etc/**/*.wants.d/
> > > disabled - [Install] section and no symlink in /etc/**/*.wants.d/
> > > static - no [Install] section and symlink in /usr/lib/**/*.wants.d/
> > > masked - symlink from the unit file-name to /dev/null in /etc
> > > 
> > > you want in addition:
> > > 
> > > preset (or something like that) - [Install] section and symlink in
> > > /usr/lib/**/*.wants.d/
> 
> I am not totally opposed to allowing /dev/null symlinks in .wants.d/
> subdirs, and considering them a way to override dependencies. Such a
> "mask a dependency" concept would be OK.
> 
> > I'd call this just "enabled". It follows the same "/etc/ trumps /usr"
> > schema that we have for udev rules, units, etc., i. e. an "enabled"
> > symlink should be allowed to live in /etc, /usr, and maybe even /run
> > (haven't though about whether this really makes sense, but perhaps for
> > full consistency it should be allowed).
> 
> OK, let me get this right. You want an algorithm like this when
> somebody invokes "systemctl enable":
> 
> a) if the unit file contains [Install], execute that, done
> b) if the unit file does not contain [Install], then delete any
>/dev/null symlinks in /etc/systemd/*.{wants,requires}.d/* of the
>same name.
> 
> Then, "systemctl disable" should do this in your opinion:
> 
> a) if the unit file contains [Install] remove all symlinks in
>/etc/systemd/*.{wants,requires}.d/* to it.
> b) if it doesn't, then *add* new symlinks to /dev/null in all
>.{wants,requires}.d/ directories where symlinks exist for it in
>/usr?
> 
> Did I get this right?
> 

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.

> I am not convinced this is really a good idea though, as with this
> scheme package changes might reenable a unit that is otherwise
> disabled. Also, I kind like the fact that there's currently a clean
> error message generated when people try to disable a unit that is part
> of the OS itself. The scheme you propose would degrade that case to a
> NOP however, right?
> 
> Lennart
> 

___
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

[Andrei Borzenkov]

В Fri, 5 Dec 2014 02:39:09 +0100
Lennart Poettering  пишет:

> 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:
> > > 
> > > > 2014-11-18 15:59 GMT+01:00 Colin Guthrie :
> > > > > For the avoidance of doubt, I believe that running systemctl preset
> > > > > should only ever happen on *first* install, never on upgrade or such 
> > > > > like.
> > > > >
> > > > 
> > > > And what are you going to do, if the unit file changes?
> > > > Say v1  had
> > > > 
> > > > [Install]
> > > > 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?
> 

That's one of the problems today - there is no way to distinguish
between "unit was not enabled due to previous defaults" and "unit was
disabled explicitly by admin". Although I'm afraid even this does not
really solve the issue as it leaves the case of "it was disabled by
default and admin was OK with it" out.

The idea of having default enabled/disabled state in /usr/lib and
letting admin override it in /etc allows to partially solve it while
making packaging really easy - changes to default unit states would
simply mean changing shipped files that is already handled right.
___
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

[Andrei Borzenkov]

В 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?

> The partitions are processed later and IMPORT ID_FS_TYPE from the parent, just
> one line above my suggested rule.
> 

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

Re: [systemd-devel] systemd-networkd & DHCPv6 Prefix Delegation

[Anthony Messina]

On Thursday, December 04, 2014 03:32:22 PM Patrik Flykt wrote:
> On Thu, 2014-12-04 at 03:27 +0100, Tom Gundersen wrote:
> > Patrik, do you have any plans for this? I agree, this is likely
> > something we want.
> 
> I'm tempted to do something about it. Give me time until mid next week
> and we'll see what happens.

Thanks. -A

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E


signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Marineau]

On Thu, Dec 4, 2014 at 5:50 PM, Lennart Poettering
 wrote:
> On Tue, 02.12.14 09:40, Michael Marineau (michael.marin...@coreos.com) wrote:
>
>> I didn't catch this behavior when it was first introduced since
>> originally it was much harder to trigger systemd's "empty /etc" logic
>> but now that it only requires /etc/machine-id to be missing it is
>> quite easy, booting a new instance from an image for example. By
>> default applying presets enables everything unless there is a preset
>> config that defines otherwise. I found this to be rather surprising,
>> booting a fresh machine reported all sorts of failures by trying to
>> start oodles of unconfigured services.
>
> Those services should not be listed as "enable" in the preset file if
> they fail to start unless explicitly configured.

They aren't listed, that's why I'm asking about the default. :)

>
>> Also the options are only "enable" and "disable" so the existing
>> pattern of pre-preconfiguring a reference host and then creating an
>> image (EC2 AMIs for example) won't work very well since the preset
>> defaults will clobber what the user enabled/disabled. (assuming the
>> user properly clears machine-id before creating the image which may
>> be rare, in all likelihood many people just get away with having
>> non-unique machine ids)
>
> 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'?

>
>> 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?

>
>> Is there a particular reason for the existing behavior? Would
>> switching the default to disable be reasonable or should the automatic
>> at boot mode gain a third "do nothing" option? Not sure where the
>> safest and least-surprising behavior lies while continuing to provide
>> this preset functionality.
>>
>> Personally I've always found the enable/disable terminology to be
>> incredibly misleading to begin with since it only refers to
>> configuration in /etc and units can be equally activated in /usr. If
>> disable and mask were equivalent then the distro's "presets" would
>> just be whatever is in /usr and there won't be a need for this extra
>> preset mechanism to initialize /etc.
>
> We have the "static" state for units that are statically on via /usr,
> and hence aren't subject to "systemctl enable" and "systemctl
> disable".
>
> 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] preset enables everything by default

[Lennart Poettering]

On Tue, 02.12.14 09:40, Michael Marineau (michael.marin...@coreos.com) wrote:

> I didn't catch this behavior when it was first introduced since
> originally it was much harder to trigger systemd's "empty /etc" logic
> but now that it only requires /etc/machine-id to be missing it is
> quite easy, booting a new instance from an image for example. By
> default applying presets enables everything unless there is a preset
> config that defines otherwise. I found this to be rather surprising,
> booting a fresh machine reported all sorts of failures by trying to
> start oodles of unconfigured services. 

Those services should not be listed as "enable" in the preset file if
they fail to start unless explicitly configured.

> Also the options are only "enable" and "disable" so the existing
> pattern of pre-preconfiguring a reference host and then creating an
> image (EC2 AMIs for example) won't work very well since the preset
> defaults will clobber what the user enabled/disabled. (assuming the
> user properly clears machine-id before creating the image which may
> be rare, in all likelihood many people just get away with having
> non-unique machine ids)

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).

> 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.

> Is there a particular reason for the existing behavior? Would
> switching the default to disable be reasonable or should the automatic
> at boot mode gain a third "do nothing" option? Not sure where the
> safest and least-surprising behavior lies while continuing to provide
> this preset functionality.
> 
> Personally I've always found the enable/disable terminology to be
> incredibly misleading to begin with since it only refers to
> configuration in /etc and units can be equally activated in /usr. If
> disable and mask were equivalent then the distro's "presets" would
> just be whatever is in /usr and there won't be a need for this extra
> preset mechanism to initialize /etc.

We have the "static" state for units that are statically on via /usr,
and hence aren't subject to "systemctl enable" and "systemctl
disable".

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 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.

Normally journald would log its own problems to kmsg. However that's
difficult inside a container...

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] /usr vs /etc for default distro units enablement

[Lennart Poettering]

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:
> > 
> > > 2014-11-18 15:59 GMT+01:00 Colin Guthrie :
> > > > For the avoidance of doubt, I believe that running systemctl preset
> > > > should only ever happen on *first* install, never on upgrade or such 
> > > > like.
> > > >
> > > 
> > > And what are you going to do, if the unit file changes?
> > > Say v1  had
> > > 
> > > [Install]
> > > 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?

I am pretty sure the latter. 

I mean, of course, you can play games and try to guess if sendmail was
off when the upgrade took place simply because that used to be the
default, or because the user/admin really didn't want it to run, which
just accidentally happened to be the default. You have a 50/50 chance
to win this guess, which makes the excercise quite moot I'd say.

I'd really be conservative here: optional things that change their
default should be left as is on updates.

Of course, if something starts to be a necessity that wasn't one
strictly necessary then one should do something about this, but
usually in that case this would be a move from "systemctl enable"
units towards statically enabled ones anyway. But again: if something
was optional before, and is optional after, then be conservative,
don't change things...

> > I mean, let's not forget that admins should be able to define their
> > own targets and then enabled units in them and disable them
> > elsewhere. Package upgrades should not manipulate that. The first
> > installation of a package should enable a unit if that's what the
> > preset policy says, but from that point on the configuration is admin
> > configuration and not be changed anymore automatically.
> 
> It's theoretically possible that the admin could have moved it to a
> different target, but that's the exception. The system should still
> sanely handle the normal case where the admin has changed nothing, and
> in that case leaving the unit in its original target is completely
> wrong.
> 
> For example, if you move a unit from sysinit.target to multi-user.target
> and remove "DefaultDependencies=no" from the .service file, then leaving
> the installed symlink for sysinit.target will cause a dependency
> loop.

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.

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] /usr vs /etc for default distro units enablement

[Lennart Poettering]

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 :
> >On Fri, 28.11.14 11:15, Didier Roche (didro...@ubuntu.com) wrote:
> >
> >>The distribution comes preinstalled with one dm, enable * -> enable it, have
> >>the Alias=display-manager.service picking the right one.
> >>However, let's say the user installed then another dm, what happens? Both
> >>will be enabled if we systemctl preset  (as the discussion was
> >>to remove our debian enable  that was conditioned on the
> >>postinst).
> >"systemctl preset" will fail if there are already conflicting
> >symlinks. Hence the first installed DM wins, the second loses.
> 
> Ok, that works with the initial install case then.
> However, if lightdm is installed and the admin install gdm, he will get a
> prompt (from postinst) asking him which dm to choose. How would you handle
> that (without messing manually with the symlinks or systemctl enable --force
> in the postinst?). Writing new presets in /etc which enables the chosen dm
> and disable other, then reloading preset file to reset that
> display-manager.service alias?

Hmm, I am pretty sure interactive updates are a bad idea. But then
again, I know that Debian likes them.

I think, if you install something new that conflicts with something
installed, then you should enable it if the policy says so and if the
existing package isn't enabled already. But if it is already enabled,
or if the policy says no, then leave it alone.

If you really want an UI in the mix here, I'd recommend just altering
the symlinks directly. (I mean, altering the symlinks manually is
completely OK. systemctl enable/disable/preset is simply supposed to
be a nicer helper there, but in no way should be the exclusive way to
access them).

> >>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.

> >>We can of course have an ubuntu-desktop.preset which disables all dms by
> >>lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
> >>having those settings conflicting with each other), but it's seems that for
> >>every aliases, we need to maintain such a list (as we enable * by
> >>default)?
> >Not following here. Different flavours of Ubuntu should probably just
> >ship different preset files. (Or well, the main ubuntu should ship one
> >that enables lightdm, and then the gnome flavour ship another preset
> >file, with a lower name, tht overrides the lightdm line, and enables
> >gdm instead).
> 
> You meant disable, right? As our default is to enable all services.

Yeah, "overrides" meant disabling.

> 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...

> 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 kee

Re: [systemd-devel] Luks + lvm in initrd

[Luca Bruno]

Thanks for your answer. Turns out this problem is not really about LVM.
I've described the more general problem here:
https://bugs.freedesktop.org/show_bug.cgi?id=85746

I don't know if that's expected or not, but I'd like to have some clearings
if I'm doing something that I shouldn't do or not.

Also not sure if I explained the problem well, tell me if you need more
information.

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

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

[Lennart Poettering]

On Sun, 23.11.14 20:33, Chris Leech (cle...@redhat.com) wrote:

> This adds auto detection for iSCSI and some FCoE drivers and treats
> mounts to file-systems on those devices as remote-fs.

Hmm, I am not too fond of having such subsystem-specific complexity in
systemd. 

Hmm, isn't this something that could be fixed in the kernel in a
generic way? Introduce a new generic sysfs attr in a block device that
indicates that some block device involves networking? Similar to the
"rotational" flag?

I mean, I am not convinced that systemd should be the place where this
is abstracted, I'd much rather see the kernel do this for us, and us
simply making use of the information. 

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 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Lennart Poettering]

On Mon, 01.12.14 16:47, Karel Zak (k...@redhat.com) wrote:

> On Mon, Dec 01, 2014 at 02:28:33PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > Wouldn't be enough to use Chris' iSCSI and FCoE auto detection?
> > Please see previous discussion... Detecting network might not be trivial
> > if the devices are layered and there's a network-requiring device somewhere
> > lower in the stack.
> 
>  Good point. (It would be possible to analyze whole stack by slave/holders
>  relations, but I agree it's too complex and probably too fragile.)
> 
> > > Anyway, if you still want to read userspace mount options than I can
> > > add something like:
> > > 
> > >  mnt_inotify_mtab_add_watch()
> > >  mnt_inotify_mtab_rm_watch()
> > >  mnt_inotify_mtab_changed()
> > > 
> > > to hide all the paths and private mtab/utab stuff.
> > Maybe something more like what journal client code does here:
> > 
> >  mnt_mtab_get_fd() -> epoll fd
> >  mnt_mtab_get_events() -> EPOLLIN|EPOLLPRI
> >  mnt_mtab_process() -> information what changed
> 
>  Hmm.. utab is optional and very often does not exist, and library
>  uses rename(2) to do atomic update of the file. This is reason why
>  Chris have used inotify for /run/mount directory (and Lennart asked
>  for inotify API). I have doubts you can use epoll to monitor 
>  directories, epoll is about I/O monitoring.

Well, what Zbigniew was suggesting is to hide the fact that inotify is
used away, and instead do that internally. I.e. provide three calls:
one that tells the user of this the fd to listen on, the second that
tells the user of this the poll events to listen on, and finally one
function to call when actually one of those poll events is triggred.

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?

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.

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 rebased 1/3] cryptsetup-generator: Split main() into more functions and use hasmaps

[Lennart Poettering]

On Tue, 02.12.14 18:49, Jan Janssen (medhe...@web.de) wrote:

Sorry for the long delay in reviewing these patches. Looks much better
than the chaotic code from before. Good work. Applied this one and the
two others. 

Thanks!

> ---
>  man/systemd-cryptsetup-generator.xml  |   9 +-
>  src/cryptsetup/cryptsetup-generator.c | 380 
> +-
>  2 files changed, 199 insertions(+), 190 deletions(-)
> 
> diff --git a/man/systemd-cryptsetup-generator.xml 
> b/man/systemd-cryptsetup-generator.xml
> index 3abb39d..ff94e88 100644
> --- a/man/systemd-cryptsetup-generator.xml
> +++ b/man/systemd-cryptsetup-generator.xml
> @@ -120,7 +120,7 @@
>  activate the specified device as part
>  of the boot process as if it was
>  listed in
> -/etc/fstab. This
> +/etc/crypttab. This
>  option may be specified more than once
>  in order to set up multiple
>  devices. rd.luks.uuid=
> @@ -130,9 +130,10 @@
>  honored by both the main system and
>  the initrd.
>  If /etc/crypttab contains entries with
> -the same UUID, then the options for this 
> entry
> -will be used.
> -If /etc/crypttab exists, only those 
> UUID
> +the same UUID, then the name, keyfile and 
> options
> +specified there will be used. Otherwise the 
> device
> +will have the name 
> luks-UUID.
> +If /etc/crypttab exists, only those 
> UUIDs
>  specified on the kernel command line
>  will be activated in the initrd or the real 
> root.
>  
> diff --git a/src/cryptsetup/cryptsetup-generator.c 
> b/src/cryptsetup/cryptsetup-generator.c
> index 45c23bb..c1581ef 100644
> --- a/src/cryptsetup/cryptsetup-generator.c
> +++ b/src/cryptsetup/cryptsetup-generator.c
> @@ -19,26 +19,34 @@
>along with systemd; If not, see .
>  ***/
>  
> -#include 
>  #include 
> +#include 
>  #include 
>  
> +#include "dropin.h"
> +#include "fileio.h"
> +#include "generator.h"
> +#include "hashmap.h"
>  #include "log.h"
> -#include "util.h"
> -#include "unit-name.h"
>  #include "mkdir.h"
> -#include "strv.h"
> -#include "fileio.h"
>  #include "path-util.h"
> -#include "dropin.h"
> -#include "generator.h"
> +#include "strv.h"
> +#include "unit-name.h"
> +#include "util.h"
> +
> +typedef struct crypto_device {
> +char *uuid;
> +char *options;
> +bool create;
> +} crypto_device;
>  
>  static const char *arg_dest = "/tmp";
>  static bool arg_enabled = true;
>  static bool arg_read_crypttab = true;
> -static char **arg_disks = NULL;
> -static char **arg_options = NULL;
> -static char *arg_keyfile = NULL;
> +static bool arg_whitelist = false;
> +static Hashmap *arg_disks = NULL;
> +static char *arg_default_options = NULL;
> +static char *arg_default_keyfile = NULL;
>  
>  static bool has_option(const char *haystack, const char *needle) {
>  const char *f = haystack;
> @@ -251,8 +259,54 @@ static int create_disk(
>  return 0;
>  }
>  
> +static void free_arg_disks(void) {
> +crypto_device *d;
> +
> +while ((d = hashmap_steal_first(arg_disks))) {
> +free(d->uuid);
> +free(d->options);
> +free(d);
> +}
> +
> +hashmap_free(arg_disks);
> +}
> +
> +static crypto_device *get_crypto_device(const char *uuid) {
> +int r;
> +crypto_device *d;
> +
> +assert(uuid);
> +
> +d = hashmap_get(arg_disks, uuid);
> +if (!d) {
> +d = new0(struct crypto_device, 1);
> +if (!d)
> +return NULL;
> +
> +d->create = false;
> +d->options = NULL;
> +
> +d->uuid = strdup(uuid);
> +if (!d->uuid) {
> +free(d);
> +return NULL;
> +}
> +
> +r = hashmap_put(arg_disks, d->uuid, d);
> +if (r < 0) {
> +free(d->uuid);
> +free(d);
> +return NULL;
> +}
> +}
> +
> +return d;
> +}
> +
>  static int parse_proc_cmdline_item(const char *key, const char *value) {
>  int r;
> +crypto_device *d;
> +_cleanup_free_ char *uuid = NULL, *uuid_value = NULL;
>  
>  if (STR_IN_SET(key, "luks", "rd.luks") && value) {
>  
> @@ -272,19 +326

Re: [systemd-devel] unit A is WantedBy unit B but unit B does not Want unit A?

[Lennart Poettering]

On Sat, 01.11.14 19:42, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> Sometimes device gets Wants on mount point; sometimes not. I do not
> really understand why. Also different mount units apparently behave
> differently - e.g. mnt.mount "forgets" its history. It almost looks like
> mnt.mount is destroyed after it is unmounted and t.mount not ...

fstab entries that do not have "noauto" set get such a dependency
implicitly.

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] Luks + lvm in initrd

[Lennart Poettering]

On Tue, 28.10.14 23:51, Luca Bruno (lethalma...@gmail.com) wrote:

> Hi, I'm going on with my work to have systemd in initrd on NixOS (using
> dracut is a little complicated at the moment).
> Everything works fine, I've ported luks and lvm and both work separately.
> However I'm hitting a problem when using luks and lvm on top of luks.

> Any hints on where the culprit can be? Same happens with lvmetad.

The systemd develeopers generally don't really know LVM. LVM does
weird things with udev rules, and we cannot really help with that I
fear. Please ask the LVM folks for help.

In general much of the problems with LVM stem from the fact that they
their udev support is optional, and you need to enable it both in the
initrd and the host to work correctly.

But anyway, I am sorry, but I doubt many people on systemd-devel will
be able to help you.

Sorry,

Lennart

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

Re: [systemd-devel] [PATCH v4] Bootchart: use /proc/pid/mountinfo for root bdev

[Lennart Poettering]

On Fri, 31.10.14 16:01, Timofey Titovets (nefelim...@gmail.com) wrote:

> 
> +void get_rootbdev(char *rootbdev) {
> +FILE *file = fopen("/proc/self/mountinfo", "r");
> +char mnt_point[PATH_MAX];
> +char mnt_source[PATH_MAX];
> +char t[256]; // Trash
> +while (file && strcmp(mnt_point, "/") && !feof(file)){
> +fscanf(file, "%s %s %s %s %s %s %s %s %s %s %s",
> +   t,t,t,t,
> +   mnt_point,  t,t,t,t,
> +   mnt_source, t);
> +}
> +if(!strcmp(mnt_point, "/"))
> +strncpy(rootbdev, &mnt_source[5], 3);
> +fclose(file);
> +}
> +

Umm, the error handling is missing. We don't invoke functions from
variable definitions. We do not allocate over-sized buffers on the
stack. Either we do it with the right size or with dyanmic memory. We
generally don't use strcmp() for simple equality checks, but
streq(). We use _cleanup_xyz_ to automatically free resources. Please
have a look at the CODING_STYLE document in the repository.

In general, I wouldn't consult mountinfo for this at all. Instead
stat() the root fs, then use udev_device_new_from_devnum() on the
returned st_dev, and read the device symlinks from that.

Lennart

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

Re: [systemd-devel] [PATCH v4 3/4] unit: add UnitMask enum and get unit scope(mask) api from property

[Lennart Poettering]

On Thu, 04.12.14 17:01, WaLyong Cho (walyong@samsung.com) wrote:

> On 12/04/2014 03:43 AM, Lennart Poettering wrote:
> > On Tue, 02.12.14 23:29, WaLyong Cho (walyong@samsung.com) wrote:
> > 
> > Hmm, what's the rationale for this? Can you elaborate?
> 
> As you already noticed(on the 4th mail), this hash table is used to find
> unit can have a given property. As you said on 4th mail, if we use a
> special option for timer then this will not be needed.
> This can be also used in systemctl set-property and we can detect given
> property is supported by that unit or not before sending dbus. But, in
> most of case, systemctl set-property is called by user command line. And
> they will know which unit support which property. So, maybe this is not
> much needed.
> If you feel messy, I will add --timer-property= option.

Yeah, I'd prefer to keep the logic for all this on the client side
simple, and make the server side figure things out. Hence I think
--timer-property= is a good solution.

Lennart

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

Re: [systemd-devel] networkd link state

[Lennart Poettering]

On Thu, 04.12.14 16:53, O Neill, David M (david.m.one...@intel.com) wrote:

> Jóhann/All,
> 
> If you could expand on how you solve the following:
> 
> Systemd-networkd is a single process and it reads its configuration
> from /etc/systemd/network.
>
> How do unit files, solve a single process managing multiple netdevs?
> 
> Taking a switch as a use case with 64 ports, a port could have quite
> a lot of configuration associated with it; in a file such as
> /etc/system/network/sw0p1.link (network/link).
>
> Are you suggesting we using symlinks like systemctl manages daemons
> on boot to solve the enable/disabled problem?

Note that .link files and .network can be applied to multiple devices
the same way. The [Match] section specifies to which set of devices
a file of this kind applies. Normally, if you have a system with 64
ports, and all should run the same configuraiton, you'd just put one
file in place and make it match all 64 ports.

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] Option "fail" mentioned in systemd.mount(5)

[Lennart Poettering]

On Fri, 05.12.14 00:20, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> Hi all,
> 
> The systemd.mount(5) man page mentions an inexistent mount option "fail" in 
> the
> following context:
> 
> nofail, fail
> With nofail this mount will be only wanted, not required, by the
> local-fs.target. This means that the boot will continue even if this
> mount point is not mounted successfully. Option fail has the opposite
> meaning and is the default.
> 
> Specifying the option "fail" in fstab produces following message in the log:
> 
> kernel: EXT4-fs (sdc1): Unrecognized mount option "fail" or missing value
> 
> So the man page contradicts actual behavior. Should this statement be removed,
> or what?

Indeed, neither util-linux nor actually our own code cares about the
"fail" option, and it is the default anyway.

I removed this now from the man page.

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] reacting to unit failures (OnFailure)

[Lennart Poettering]

On Thu, 04.12.14 16:17, Nekrasov, Alexander (alexander.nekra...@emc.com) wrote:

> If I may go back to RestartSec, this gives me an ability to sleep
> before attempting to restart. I could see where I might use that,
> but I also need another ability, which is to stop restarting a
> service if it keeps failing, and trigger OnFailure instead.

> Upstart has a respawn limit, something like 3 restarts in 180
> seconds, and if it still fails after that - the job goes to "failed"
> state and is left stopped. Can I do the same with SystemD?

Yes, see StartLimitInterval=, StartLimitBurst=

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] segfault in timesyncd

[Lennart Poettering]

On Thu, 06.11.14 16:32, Damien Robert (damien.olivier.rob...@gmail.com) wrote:

> Here are the logs:
> 
> Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization.
> Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server 
> 10.3.255.254:123 (10.3.255.254).
> Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply 
> from 10.3.255.254:123 (10.3.255.254).
> Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip 
> b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000]
> Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process 
> exited, code=killed, status=11/SEGV
> Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered 
> failed state.
> Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff 
> time, scheduling restart.
> 
> I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep'
> does produce one:
> Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user 
> 100
> 0 dumped core.
> And my systemd/system.conf does not have a DefaultLimitCORE, and indeed
> $ systemctl show systemd-timesyncd | grep LimitCORE
> LimitCORE=18446744073709551615

Hmm, so, by default we leave the RLIMIT_CORE setting unmodified how we
got it from the kernel. This is the right choice usually, if you use
systemd-coredump to collect the coredumps of the system, since that is
actually not affected by the resource limit. The resource limit only
applies to core dumps stored to disk.

You can change the system-wide default for RLIMIT_CORE in
system.conf. However, I'd instead suggest to make use of
systemd-coredump instead.

Thanks!

Lennart

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

[systemd-devel] Option "fail" mentioned in systemd.mount(5)

[Ivan Shapovalov]

Hi all,

The systemd.mount(5) man page mentions an inexistent mount option "fail" in the
following context:

nofail, fail
With nofail this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if this
mount point is not mounted successfully. Option fail has the opposite
meaning and is the default.

Specifying the option "fail" in fstab produces following message in the log:

kernel: EXT4-fs (sdc1): Unrecognized mount option "fail" or missing value

So the man page contradicts actual behavior. Should this statement be removed,
or what?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] reacting to unit failures (OnFailure)

[Nekrasov, Alexander]

If I may go back to RestartSec, this gives me an ability to sleep before 
attempting to restart. I could see where I might use that, but I also need 
another ability, which is to stop restarting a service if it keeps failing, and 
trigger OnFailure instead. 

Upstart has a respawn limit, something like 3 restarts in 180 seconds, and if 
it still fails after that - the job goes to "failed" state and is left stopped. 
Can I do the same with SystemD?


> -Original Message-
> From: "Jóhann B. Guðmundsson" [mailto:johan...@gmail.com]
> Sent: Tuesday, December 02, 2014 10:28 AM
> To: Nekrasov, Alexander; systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] reacting to unit failures (OnFailure)
> 
> 
> On 12/02/2014 03:12 PM, Nekrasov, Alexander wrote:
> > Lennart just gave me a solution, thank you. I'll use templates
> >
> > I have a system where components at the "single node" level have
> dependencies and HA policies, such as "restart this many times within
> this interval, if still fails - run this action" where action is a
> sequence of commands. Components provide this information in their own
> language and I have to generate systemd configuration for them. It's
> more complex than just rebooting the node so I couldn't use
> FailureAction.
> 
> Right but you already have
> Restart=on-failure
> RestartSec=...
> 
> and the likes to restart the services in graceful HA manner ( and at the
> sametime allowing it to fail gracefully ) so what I was curious about
> what else you are doing in the background since it might lead to a worse
> situation in HA setup by doing so depending on the HA setup ( split
> brains etc you know the drill ).
> 
> JBG
___
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]

Thanks for the links William. Looks like most of that should be
covered by networkd. I now also added support for MTU and MACAddress
to be set in the .network files. The intention here is that if you
ever disable a network at runtime, we will revert to the default
(.link-defined) settings. However, runtime configuration is not yet
implemented, so for now the only distinction between setting this in a
.link and a .network is that you can now match on the real ifname.

HTH,

Tom

On Thu, Dec 4, 2014 at 9:07 PM, William Kennington
 wrote:
> In regards to the OS and syntax, this is NixOS. NixOS uses its own
> expression language to configure the entire system, including the network
> stack. If a user wanted to configure their system's networking stack, they
> would modify the networking.* set of options in their
> /etc/nixos/configuration.nix. Currently this is done with a set of generated
> scripts run as systemd services with device based dependencies. Ideally this
> would be directly translated to networkd syntax.
>
> For example, a user might have this snippet as part of their config for
> statically configuring one of their ethernet interfaces:
>
> networking.interfaces."enp4s0" = {
>   macAddress = "de:ad:be:eef:ca:fe";
>   mtu = 9000;
>   ip4 = [
> { address = "10.0.0.2"; prefixLength = 24; }
> { address = "10.0.0.3"; prefixLength = 24; }
>   ];
> };
>
> For link configuration, we are currently generating a
> network-link-.service which sets the mac address and mtu using
> iproute2:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713
>
> The networking options are all defined in:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix
>
> Our current translator to networkd is:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix
>
>
> Of course, the problem with just using kernel names is that our use case
> assumes that the interface was already renamed by udev. Therefore, our
> matching must be based on the post-udev name if it is to be backward
> compatible. Ultimately it might be best to continue using our set of scripts
> coupled with udev generated systemd device units, given our use cases.
>
> On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen  wrote:
>>
>> On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
>>  wrote:
>> > On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
>> >
>> >> > I mean, most of the times .link files are
>> >> > used to choose the name depending on other fields, but I think in all
>> >> > cases where the name is chosen at creation time of an interface (like
>> >> > for example for veth links), it should be Ok to match links based on
>> >> > the name they already have?
>> >>
>> >> So this we could do (i.e., allow name matches if and only if the name
>> >> is set at creation time). Though, if the name is set at creation time,
>> >> shouldn't also all the other properties have been?
>> >
>> > In nspawn we create veth links, and I *really* *really* don't want to
>> > add tons of options there to set the MTU or suchlike. Setting these
>> > properties really should be done within networkd I think.
>> >
>> > I think it would be really useful if we could match on the container's
>> > veth links by name, so that a .link file for it could be equally
>> > expressive as the .network file already is.
>> >
>> >> 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)...
>>
>> Testing and feedback welcome. Does this solve your problem William?
>>
>> Cheers,
>>
>> Tom
>
>
___
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

[William Kennington]

In regards to the OS and syntax, this is NixOS. NixOS uses its own
expression language to configure the entire system, including the network
stack. If a user wanted to configure their system's networking stack, they
would modify the networking.* set of options in their
/etc/nixos/configuration.nix. Currently this is done with a set of
generated scripts run as systemd services with device based dependencies.
Ideally this would be directly translated to networkd syntax.

For example, a user might have this snippet as part of their config for
statically configuring one of their ethernet interfaces:

networking.interfaces."enp4s0" = {
  macAddress = "de:ad:be:eef:ca:fe";
  mtu = 9000;
  ip4 = [
{ address = "10.0.0.2"; prefixLength = 24; }
{ address = "10.0.0.3"; prefixLength = 24; }
  ];
};

For link configuration, we are currently generating a
network-link-.service which sets the mac address and mtu using
iproute2:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713

The networking options are all defined in:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix

Our current translator to networkd is:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix


Of course, the problem with just using kernel names is that our use case
assumes that the interface was already renamed by udev. Therefore, our
matching must be based on the post-udev name if it is to be backward
compatible. Ultimately it might be best to continue using our set of
scripts coupled with udev generated systemd device units, given our use
cases.

On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen  wrote:

> On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
>  wrote:
> > On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
> >
> >> > I mean, most of the times .link files are
> >> > used to choose the name depending on other fields, but I think in all
> >> > cases where the name is chosen at creation time of an interface (like
> >> > for example for veth links), it should be Ok to match links based on
> >> > the name they already have?
> >>
> >> So this we could do (i.e., allow name matches if and only if the name
> >> is set at creation time). Though, if the name is set at creation time,
> >> shouldn't also all the other properties have been?
> >
> > In nspawn we create veth links, and I *really* *really* don't want to
> > add tons of options there to set the MTU or suchlike. Setting these
> > properties really should be done within networkd I think.
> >
> > I think it would be really useful if we could match on the container's
> > veth links by name, so that a .link file for it could be equally
> > expressive as the .network file already is.
> >
> >> 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)...
>
> Testing and feedback welcome. Does this solve your problem William?
>
> Cheers,
>
> Tom
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] unit: ignore generated systemd-bootchart.service

[Lennart Poettering]

On Thu, 04.12.14 12:46, WaLyong Cho (walyong@samsung.com) wrote:

Applied! Thanks!

> ---
>  units/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/units/.gitignore b/units/.gitignore
> index e12d299..3613cee 100644
> --- a/units/.gitignore
> +++ b/units/.gitignore
> @@ -21,6 +21,7 @@
>  /systemd-ask-password-wall.service
>  /systemd-backlight@.service
>  /systemd-binfmt.service
> +/systemd-bootchart.service
>  /systemd-bus-proxyd@.service
>  /systemd-firstboot.service
>  /systemd-fsck-root.service
> -- 
> 1.9.3
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH] bus: fix null pointer dereference

[Lennart Poettering]

On Sun, 09.11.14 15:41, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:

> CID#1237620
> ---
>  src/libsystemd/sd-bus/bus-message.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/libsystemd/sd-bus/bus-message.c 
> b/src/libsystemd/sd-bus/bus-message.c
> index be36d9f..edadacf 100644
> --- a/src/libsystemd/sd-bus/bus-message.c
> +++ b/src/libsystemd/sd-bus/bus-message.c
> @@ -2048,6 +2048,7 @@ static int bus_message_close_variant(sd_bus_message *m, 
> struct bus_container *c)
>  
>  assert(m);
>  assert(c);
> +assert(c->signature);
>  
>  if (!BUS_MESSAGE_IS_GVARIANT(m))
>  return 0;
> @@ -2174,6 +2175,8 @@ _public_ int 
> sd_bus_message_close_container(sd_bus_message *m) {
>  if (c->enclosing != SD_BUS_TYPE_ARRAY)
>  if (c->signature && c->signature[c->index] != 0)
>  return -EINVAL;
> +if (!c->signature && c->enclosing == SD_BUS_TYPE_VARIANT)
> +return -EINVAL;
>  
>  m->n_containers--;

The letter check is really unnecessary, we don't need to fail in this
case. 

Note that when a container is being put together the signature is
known and initialized at the time the container is opened. Hence when
a container was successfully opened, we know that we can also close it
again with an initialized signature.

The only reason why we allow the signature to be NULL in most cases,
is that when no container is open, and we hence put together the
top-level message object, then we don't know the signature yet, and it
grows as elements are added.

It's a bit of a weird assymetry in that regard: containers know the
signature in advance, but the message itself grows the signature as we
go... 

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] [PATCHv2] core: send sigabrt on watchdog timeout to get the stacktrace

[Lennart Poettering]

On Tue, 28.10.14 15:34, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

Sorry for not reviewing this more quickly!

Patch looks great, wanted to apply it, but it unfortunately doesn't
apply anymore. Any chance you can rebase this? Will apply quickly
then!

Sorry for the delay,

Lennart

> if sigabrt doesn't do the job, follow regular shutdown
> routine, sigterm > sigkill.
> 
> Umut:
> - I have done basic testing with suppressing sigabrt,
>   suppressing both sigabrt & sigterm on client application.
> - Documentation needs to be updated. I wasn't sure if we
> should mention it in KillMode, KillSignal or WatchdogSec

Maybe in KillSignal= and briefly in WatchdogSec=? (given that they are
in different man pages, I think doing this in both places makes a ton
of 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 v10] tmpfiles, man: Add xattr support to tmpfiles

[Lennart Poettering]

On Thu, 04.12.14 10:32, Maciej Wereski (m.were...@partner.samsung.com) wrote:

> This patch makes it possible to set extended attributes on files created
> by tmpfiles. This can be especially used to set SMACK security labels on
> volatile files and directories.
> 
> It is done by adding new line of type "t". Such line should contain
> attributes in Argument field, using following format:

Looks good! Applied!

Thanks!

Lennart

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

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

[Tom Gundersen]

On Thu, Dec 4, 2014 at 8:08 PM, Lennart Poettering
 wrote:
> On Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:
>
>> >> 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?

We got into lots of issues in the past with trying to track the
renaming from userspace (which is why NET_NAME_RENAMED and friends now
are exposed from the kernel), so I'd rather not get back into that
game. The issue is that processes can (and do) rename interfaces
outside of udev's control (possibly before udev is running), and we'll
then be left with knowing that a device was renamed (as the kernel
tells us that much), but not from what. I'd really prefer to keep this
dead simple and either say (as now) that the config is only applied
once if you rename the device, or say that the name-matching config
cannot rename.

-t
___
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 Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:

> >> 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?

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] missing: define NET_NAME_UNKNOWN

[Tom Gundersen]

Thanks!

On Thu, Dec 4, 2014 at 7:27 PM, David Herrmann  wrote:
> Hi
>
> On Thu, Dec 4, 2014 at 7:12 PM, Colin Walters  wrote:
>> It's only exposed to userspace since
>>
>>   commit 685343fc3ba61a1f6eef361b786601123db16c28
>>   Author: Tom Gundersen 
>>   AuthorDate: Mon Jul 14 16:37:22 2014 +0200
>>   Commit: David S. Miller 
>>   CommitDate: Tue Jul 15 16:12:01 2014 -0700
>>
>> to the kernel.
>
> Weird, this doesn't apply here.. but I cannot figure out why. I merged
> it manually now (and moved the constant above the other NET_NAME
> defines).
>
> Applied! Thanks
> David
>
>> ---
>>  src/shared/missing.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/shared/missing.h b/src/shared/missing.h
>> index a56d265..aef232b 100644
>> --- a/src/shared/missing.h
>> +++ b/src/shared/missing.h
>> @@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
>>  #  define NET_NAME_RENAMED 4
>>  #endif
>>
>> +#ifndef NET_NAME_UNKNOWN
>> +#  define NET_NAME_UNKNOWN 0
>> +#endif
>> +
>>  #ifndef BPF_XOR
>>  #  define BPF_XOR 0xa0
>>  #endif
>> --
>> 1.8.3.1
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] missing: define NET_NAME_UNKNOWN

[David Herrmann]

Hi

On Thu, Dec 4, 2014 at 7:12 PM, Colin Walters  wrote:
> It's only exposed to userspace since
>
>   commit 685343fc3ba61a1f6eef361b786601123db16c28
>   Author: Tom Gundersen 
>   AuthorDate: Mon Jul 14 16:37:22 2014 +0200
>   Commit: David S. Miller 
>   CommitDate: Tue Jul 15 16:12:01 2014 -0700
>
> to the kernel.

Weird, this doesn't apply here.. but I cannot figure out why. I merged
it manually now (and moved the constant above the other NET_NAME
defines).

Applied! Thanks
David

> ---
>  src/shared/missing.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/shared/missing.h b/src/shared/missing.h
> index a56d265..aef232b 100644
> --- a/src/shared/missing.h
> +++ b/src/shared/missing.h
> @@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
>  #  define NET_NAME_RENAMED 4
>  #endif
>
> +#ifndef NET_NAME_UNKNOWN
> +#  define NET_NAME_UNKNOWN 0
> +#endif
> +
>  #ifndef BPF_XOR
>  #  define BPF_XOR 0xa0
>  #endif
> --
> 1.8.3.1
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] missing: define NET_NAME_UNKNOWN

[Colin Walters]

It's only exposed to userspace since

  commit 685343fc3ba61a1f6eef361b786601123db16c28
  Author: Tom Gundersen 
  AuthorDate: Mon Jul 14 16:37:22 2014 +0200
  Commit: David S. Miller 
  CommitDate: Tue Jul 15 16:12:01 2014 -0700

to the kernel.
---
 src/shared/missing.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/missing.h b/src/shared/missing.h
index a56d265..aef232b 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
 #  define NET_NAME_RENAMED 4
 #endif
 
+#ifndef NET_NAME_UNKNOWN
+#  define NET_NAME_UNKNOWN 0
+#endif
+
 #ifndef BPF_XOR
 #  define BPF_XOR 0xa0
 #endif
-- 
1.8.3.1

From 6568250e5ec1873b9b8df986fa07bd6e23ddf5a1 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Thu, 4 Dec 2014 13:11:03 -0500
Subject: [PATCH] missing: define NET_NAME_UNKNOWN

It's only exposed to userspace since

  commit 685343fc3ba61a1f6eef361b786601123db16c28
  Author: Tom Gundersen 
  AuthorDate: Mon Jul 14 16:37:22 2014 +0200
  Commit: David S. Miller 
  CommitDate: Tue Jul 15 16:12:01 2014 -0700

to the kernel.
---
 src/shared/missing.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/missing.h b/src/shared/missing.h
index a56d265..aef232b 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
 #  define NET_NAME_RENAMED 4
 #endif
 
+#ifndef NET_NAME_UNKNOWN
+#  define NET_NAME_UNKNOWN 0
+#endif
+
 #ifndef BPF_XOR
 #  define BPF_XOR 0xa0
 #endif
-- 
1.8.3.1

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

Re: [systemd-devel] mate desktop user service file

[arnaud gaboury]

On Thu, Dec 4, 2014 at 4:20 PM, arnaud gaboury  wrote:
>>
>> You seem to be using some mechanism for starting 'systemd --user' that
>> gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
>> started via a specific third-party implementation of a dbus.service for
>> the user bus, possibly from "user-session-units". If you use the part of
>> user-session-units that assumes a dbus-daemon will be launched, but not
>> the part that actually launches the dbus-daemon, then I'm afraid you get
>> to keep both pieces.
>>
>> Neither dbus nor systemd currently ships that dbus.service. When I
>> suggested adding one to dbus, Lennart asked me to use a different path
>> for the socket, then said he had no plans to support a non-kdbus user
>> bus at all ... so that feature request is on hold.
>> (https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)
>>
>> Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.
--
└─session-c2.scope
  ├─2908 login -- gabx
  ├─2911 -zsh
  ├─2929 /bin/sh /usr/bin/startx
  ├─2951 xinit /home/gabx/.xinitrc -- /etc/X11/xinit/xserverrc :0
vt1 -auth /tmp/serverauth.7yJtuNYzPM
  ├─2952 /usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth
/tmp/serverauth.7yJtuNYzPM vt1
  ├─2956 i3
  ├─2979 firefox-aurora
  ├─2980 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.2956
  ├─2982 urxvt
  ├─2985 caja --no-desktop
  ├─2987 urxvt
  ├─2996 i3status --config=~/.config/i3/i3status.conf
  ├─3011 dbus-launch --autolaunch=77f348a2b3fb429b85a5de751ea9175a
--binary-syntax --close-stderr

---

Culprit is localized : i3

Thank you again for all your explanations.
___
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 Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
 wrote:
> On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
>
>> > I mean, most of the times .link files are
>> > used to choose the name depending on other fields, but I think in all
>> > cases where the name is chosen at creation time of an interface (like
>> > for example for veth links), it should be Ok to match links based on
>> > the name they already have?
>>
>> So this we could do (i.e., allow name matches if and only if the name
>> is set at creation time). Though, if the name is set at creation time,
>> shouldn't also all the other properties have been?
>
> In nspawn we create veth links, and I *really* *really* don't want to
> add tons of options there to set the MTU or suchlike. Setting these
> properties really should be done within networkd I think.
>
> I think it would be really useful if we could match on the container's
> veth links by name, so that a .link file for it could be equally
> expressive as the .network file already is.
>
>> 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)...

Testing and feedback welcome. Does this solve your problem William?

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 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.

The partitions are processed later and IMPORT ID_FS_TYPE from the parent, just
one line above my suggested rule.

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

Re: [systemd-devel] networkd link state

[Jóhann B. Guðmundsson]

On 12/04/2014 04:36 PM, Brendan Hide wrote:

On 2014/12/04 17:54, "Jóhann B. Guðmundsson" wrote:


On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in 
systemd not handled by introducing a new enabled/disabled "flag"
I think the idea has some merit. But I also think a *new* flag isn't 
the right, especially since we already have flags that (mostly) 
achieve this already.


Also, config-wise, admins don't work with separate unit files for 
every network interface - we have .net{dev,work} files.


br0.netdev:
[NetDev]
Name=br0
Kind=dummy
#^ currently valid, though I don't know what the results would be.
#Kind=bridge

enp0s25.network:
[Match]
Name=enp0s25
[Network]
DHCP=none
#^ currently valid, though I don't know what the results would be.
#Bridge=br0

The problem with this is that it could still be configured, even if in 
a broken state, where the admin might want that it leave the device 
alone completely or disabled (as in `ip link set enp0s25 down`). This 
might also cause a lot of noise in the logs if the config "breakage" 
isn't static. Again, I haven't tested and I don't know what the actual 
results would be.


Alternatively:
By {en,dis}able, we usually simply adjust whether or not a file will 
be found in a location. For example, renaming the file would work to a 
degree:

mv /etc/systemd/network/enp0s25.network{,.disable}

The only problem I see with this strategy would be if you have 
multiple rulesets with wildcards. For example you have this .disabled 
config for enp0s25 but you also have a less-specific ruleset for en* 
in a second (non-disabled) config. That less-specific ruleset could 
enable the interface with an unwanted configuration.




To be consistent with construction of other type units we would have to 
introduce [Install] section and .network type units would have to be 
enabled/disabled ( most likely by create symlinks in network.target ) 
tjhen administrators simply run systemctl enable enp0s25.network or 
systemctl enable br0.netdev etc.


Tom probably has some insight why this route was not choicen to begin 
with in the overall design to handle enable/disable (if up/down ) of 
network devices?

___
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

[Andrei Borzenkov]

В 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.

> 
> > 
> > Zbyszek
> > 
> >> ---
> >>  rules/60-persistent-storage.rules | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/rules/60-persistent-storage.rules 
> >> b/rules/60-persistent-storage.rules
> >> index 475b151..836e053 100644
> >> --- a/rules/60-persistent-storage.rules
> >> +++ b/rules/60-persistent-storage.rules
> >> @@ -22,6 +22,11 @@ TEST=="whole_disk", GOTO="persistent_storage_end"
> >>  # for partitions import parent information
> >>  ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
> >>  
> >> +# 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
> >> +ENV{ID_FS_TYPE}=="?*", GOTO="persistent_storage_end"
> >> +
> >>  # virtio-blk
> >>  KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
> >> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
> >>  KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
> >> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
> >> -- 
> >> 2.1.0
> >>
> >> ___
> >> systemd-devel mailing list
> >> systemd-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

Re: [systemd-devel] networkd link state

[O Neill, David M]

Jóhann/All,

If you could expand on how you solve the following:

Systemd-networkd is a single process and it reads its configuration from 
/etc/systemd/network.
How do unit files, solve a single process managing multiple netdevs?

Taking a switch as a use case with 64 ports, a port could have quite a lot of 
configuration associated with it; in a file such as 
/etc/system/network/sw0p1.link (network/link).
Are you suggesting we using symlinks like systemctl  manages daemons on boot to 
solve the enable/disabled problem?

Thanks
Dave.

-Original Message-
From: O Neill, David M 
Sent: Thursday, December 4, 2014 4:06 PM
To: '"Jóhann B. Guðmundsson"'; systemd-devel@lists.freedesktop.org
Subject: RE: [systemd-devel] networkd link state

Thanks!

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of "Jóhann B. Guðmundsson"
Sent: Thursday, December 4, 2014 3:55 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] networkd link state


On 12/04/2014 03:47 PM, O Neill, David M wrote:
> What do you think?

I think this should be consisted with other unit enablement in systemd not 
handled by introducing a new enabled/disabled "flag"

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

Re: [systemd-devel] networkd link state

[Brendan Hide]

On 2014/12/04 17:54, "Jóhann B. Guðmundsson" wrote:


On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in systemd 
not handled by introducing a new enabled/disabled "flag"
I think the idea has some merit. But I also think a *new* flag isn't the 
right, especially since we already have flags that (mostly) achieve this 
already.


Also, config-wise, admins don't work with separate unit files for every 
network interface - we have .net{dev,work} files.


br0.netdev:
[NetDev]
Name=br0
Kind=dummy
#^ currently valid, though I don't know what the results would be.
#Kind=bridge

enp0s25.network:
[Match]
Name=enp0s25
[Network]
DHCP=none
#^ currently valid, though I don't know what the results would be.
#Bridge=br0

The problem with this is that it could still be configured, even if in a 
broken state, where the admin might want that it leave the device alone 
completely or disabled (as in `ip link set enp0s25 down`). This might 
also cause a lot of noise in the logs if the config "breakage" isn't 
static. Again, I haven't tested and I don't know what the actual results 
would be.


Alternatively:
By {en,dis}able, we usually simply adjust whether or not a file will be 
found in a location. For example, renaming the file would work to a degree:

mv /etc/systemd/network/enp0s25.network{,.disable}

The only problem I see with this strategy would be if you have multiple 
rulesets with wildcards. For example you have this .disabled config for 
enp0s25 but you also have a less-specific ruleset for en* in a second 
(non-disabled) config. That less-specific ruleset could enable the 
interface with an unwanted configuration.


--
__
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

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

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

[Peter Lemenkov]

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!


-- 
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 link state

[O Neill, David M]

Thanks!

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of "Jóhann B. Guðmundsson"
Sent: Thursday, December 4, 2014 3:55 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] networkd link state


On 12/04/2014 03:47 PM, O Neill, David M wrote:
> What do you think?

I think this should be consisted with other unit enablement in systemd not 
handled by introducing a new enabled/disabled "flag"

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

Re: [systemd-devel] networkd link state

[Jóhann B. Guðmundsson]

On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in systemd 
not handled by introducing a new enabled/disabled "flag"


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

[systemd-devel] networkd link state

[O Neill, David M]

Folks,

I would like to introduce a flag "enable=Boolean" in the networkd configuration 
files.
I am introducing new features that can create a large amount of configuration.

Deleting and restoring configuration can be quiet laborious
Renaming the files to another extension is possibly another option

This configuration will be under configuration management using tools such as 
chef/puppet/cfengine.

Typically net-tools/networkmanager etc has such a flag and existing in the 
ifcfg "onboot / enabled".
Switch technology has the ability to turn on and off the port without deleting 
the configuration also.

What do you think?

Thanks

--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

Re: [systemd-devel] shutdown

[Lennart Poettering]

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

> Hello,

Heya, sorry for the late reply. In case this is still open:

Which distribution is this?

> I'm using systemd, but can't seem to correctly shutdown. I have
> already:

What does "can't seem to correctly shutdown" mean? What precisely
fails? I assume it hangs somewhere? Where precisely?

> - checked: reboot -f works
> - enabled the debug-shell on vt9

When you shut down with "debug" on the kernel command line, is there
any indication where precisely it hangs? can you paste the last output 
somewhere?

> 
> So I was hoping to issue the "systemctl list-jobs" command from the debug
> shell, however, it didn't allow me to type in commands. The debug shell
> allows me to type something but it is as if the shell is not receiving that
> input. So I can't use the debug shell it seems.
> 
> So I decidec to execute "journalctl -x -f" while the sytem is running, and
> then do "reboot". So I only see it gets to log "Shutting down." but then
> nothing anymore.

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

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] mate desktop user service file

[arnaud gaboury]

>
> You seem to be using some mechanism for starting 'systemd --user' that
> gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
> started via a specific third-party implementation of a dbus.service for
> the user bus, possibly from "user-session-units". If you use the part of
> user-session-units that assumes a dbus-daemon will be launched, but not
> the part that actually launches the dbus-daemon, then I'm afraid you get
> to keep both pieces.
>
> Neither dbus nor systemd currently ships that dbus.service. When I
> suggested adding one to dbus, Lennart asked me to use a different path
> for the socket, then said he had no plans to support a non-kdbus user
> bus at all ... so that feature request is on hold.
> (https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)
>
> Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.
>
> autolaunch is a mechanism to start a dbus-daemon per (machine, X11
> display) pair when no dbus-daemon is running and an application tries to
> connect to D-Bus. It mostly works via X11 properties; the files in
> ~/.dbus are a fallback.

After carefully reading dbus-launch(1), I understand now the fall back
mechanism.

Fom man :


I have this drop-in config as recommanded by my distro (Archlinux) wiki[0]:

/etc/systemd/system/user@.service.d/dbus.conf
-
[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
---

I start systemd --user as described in wiki.

[0]https://wiki.archlinux.org/index.php/Systemd/User
___
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 Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:

> > I mean, most of the times .link files are
> > used to choose the name depending on other fields, but I think in all
> > cases where the name is chosen at creation time of an interface (like
> > for example for veth links), it should be Ok to match links based on
> > the name they already have?
> 
> So this we could do (i.e., allow name matches if and only if the name
> is set at creation time). Though, if the name is set at creation time,
> shouldn't also all the other properties have been? 

In nspawn we create veth links, and I *really* *really* don't want to
add tons of options there to set the MTU or suchlike. Setting these
properties really should be done within networkd I think.

I think it would be really useful if we could match on the container's
veth links by name, so that a .link file for it could be equally
expressive as the .network file already is.

> 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?

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] SIT tunnel does not work

[Tom Gundersen]

Hi Tomasz,

Sorry to dig up such an old thread, but I just made some changes to
the sit handling, and at least for me it works now. This is the config
I'm currently using:

wireless.network ---8<---

[Match]
Name=wlp3s0

[Network]
DHCP=yes
Tunnel=he

he.netdev ---8<-

[NetDev]
Name=he
Kind=sit

[Tunnel]
Remote=222.333.444.555
TTL=255

he.network ---8<-

[Match]
Name=he-ipv6

[Network]
Address=2001:470:11::2/64

[Route]
Gateway=2001:470:11::1
Source=2001:470:22::/48

[Route]
Gateway=2001:470:11::1
Source=2001:470:11::2/128

[Route]
Source=::/128

---8<-


(you probably don't need the source routing stuff, but that's what I
was testing).



Do you still see problems with this on your end with current git?

Cheers,

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

Re: [systemd-devel] systemd.netdev: Tunnel should support ANY addresses for Local option

[Tom Gundersen]

On Mon, Nov 24, 2014 at 8:38 PM, William Kennington
 wrote:
> Currently, networkd netdevs do not support tunnel devices which do not have
> a local address configured. This breaks the configuration of sit devices on
> my hosts which run dhcp for ipv4 configuration, which normally have local
> set to 0.0.0.0. Is there any chance we could remove the any check for the
> local endpoint address?

Done. Does this work for you as expected with current git?

Cheers,

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

Re: [systemd-devel] systemd-networkd & DHCPv6 Prefix Delegation

[Tom Gundersen]

On Thu, Dec 4, 2014 at 2:32 PM, Patrik Flykt
 wrote:
> On Thu, 2014-12-04 at 03:27 +0100, Tom Gundersen wrote:
>> Patrik, do you have any plans for this? I agree, this is likely
>> something we want.
>
> I'm tempted to do something about it. Give me time until mid next week
> and we'll see what happens.

Great! Thanks!

-t
___
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 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.

> 
> Zbyszek
> 
>> ---
>>  rules/60-persistent-storage.rules | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/rules/60-persistent-storage.rules 
>> b/rules/60-persistent-storage.rules
>> index 475b151..836e053 100644
>> --- a/rules/60-persistent-storage.rules
>> +++ b/rules/60-persistent-storage.rules
>> @@ -22,6 +22,11 @@ TEST=="whole_disk", GOTO="persistent_storage_end"
>>  # for partitions import parent information
>>  ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
>>  
>> +# 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
>> +ENV{ID_FS_TYPE}=="?*", GOTO="persistent_storage_end"
>> +
>>  # virtio-blk
>>  KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
>> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
>>  KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
>> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
>> -- 
>> 2.1.0
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

[Zbigniew Jędrzejewski-Szmek]

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?

Zbyszek

> ---
>  rules/60-persistent-storage.rules | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/rules/60-persistent-storage.rules 
> b/rules/60-persistent-storage.rules
> index 475b151..836e053 100644
> --- a/rules/60-persistent-storage.rules
> +++ b/rules/60-persistent-storage.rules
> @@ -22,6 +22,11 @@ TEST=="whole_disk", GOTO="persistent_storage_end"
>  # for partitions import parent information
>  ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
>  
> +# 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
> +ENV{ID_FS_TYPE}=="?*", GOTO="persistent_storage_end"
> +
>  # virtio-blk
>  KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
>  KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
> SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
> -- 
> 2.1.0
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd & DHCPv6 Prefix Delegation

[Patrik Flykt]

On Thu, 2014-12-04 at 03:27 +0100, Tom Gundersen wrote:
> Patrik, do you have any plans for this? I agree, this is likely
> something we want.

I'm tempted to do something about it. Give me time until mid next week
and we'll see what happens.

Cheers,

Patrik


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

Re: [systemd-devel] mate desktop user service file

[Simon McVittie]

On 04/12/14 08:56, arnaud gaboury wrote:
> -$DBUS_SESSION_BUS_ADDRESS
> For reasons I ignore (far from being a dbus expert), the
> $DBUS_SESSION_BUS_ADDRESS as returned by the
> $systemctl --user show-environment did not work for mate-settings-daemon.
...
> $systemctl --user show-environment returns
> DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket

You can ignore those reasons as much as you like, but ignoring them is
not going to make them go away.

You seem to be using some mechanism for starting 'systemd --user' that
gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
started via a specific third-party implementation of a dbus.service for
the user bus, possibly from "user-session-units". If you use the part of
user-session-units that assumes a dbus-daemon will be launched, but not
the part that actually launches the dbus-daemon, then I'm afraid you get
to keep both pieces.

Neither dbus nor systemd currently ships that dbus.service. When I
suggested adding one to dbus, Lennart asked me to use a different path
for the socket, then said he had no plans to support a non-kdbus user
bus at all ... so that feature request is on hold.
(https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)

Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.

> So adding 
> EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
> solved the issue.

FYI, 77f... is your D-Bus machine ID, found in /var/lib/dbus/machine-id
or /etc/machine-id.

> 154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
> --autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
> --close-stderr
> 
> Why this autolaunch ?

autolaunch is a mechanism to start a dbus-daemon per (machine, X11
display) pair when no dbus-daemon is running and an application tries to
connect to D-Bus. It mostly works via X11 properties; the files in
~/.dbus are a fallback.

If mate-settings-daemon can connect to X11 (a correct DISPLAY and
XAUTHORITY) and *does not* have DBUS_SESSION_BUS_ADDRESS in its
environment, it will use the autolaunch mechanism to get a bus.

Normally, Linux distributions and desktop environments also ensure that
a dbus-daemon is running for each X11 session. Since you seem to have
constructed your own desktop environment out of pieces, it's up to you
to decide how you launch your dbus-daemon and communicate its address to
the right places; autolaunch is the fallback mechanism for if you don't.

S

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

Re: [systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.

[Harald Hoyer]

On 22.09.2014 11:48, Maurizio Lombardi wrote:
> This patch changes the naming scheme for sas disks. The original names used
> disk's sas address and lun, the new scheme uses sas address of the
> nearest expander (if available) and a phy id of the used connection.
> If no expander is used, the phy id of hba phy is used.
> Note that names that refer to RAID or other abstract devices are
> unchanged.
> 
> Name in raid configuration:
> hba_pci_address-sas-raid_sas_address-lunY-partZ
> 
> Name in expander bare disk configuration:
> hba_pci_address-sas-expander_sas_address-phyX-lunY-partZ
> 
> Name format without expanders:
> hba_pci_address-sas-phyX-lunY-partZ
> 
> Signed-off-by: Maurizio Lombardi 


After convincing Kay Sievers, I am going to push this patch, as it fixes
obviously non-predictable symlinks.

To fix already released systemd versions, I would suggest to patch them in a
way, that it outputs both symlinks and add a release note, that the old
symlinks are deprecated.

In the long run, we really should outsource all specialized storage udev helper
code, as Kay mentioned in the various replies to this thread.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[harald]

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
---
 rules/60-persistent-storage.rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 475b151..836e053 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -22,6 +22,11 @@ TEST=="whole_disk", GOTO="persistent_storage_end"
 # for partitions import parent information
 ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
 
+# 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
+ENV{ID_FS_TYPE}=="?*", GOTO="persistent_storage_end"
+
 # virtio-blk
 KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
 KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
-- 
2.1.0

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

Re: [systemd-devel] mate desktop user service file

[arnaud gaboury]

> Just to mention, the default 1.8.1 mate, will autostart mate-setting-daemon
> according to
> its file in /etc/xdg/autostart/mate-settings-daemon.desktop:
> --
> [Desktop Entry]
> Type=Application
> Name=MATE Settings Daemon
> 
> Exec=/usr/lib/mate-settings-daemon/mate-settings-daemon
> OnlyShowIn=MATE;
> X-MATE-Autostart-Phase=Initialization
> X-MATE-Autostart-Notify=true
> X-MATE-AutoRestart=true
> --
>
> So the problem does not involve systemd at all...
>

I am NOT using mate, so the autostart is not starting. I use i3 wm and
Caja file manger. I only want to use mate-settings-daemon, nothing
else.
___
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 Thu, Dec 4, 2014 at 3:50 AM, Lennart Poettering
 wrote:
> Tom, I think it would make sense to allow Name= matches in the [Match]
> section of .link files, no?

Hm, so far I hesitated, as the most common scenarios is the one that
William has, namely to want to match on the name set by udev and not
the one set by the kernel. This we cannot really do in .link files as
it would be confusing for admins to figure out exactly what is being
matched on, and it could obviously become undecidable/nonterminating
depending on how we try to implement it.

> I mean, most of the times .link files are
> used to choose the name depending on other fields, but I think in all
> cases where the name is chosen at creation time of an interface (like
> for example for veth links), it should be Ok to match links based on
> the name they already have?

So this we could do (i.e., allow name matches if and only if the name
is set at creation time). Though, if the name is set at creation time,
shouldn't also all the other properties have been? 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.

So overall, not really convinced, but if there is a usecase for
matching on such limited types of names, I'm not very strongly against
it.

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

Re: [systemd-devel] [PATCH] networkd: Add bridge port path cost

[Tom Gundersen]

Applied. Thanks! (sorry for the delay)

On Sat, Nov 15, 2014 at 4:17 AM, Susant Sahani  wrote:
> This patch add support to specify path cost of the
> bridge port to be configured via conf file.
>
> Exampe: conf
>
> file: br.netdev
>
> [NetDev]
> Name=br-test
> Kind=bridge
>
> file: br.network
> [Match]
> Name=em1
>
> [Network]
> Bridge=br-test
>
> [BridgePort]
> Cost=332
>
>  bridge link
> 2: em1 state UP :  mtu 1500 master
> br-test state disabled priority 32 cost 332
> ---
>  man/systemd.network.xml  | 13 +
>  src/network/networkd-link.c  | 93 
> 
>  src/network/networkd-network-gperf.gperf |  1 +
>  src/network/networkd-network.c   |  2 +-
>  src/network/networkd.h   |  2 +
>  5 files changed, 110 insertions(+), 1 deletion(-)
>
> diff --git a/man/systemd.network.xml b/man/systemd.network.xml
> index 4cc13b2..c9c946c 100644
> --- a/man/systemd.network.xml
> +++ b/man/systemd.network.xml
> @@ -505,6 +505,19 @@
>  
>
>  
> +[BridgePort] Section Options
> +The [BridgePort] section 
> accepts the following keys.
> +
> +
> +Cost=
> +
> +  Each port in a bridge may 
> have different speed. Cost is used to decide which link to use. Faster 
> interfaces should have lower costs
> +
> +
> +
> +
> +
> +
>  Example
>  
>  /etc/systemd/network/50-static.network
> diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
> index 26ef0fe..dbc804b 100644
> --- a/src/network/networkd-link.c
> +++ b/src/network/networkd-link.c
> @@ -705,6 +705,27 @@ int link_address_drop_handler(sd_rtnl *rtnl, 
> sd_rtnl_message *m, void *userdata)
>  return 1;
>  }
>
> +static int link_set_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void 
> *userdata) {
> +_cleanup_link_unref_ Link *link = userdata;
> +int r;
> +
> +log_debug_link(link, "set link");
> +
> +r = sd_rtnl_message_get_errno(m);
> +if (r < 0 && r != -EEXIST) {
> +log_struct_link(LOG_ERR, link,
> +"MESSAGE=%-*s: could not join netdev: %s",
> +IFNAMSIZ,
> +link->ifname, strerror(-r),
> +"ERRNO=%d", -r,
> +NULL);
> +link_enter_failed(link);
> +return 1;
> +}
> +
> +return 0;
> +}
> +
>  static int set_hostname_handler(sd_bus *bus, sd_bus_message *m, void 
> *userdata,
>  sd_bus_error *ret_error) {
>  _cleanup_link_unref_ Link *link = userdata;
> @@ -826,6 +847,69 @@ int link_set_mtu(Link *link, uint32_t mtu) {
>  return 0;
>  }
>
> +static int link_set_bridge(Link *link) {
> +_cleanup_rtnl_message_unref_ sd_rtnl_message *req = NULL;
> +int r;
> +
> +assert(link);
> +assert(link->network);
> +
> +if(link->network->cost == 0)
> +return 0;
> +
> +r = sd_rtnl_message_new_link(link->manager->rtnl, &req,
> + RTM_SETLINK, link->ifindex);
> +if (r < 0) {
> +log_error_link(link, "Could not allocate RTM_SETLINK 
> message");
> +return r;
> +}
> +
> +r = sd_rtnl_message_link_set_family(req, PF_BRIDGE);
> +if (r < 0) {
> +log_error_link(link,
> +   "Could not set message family %s", 
> strerror(-r));
> +return r;
> +}
> +
> +r = sd_rtnl_message_open_container(req, IFLA_PROTINFO);
> +if (r < 0) {
> +log_error_link(link,
> +   "Could not append IFLA_PROTINFO attribute: 
> %s",
> +   strerror(-r));
> +return r;
> +}
> +
> +if(link->network->cost != 0) {
> +r = sd_rtnl_message_append_u32(req, IFLA_BRPORT_COST, 
> link->network->cost);
> +if (r < 0) {
> +log_error_link(link,
> +   "Could not append IFLA_BRPORT_COST 
> attribute: %s",
> +   strerror(-r));
> +return r;
> +}
> +}
> +
> +r = sd_rtnl_message_close_container(req);
> +if (r < 0) {
> +log_error_link(link,
> +   "Could not append IFLA_LINKINFO attribute: 
> %s",
> +   strerror(-r));
> +return r;
> +}
> +
> 

Re: [systemd-devel] [PATCH] networkd: support vxlan parameters

[Tom Gundersen]

Applied. Thanks!

On Sat, Nov 15, 2014 at 3:54 AM, Susant Sahani  wrote:
> V3: fix copy paste error
> V4: Make manual and config more readable
>
> Add vxlan paramertes to config.
> ---
>  man/systemd.netdev.xml  | 30 
>  src/network/networkd-netdev-gperf.gperf | 83 
> +
>  src/network/networkd-netdev-vxlan.c | 81 
>  src/network/networkd-netdev-vxlan.h | 10 
>  src/network/networkd.h  | 11 +
>  5 files changed, 176 insertions(+), 39 deletions(-)
>
> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
> index 275ee52..45934f2 100644
> --- a/man/systemd.netdev.xml
> +++ b/man/systemd.netdev.xml
> @@ -272,6 +272,36 @@
>  to discover remote MAC 
> addresses.
>  
>  
> +
> +
> FDBAgeingSec=
> +
> +The lifetime of 
> Forwarding Database entry learnt by the kernel in seconds.
> +
> +
> +
> +
> ARPProxy=
> +
> +A boolean. When true, 
> enables ARP proxy.
> +
> +
> +
> +
> L2MissNotification=
> +
> +A boolean. When true, 
> enables netlink LLADDR miss notifications.
> +
> +
> +
> +
> L3MissNotification=
> +
> +A boolean. When true, 
> enables netlink IP ADDR miss notifications.
> +
> +
> +
> +
> RouteShortCircuit=
> +
> +A boolean. When true 
> route short circuit is turned on.
> +
> +
>  
>  
>  
> diff --git a/src/network/networkd-netdev-gperf.gperf 
> b/src/network/networkd-netdev-gperf.gperf
> index c524ee5..b311ebe 100644
> --- a/src/network/networkd-netdev-gperf.gperf
> +++ b/src/network/networkd-netdev-gperf.gperf
> @@ -18,42 +18,47 @@ struct ConfigPerfItem;
>  %struct-type
>  %includes
>  %%
> -Match.Host,  config_parse_net_condition, CONDITION_HOST, 
>offsetof(NetDev, match_host)
> -Match.Virtualization,config_parse_net_condition, 
> CONDITION_VIRTUALIZATION,  offsetof(NetDev, match_virt)
> -Match.KernelCommandLine, config_parse_net_condition, 
> CONDITION_KERNEL_COMMAND_LINE, offsetof(NetDev, match_kernel)
> -Match.Architecture,  config_parse_net_condition, 
> CONDITION_ARCHITECTURE,offsetof(NetDev, match_arch)
> -NetDev.Description,  config_parse_string,0,  
>offsetof(NetDev, description)
> -NetDev.Name, config_parse_ifname,0,  
>offsetof(NetDev, ifname)
> -NetDev.Kind, config_parse_netdev_kind,   0,  
>offsetof(NetDev, kind)
> -NetDev.MTUBytes, config_parse_iec_size,  0,  
>offsetof(NetDev, mtu)
> -NetDev.MACAddress,   config_parse_hwaddr,0,  
>offsetof(NetDev, mac)
> -VLAN.Id, config_parse_uint64,0,  
>offsetof(VLan, id)
> -MACVLAN.Mode,config_parse_macvlan_mode,  0,  
>offsetof(MacVlan, mode)
> -Tunnel.Local,config_parse_tunnel_address,0,  
>offsetof(Tunnel, local)
> -Tunnel.Remote,   config_parse_tunnel_address,0,  
>offsetof(Tunnel, remote)
> -Tunnel.TOS,  config_parse_unsigned,  0,  
>offsetof(Tunnel, tos)
> -Tunnel.TTL,  config_parse_unsigned,  0,  
>offsetof(Tunnel, ttl)
> -Tunnel.DiscoverPathMTU,  config_parse_bool,  0,  
>offsetof(Tunnel, pmtudisc)
> -Peer.Name,   config_parse_ifname,   

[systemd-devel] [PATCH v10] tmpfiles, man: Add xattr support to tmpfiles

[Maciej Wereski]

This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.

It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:

name=value

All other fields are ignored.

If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.

Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
v10:
* use strv_consume_pair()
* small refactorization and cleanup

v9:
* fully parse xattrs in one place
* remove potential double free()

v8:
* update man

v7:
* use strv_consume() instead of strv_extend()
* use only lsetxattr()
* do not label in 'z' option
* style fixes and cleanup

v6:
* rebase
* man fixes
* use glibc xattr
* use unquote_first_word() instead of own parsing logic

v5:
* fixes for HAVE_XATTR undefined
* use cunescape() instead of strreplace()
* cache result of strv_length()
* fix typo in manpage

v4:
* grammar fix in man
* style fix

v3:
* "may be used" instead of "should be used" in manpage
* use strv_isempty() instead of != NULL
* rework item_set_xattrs() with split_pair()
* remove copy_item_contents()
* use hashmap_replace() instead of removed copy_item_contents()
* use strv_extend() instead of strv_append()
* cleanup
---
 man/tmpfiles.d.xml  |  32 ---
 src/tmpfiles/tmpfiles.c | 139 
 2 files changed, 155 insertions(+), 16 deletions(-)

diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 1b14d69..4f2e640 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -343,6 +343,25 @@ L/tmp/foobar ----   
/dev/null
 normal path
 names.
 
+
+
+t
+Set extended
+attributes on item. It may be
+used in conjunction with other
+types (only d,
+D, 
f,
+F, 
L,
+p, 
c,
+b, makes sense).
+If used as a standalone line, then
+systemd-tmpfiles
+will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+
+
 
 
 If the exclamation mark is used, this
@@ -430,7 +449,7 @@ r! /tmp/.X[0-9]*-lock
 will not be modified. This parameter is
 ignored for x,
 r, R,
-L lines.
+L, t 
lines.
 
 Optionally, if prefixed with
 ~, the access mode is masked
@@ -462,8 +481,8 @@ r! /tmp/.X[0-9]*-lock
 ownership will not be modified. These
 parameters are ignored for
 x, r,
-R, L
-lines.
+R, L,
+t lines.
 
 
 
@@ -527,8 +546,8 @@ r! /tmp/.X[0-9]*-lock
 specify a short string that is written to the
 file, suffixed by a newline. For
 C, specifies the source file
-or directory. Ignored for all other
-lines.
+or directory. For t determines
+extended attributes to be set. Ignored for all other 
lines.
 
 
 
@@ -540,7 +559,8 @@ r! /tmp/.X[0-9]*-lock
 screen needs two directories 
created at boot with specific modes and ownership.
 
 d /run/screens  1777 root root 10d
-d /run/uscreens 0755 root root 10d12h
+d /run/uscreens 0755 root root 10d12h
+t /run/screen - - - - user.name="John Smith" 
security.SMACK64=screen
 
 
 /etc/tmpfiles.d/abrt.conf example
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index d60c577..d40bd96 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "log.h"
 #include "util.h"
@@ -71,6 +72,7 @@ typedef enum ItemTy

Re: [systemd-devel] mate desktop user service file

[Qu Wenruo]

在 12/04/2014 04:56 PM, arnaud gaboury 写道:

mate-settings-daemon might expect to be run from within an X-session.
These errors look like DISPLAY= isn't set, which is reasonable because
systemd starts programs from a clean environment.

As mentioned in my post, $DISPLAY is correctly set and is in systemctl
environment. The command is run inside the X session

After more tests, I realized two variables were missing:
-$XAUTHORITY
In an effort to group runtime variables in one place, I set
XAUTHORITY=/run/user/1000/Xauthority.
So adding Environment=XAUTHORITY=/run/user/1000/Xauthority solved this issue.

-$DBUS_SESSION_BUS_ADDRESS
For reasons I ignore (far from being a dbus expert), the
$DBUS_SESSION_BUS_ADDRESS as returned by the
$systemctl --user show-environment did not work for mate-settings-daemon.
Instead, mate is looking for this file to connect to dbus :
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
(machine.id-display). This file has the following content:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736
DBUS_SESSION_BUS_PID=8268
DBUS_SESSION_BUS_WINDOWID=16777217
So adding 
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
solved the issue.

I am now with this service file:

~/.config/systemd/user/mate-settings-daemon.service

-
[Unit]
Description=Mate settings daemon

[Service]
Type=daemon
Environment=XAUTHORITY=/run/user/1000/Xauthority
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
ExecStart=/usr/lib/mate-settings-daemon/mate-settings-daemon

[Install]
WantedBy=wm.target


it works and does what I am expecting (mate-settings are started
without any mate session being started).

-
gabx@hortensia ➤➤ ~ % systemctl --user status mate-settings-daemon
● mate-settings-daemon.service - Mate settings daemon
Loaded: loaded
(/home/gabx/.config/systemd/user/mate-settings-daemon.service;
disabled)
Active: active (running) since Thu 2014-12-04 09:34:39 CET; 9min ago
  Main PID: 5664 (mate-settings-d)
CGroup: 
/user.slice/user-1000.slice/user@1000.service/mate-settings-daemon.service
└─5664 /usr/lib/mate-settings-daemon/mate-settings-daemon


Just to mention, the default 1.8.1 mate, will autostart 
mate-setting-daemon according to

its file in /etc/xdg/autostart/mate-settings-daemon.desktop:
--
[Desktop Entry]
Type=Application
Name=MATE Settings Daemon

Exec=/usr/lib/mate-settings-daemon/mate-settings-daemon
OnlyShowIn=MATE;
X-MATE-Autostart-Phase=Initialization
X-MATE-Autostart-Notify=true
X-MATE-AutoRestart=true
--

So the problem does not involve systemd at all...

Thanks,
Qu



Anyway, you really should talk to the mate developers to ask them

It is done, but still waiting for any hint...

Now my new questions:

It seems to me my setting is a dirty hack. I can't understand the
content of ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0.

-
$ myps dbus
.
154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
--autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
--close-stderr
.
---

Why this autolaunch ?
Why is the DBUS_SESSION_BUS_ADDRESS in this file set to
/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 when
$systemctl --user show-environment returns
DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket ?
I am left with two adresses, which sounds to me confusing and weird.

Why is mate-settings-daemon listening to the adress in
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 and not to the
one provided by systemctl ?


Even if my setup works, I would like to understand this story of two
dbus seesion adresses. Thank you for any explanation to light my
lantern.


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


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

Re: [systemd-devel] mate desktop user service file

[arnaud gaboury]

>
> mate-settings-daemon might expect to be run from within an X-session.
> These errors look like DISPLAY= isn't set, which is reasonable because
> systemd starts programs from a clean environment.

As mentioned in my post, $DISPLAY is correctly set and is in systemctl
environment. The command is run inside the X session

After more tests, I realized two variables were missing:
-$XAUTHORITY
In an effort to group runtime variables in one place, I set
XAUTHORITY=/run/user/1000/Xauthority.
So adding Environment=XAUTHORITY=/run/user/1000/Xauthority solved this issue.

-$DBUS_SESSION_BUS_ADDRESS
For reasons I ignore (far from being a dbus expert), the
$DBUS_SESSION_BUS_ADDRESS as returned by the
$systemctl --user show-environment did not work for mate-settings-daemon.
Instead, mate is looking for this file to connect to dbus :
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
(machine.id-display). This file has the following content:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736
DBUS_SESSION_BUS_PID=8268
DBUS_SESSION_BUS_WINDOWID=16777217
So adding 
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
solved the issue.

I am now with this service file:

~/.config/systemd/user/mate-settings-daemon.service

-
[Unit]
Description=Mate settings daemon

[Service]
Type=daemon
Environment=XAUTHORITY=/run/user/1000/Xauthority
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
ExecStart=/usr/lib/mate-settings-daemon/mate-settings-daemon

[Install]
WantedBy=wm.target


it works and does what I am expecting (mate-settings are started
without any mate session being started).

-
gabx@hortensia ➤➤ ~ % systemctl --user status mate-settings-daemon
● mate-settings-daemon.service - Mate settings daemon
   Loaded: loaded
(/home/gabx/.config/systemd/user/mate-settings-daemon.service;
disabled)
   Active: active (running) since Thu 2014-12-04 09:34:39 CET; 9min ago
 Main PID: 5664 (mate-settings-d)
   CGroup: 
/user.slice/user-1000.slice/user@1000.service/mate-settings-daemon.service
   └─5664 /usr/lib/mate-settings-daemon/mate-settings-daemon




> Anyway, you really should talk to the mate developers to ask them
It is done, but still waiting for any hint...

Now my new questions:

It seems to me my setting is a dirty hack. I can't understand the
content of ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0.

-
$ myps dbus
.
154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
--autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
--close-stderr
.
---

Why this autolaunch ?
Why is the DBUS_SESSION_BUS_ADDRESS in this file set to
/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 when
$systemctl --user show-environment returns
DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket ?
I am left with two adresses, which sounds to me confusing and weird.

Why is mate-settings-daemon listening to the adress in
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 and not to the
one provided by systemctl ?


Even if my setup works, I would like to understand this story of two
dbus seesion adresses. Thank you for any explanation to light my
lantern.


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

Re: [systemd-devel] [PATCH v4] run: introduce timer support option

[WaLyong Cho]

On 12/04/2014 03:44 AM, Lennart Poettering wrote:
> On Tue, 02.12.14 23:35, WaLyong Cho (walyong@samsung.com) wrote:
> 
>> Supported timer options --on-active=, --on-boot=, --on-startup=,
>> --on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
>> corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
>> OnUnitActiveSec=, OnUnitInactiveSec= of timer respectively.
> 
> I think a nice way to make both the properties of the service and of
> the timer unit configurable would be to introduce --timer-property= in
> addition to --property= as parameter. --property= would then always be
> applied to the service/scope being created, and --timer-property=
> would apply to the timer unit instead. Do we need the tables of the
> 3rd patch which a simple scheme like that?

I replied on 3rd patch email. If we don't need 3rd patch then I will
change it to --timer-property=.

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

Re: [systemd-devel] [PATCH v4 3/4] unit: add UnitMask enum and get unit scope(mask) api from property

[WaLyong Cho]

On 12/04/2014 03:43 AM, Lennart Poettering wrote:
> On Tue, 02.12.14 23:29, WaLyong Cho (walyong@samsung.com) wrote:
> 
> Hmm, what's the rationale for this? Can you elaborate?

As you already noticed(on the 4th mail), this hash table is used to find
unit can have a given property. As you said on 4th mail, if we use a
special option for timer then this will not be needed.
This can be also used in systemctl set-property and we can detect given
property is supported by that unit or not before sending dbus. But, in
most of case, systemctl set-property is called by user command line. And
they will know which unit support which property. So, maybe this is not
much needed.
If you feel messy, I will add --timer-property= option.

WaLyong
> 
>> ---
>>  Makefile.am  |   7 ++
>>  src/shared/.gitignore|   1 +
>>  src/shared/unit-name.c   |  22 
>>  src/shared/unit-name.h   |  26 +
>>  src/shared/unit-property-scope.gperf | 202 
>> +++
>>  5 files changed, 258 insertions(+)
>>  create mode 100644 src/shared/unit-property-scope.gperf
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 38d320f..3cec5fb 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -819,6 +819,7 @@ libsystemd_shared_la_SOURCES = \
>>  src/shared/cgroup-show.h \
>>  src/shared/unit-name.c \
>>  src/shared/unit-name.h \
>> +src/shared/unit-property-scope.c \
>>  src/shared/utmp-wtmp.h \
>>  src/shared/watchdog.c \
>>  src/shared/watchdog.h \
>> @@ -907,6 +908,12 @@ libsystemd_shared_la_CFLAGS = \
>>  $(SECCOMP_CFLAGS) \
>>  -pthread
>>  
>> +EXTRA_DIST += \
>> +src/shared/unit-property-scope.gperf
>> +
>> +CLEANFILES += \
>> +src/shared/unit-property-scope.c
>> +
>>  libsystemd_shared_la_LIBADD = \
>>  $(CAP_LIBS)
>>  
>> diff --git a/src/shared/.gitignore b/src/shared/.gitignore
>> index 61709e8..e7faa23 100644
>> --- a/src/shared/.gitignore
>> +++ b/src/shared/.gitignore
>> @@ -10,3 +10,4 @@
>>  /arphrd-from-name.h
>>  /arphrd-list.txt
>>  /arphrd-to-name.h
>> +/unit-property-scope.c
>> diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
>> index 21b6691..7cf0160 100644
>> --- a/src/shared/unit-name.c
>> +++ b/src/shared/unit-name.c
>> @@ -602,3 +602,25 @@ static const char* const 
>> unit_dependency_table[_UNIT_DEPENDENCY_MAX] = {
>>  };
>>  
>>  DEFINE_STRING_TABLE_LOOKUP(unit_dependency, UnitDependency);
>> +
>> +static UnitMask unit_get_mask_from_property(const char *property) {
>> +const unit_property_scope_mapping *m;
>> +
>> +assert(property);
>> +
>> +m = unit_property_scope_mapping_lookup(property, strlen(property));
>> +if (m)
>> +return m->scope;
>> +
>> +return _UNIT_MASK_MAX;
>> +
>> +}
>> +
>> +bool unit_can_have_property(UnitType t, const char *property) {
>> +UnitMask m;
>> +
>> +assert(property);
>> +
>> +m = unit_get_mask_from_property(property);
>> +return !!((1ULL << t) & m);
>> +}
>> diff --git a/src/shared/unit-name.h b/src/shared/unit-name.h
>> index 6f139cc..191c930 100644
>> --- a/src/shared/unit-name.h
>> +++ b/src/shared/unit-name.h
>> @@ -28,6 +28,7 @@
>>  #define UNIT_NAME_MAX 256
>>  
>>  typedef enum UnitType UnitType;
>> +typedef enum UnitMask UnitMask;
>>  typedef enum UnitLoadState UnitLoadState;
>>  typedef enum UnitDependency UnitDependency;
>>  
>> @@ -49,6 +50,23 @@ enum UnitType {
>>  _UNIT_TYPE_INVALID = -1
>>  };
>>  
>> +enum UnitMask {
>> +UNIT_MASK_SERVICE   = 1ULL << UNIT_SERVICE,
>> +UNIT_MASK_SOCKET= 1ULL << UNIT_SOCKET,
>> +UNIT_MASK_BUSNAME   = 1ULL << UNIT_BUSNAME,
>> +UNIT_MASK_TARGET= 1ULL << UNIT_TARGET,
>> +UNIT_MASK_SNAPSHOT  = 1ULL << UNIT_SNAPSHOT,
>> +UNIT_MASK_DEVICE= 1ULL << UNIT_DEVICE,
>> +UNIT_MASK_MOUNT = 1ULL << UNIT_MOUNT,
>> +UNIT_MASK_AUTOMOUNT = 1ULL << UNIT_AUTOMOUNT,
>> +UNIT_MASK_SWAP  = 1ULL << UNIT_SWAP,
>> +UNIT_MASK_TIMER = 1ULL << UNIT_TIMER,
>> +UNIT_MASK_PATH  = 1ULL << UNIT_PATH,
>> +UNIT_MASK_SLICE = 1ULL << UNIT_SLICE,
>> +UNIT_MASK_SCOPE = 1ULL << UNIT_SCOPE,
>> +_UNIT_MASK_MAX  = 1ULL <<_UNIT_TYPE_MAX,
>> +};
>> +
>>  enum UnitLoadState {
>>  UNIT_STUB = 0,
>>  UNIT_LOADED,
>> @@ -165,3 +183,11 @@ int build_subslice(const char *slice, const char*name, 
>> char **subslice);
>>  
>>  const char *unit_dependency_to_string(UnitDependency i) _const_;
>>  UnitDependency unit_dependency_from_string(const char *s) _pure_;
>> +
>> +struct unit_property_scope_mapping {
>> +const char* property;
>> +UnitMask scope;
>> +};
>> +typedef struct unit_property_scope_mapping unit_property_scope_mapping;
>> +const unit_property_scope_mapping* unit_property_scope_mapping_lookup 
>> (regist