Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it

[Martin Pitt]

Hey Lennart,

Lennart Poettering [2015-02-28 17:40 +0100]:
> This is implemented now. Please check if this fixes this issue for
> you.

This fixes the bad unmounts at boot, but also breaks the automatic cleanup of
stale mounts after CD ejection. After inserting a medium, the .device looks ok:

$ systemctl show dev-sr1.device
SysFSPath=/sys/devices/pci:00/:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr1
Id=dev-sr1.device
Names=dev-sr1.device
Following=sys-devices-pci:00-:00:01.1-ata2-host1-target1:0:0-1:0:0:0-block-sr1.device
Wants=media-martin-Fedora\x5cx2dLive\x5cx2dLXDE\x5cx2dx86_64\x5cx2d21\x5cx2d5.mount
BoundBy=media-martin-Fedora\x5cx2dLive\x5cx2dLXDE\x5cx2dx86_64\x5cx2d21\x5cx2d5.mount
Before=media-martin-Fedora\x5cx2dLive\x5cx2dLXDE\x5cx2dx86_64\x5cx2d21\x5cx2d5.mount
Description=QEMU_DVD-ROM Fedora-Live-LXDE-x86_64-21-5
LoadState=loaded
ActiveState=active
SubState=plugged

and so does the mount:

$ systemctl show 
'media-martin-Fedora\x2dLive\x2dLXDE\x2dx86_64\x2d21\x2d5.mount' > sr1.mount
Where=/media/martin/Fedora-Live-LXDE-x86_64-21-5
What=/dev/sr1
Id=media-martin-Fedora\x5cx2dLive\x5cx2dLXDE\x5cx2dx86_64\x5cx2d21\x5cx2d5.mount
Names=media-martin-Fedora\x5cx2dLive\x5cx2dLXDE\x5cx2dx86_64\x5cx2d21\x5cx2d5.mount
Requires=-.mount
Wants=system.slice
BindsTo=dev-sr1.device
WantedBy=dev-sr1.device
Conflicts=umount.target
Before=local-fs.target umount.target
After=local-fs-pre.target system.slice -.mount systemd-journald.socket 
dev-sr1.device
RequiresMountsFor=/media/martin
Description=/media/martin/Fedora-Live-LXDE-x86_64-21-5
LoadState=loaded
ActiveState=active
SubState=mounted
SourcePath=/proc/self/mountinfo

but after ejecting the mount still stays around. The device unit does
to activating/tentative, and the .mount unit is unchanged from the above.
Supposedly this line is the interesting one:

  systemd[1]: dev-sr1.device changed plugged -> tentative

which in this case really should become "dead". The full debug journal
is at http://people.canonical.com/~pitti/tmp/journal-cd-eject.txt

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] minimal required units

[Andrei Borzenkov]

В Thu, 12 Mar 2015 13:49:38 -0700
aaron_wri...@selinc.com пишет:

> Andrei Borzenkov  wrote on 03/12/2015 12:18:15 PM:
> 
> > From: Andrei Borzenkov 
> > To: aaron_wri...@selinc.com
> > Cc: systemd-devel@lists.freedesktop.org
> > Date: 03/12/2015 12:18 PM
> > Subject: Re: [systemd-devel] minimal required units
> > 
> > В Thu, 12 Mar 2015 11:09:57 -0700
> > aaron_wri...@selinc.com пишет:
> > 
> > > 
> > > I feel like there needs to be a list of required units to get base 
> > > functionality out of systemd. So that embedded guys like me can build 
> up a 
> > > system from scratch, instead of starting from full blown desktop 
> support 
> > > and guessing at what can be taken out.
> > > 
> > 
> > sysinit.target is supposed to get you minimal working system (more or
> > less what you got with single user in the past). It could be considered
> > as starting point. Most embedded systems I have seen were running
> > something very close to single user anyway.
> > 
> 
> Right now, I'm starting with the basic.target. Gets me a few more features 
> than sysinit.target, such as timers, which I feel I can use in my product 
> to replace cron.
> 
> > > My question is mainly about whether the list of actual required units 
> is 
> > > known, or if it is something that requires investigation (digging 
> through 
> > > a bunch of code).
> > > 
> > 
> > Did you see bootup(7)?
> 
> Yes, I've read that a few times, and I love the diagram. It seems to 
> suggest to me that I can use basic.target as a good synchronization point, 
> and then add my units after that, which makes sense to me.
> 
> If I include at least all of the units leading up to basic.target, would 
> that cover the units required by systemd?

systemd does not really require anything. Really. *You* (or your
system) require something to be started during boot and only you know
what should be started. You can use single service that calls /etc/rc
as starting point and split it up step by step.

Units shipped with systemd help to organize system startup in logical
steps and provide common hooks to plug your own extensions into.
Removing common hooks won't buy you anything but will make system less
flexible and harder to troubleshoot.

>  Though, that would include lots 
> of things I don't need, such as cryptsetup.target, swap.target, mqueue, 
> configfs, debugfs, etc.
> 

If you do not use them, do not include them. But cryptsetup.target
or swap.target will not even appear if you do not have /etc/crypttab
or swaps and others you mention check whether they can be started.

> I'm concerned because I left out local-fs.target to begin with, as I don't 
> need systemd to mount anything, but that seemed to cause systemd to 
> unmount everything other than / and the kernel file systems.

Sorry, that does not fit. Either you "do not need to mount anything" or
"systemd unmount everything". What was there to unmount if you did not
mount anything in the first place? 

> So I got bit 
> by there not being any documentation that says, "local-fs.target is 
> Required". Unless, I'm missing something.
> 

It is very hard to answer without seeing more details.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs

[Lennart Poettering]

On Wed, 11.03.15 08:12, Didier Roche (didro...@ubuntu.com) wrote:

> Le 10/03/2015 18:54, Lennart Poettering a écrit :
> >On Tue, 10.03.15 18:01, Didier Roche (didro...@ubuntu.com) wrote:
> >
> >>The context is bug
> >>https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140, where
> >>systemd-machine-id-commit unit is entering in failed state (the binary
> >>handles gracefully the fact that it can't unmount the file) on a default
> >>ubuntu live system (which is a squashfs/overlayfs system).
> >Hmm, it's not clear to me by that bug what precisely fails... Any
> >idea? Maybe it would be better to just handle that failure gracefully...
> 
> Basically, ConditionPathIsMountPoint=/etc/machine-id is met in the unit and
> so systemd-machine-id-commit is launched.
> 
> This one:
> - executes the double checking path_is_mount_point(etc_machine_id, false)
> successfully (of course)
> - find that machine-id fd is a temporary fs (based on the same issue), read
> the machine-id file content
> - switch namespace
> - call unmount(etc_machine_id), which obviously fails as there is nothing to
> unmount. I don't think we should shadow that failure and not returning in
> error here, right?

I think we should do that. I.e. downgrade the error message that happens in
this case to debug, and exit cleanly. But of course only do so if the
right errno is returned from umount(). Also, a good explanatory
comment next to it would be good...

Lennart

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

Re: [systemd-devel] How to factory reset?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote:
> On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger  
> wrote:
> >> presets and machined ID are applied by PID 1, before it begins with
> >> starting any units, hence *really* early on. Note though that actually
> >> /etc/machine-id is used as flag for "is /etc empty". If the file
> >> exists it is assumed that /etc is provisioned properly. If it is
> >> missing PID 1 will generate the machiend id and apply presets.
> >
> > An OS installer could put the machine-id into /usr just fine (and so
> > can I) and systemd could just get it from there if available before
> > generating a new one.
> >
> > It would be nice if the machine-id did not change during to a factory
> > reset: It is used in the logs and changing it will basically make
> > historical log data much harder to analyze. IIRC networkd also uses it
> > to generate persistent MAC addresses for containers and such.
> >
> > So far this seems to be the only critical piece of information that
> > can not get restored via tmpfiles.d.
> 
> Thinking about this a bit longer: /usr does not seem like a good idea.
> The machine-id is supposed to be unique and usr-images are meant to be
> reused.
> 
> Maybe provide a kernel command line option to force the machine-id if
> none is set yet?
I think this could be an option.  We currently check
/var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid.
I think that the first should work for your use case, since you keep /var.
But we also check some commandline option, this seems useful for some
use cases.

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 13, 2015 at 09:54:48AM +1100, Jeff Waugh wrote:
> On Fri, Mar 13, 2015 at 8:53 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > So you prefer the second version to the first, right? Does not
> > exec_prefix get assigned and then substituted, leading to an identical
> > result?
> 
> Those are the as-installed versions (they're not manipulated again during 
> make).
I wasn't sufficiently clear. I meant substituted *by pkg-config*,
leading to an identical result for anything which queries pkg-config
for those values.

> >> And how does that improve cross-compilation?
> >
> > It allows you to successfully build other software that uses the
> > library. A minor detail. :-)
>
> Well, I was looking for a more elaborate explanation, why that change
> makes a difference.
> To me, the resulting .pc are basically the same. So there must be
> something else I'm missing.
Exactly my thoughts.

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Michael Biebl]

2015-03-13 0:13 GMT+01:00 Jeff Waugh :
> On Fri, Mar 13, 2015 at 10:07 AM, Michael Biebl  wrote:
>>> Those are the as-installed versions (they're not manipulated again during 
>>> make).
>>
>> And how does that improve cross-compilation?
>
> It allows you to successfully build other software that uses the
> library. A minor detail. :-)

Well, I was looking for a more elaborate explanation, why that change
makes a difference.
To me, the resulting .pc are basically the same. So there must be
something else I'm missing.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Jeff Waugh]

On Fri, Mar 13, 2015 at 10:11 AM, Lucas De Marchi
 wrote:
> Both kmod and systemd are being crosscompiled for quite some time by yocto, 
> buildroot, etc

It does interest me that buildroot doesn't have an equivalent change,
despite (at least) pciutils depending on it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Jeff Waugh]

On Fri, Mar 13, 2015 at 10:11 AM, Lucas De Marchi
 wrote:
> I can't but think this is just to conform to other (gnome) projects.

These patches come from an absolutely non-GNOME environment (OpenWrt),
but I'm appealing to an authority in actively maintained GNOME code as
that's where pkg-config comes from and a project I'm historically
familiar with.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Jeff Waugh]

On Fri, Mar 13, 2015 at 10:07 AM, Michael Biebl  wrote:
>> Those are the as-installed versions (they're not manipulated again during 
>> make).
>
> And how does that improve cross-compilation?

It allows you to successfully build other software that uses the
library. A minor detail. :-)

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Lucas De Marchi]

On Thu, Mar 12, 2015 at 6:57 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Mar 12, 2015 at 11:00:55AM +0100, Kay Sievers wrote:
>> On Thu, Mar 12, 2015 at 5:09 AM, Lucas De Marchi
>>  wrote:
>> > On Tue, Mar 10, 2015 at 3:04 PM, Jeff Waugh  wrote:
>> >> Generate pkg-config files during configure as God (Havoc) intended. This 
>> >> fixes
>> >> all of systemd's pkg-config files when cross-compiling (and possibly 
>> >> other use
>> >> cases).
>>
>> > Kay, please take a look on this. There's a similar patch pending to
>> > kmod on [1]. I'm still not sure what exactly it's fixing... seems like
>> > just that it would not replace/expand all occurrences of the
>> > variables...
>>
>> AC_CONFIG_FILES is usually meant to create/prepare autoconf/automake
>> related files needed for the build process, and not to produce plain
>> package content to ship.
>>
>> Not that quoting autoconf manuals would make the autotools mess any
>> better, but there is also this. :)
>>
>> "Similarly, you should not rely on AC_CONFIG_FILES to replace bindir
>> and friends in your shell scripts and other files; instead, let make
>> manage their replacement. For instance Autoconf ships templates of its
>> shell scripts ending with ‘.in’, and uses a makefile snippet similar
>> to the following to build scripts like autoheader and autom4te:
> OK, but is there any difference for us, in the normal non-cross case?
> (I guess that make is a bit more efficient, because it parallelizes, but
> that step is tiny in any case, so the difference is most likely negligible.)
>
> I asked some more questions about the motivation for this change in
> the other branch of the thread. I'm just thinking that if there's a

what branch?

> good reason to change this for people who cross-compile, we should
> consider doing it.

Looking at it I still fail to see any problems and why one is better
than the other. The only difference is that ours expands all variables
and letting for configure they are not all expanded. There's no
difference regarding crosscompilation. Both kmod and systemd are being
crosscompiled for quite some time by yocto, buildroot, etc

I can't but think this is just to conform to other (gnome) projects.


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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Michael Biebl]

2015-03-12 23:54 GMT+01:00 Jeff Waugh :
> On Fri, Mar 13, 2015 at 8:53 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> So you prefer the second version to the first, right? Does not
>> exec_prefix get assigned and then substituted, leading to an identical
>> result?
>
> Those are the as-installed versions (they're not manipulated again during 
> make).

And how does that improve cross-compilation?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Jeff Waugh]

On Fri, Mar 13, 2015 at 8:53 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> So you prefer the second version to the first, right? Does not
> exec_prefix get assigned and then substituted, leading to an identical
> result?

Those are the as-installed versions (they're not manipulated again during make).

Here's an example from GNOME land:

  https://git.gnome.org/browse/gjs/tree/configure.ac#n232
  https://git.gnome.org/browse/gjs/tree/Makefile.am#n72

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 12, 2015 at 11:00:55AM +0100, Kay Sievers wrote:
> On Thu, Mar 12, 2015 at 5:09 AM, Lucas De Marchi
>  wrote:
> > On Tue, Mar 10, 2015 at 3:04 PM, Jeff Waugh  wrote:
> >> Generate pkg-config files during configure as God (Havoc) intended. This 
> >> fixes
> >> all of systemd's pkg-config files when cross-compiling (and possibly other 
> >> use
> >> cases).
> 
> > Kay, please take a look on this. There's a similar patch pending to
> > kmod on [1]. I'm still not sure what exactly it's fixing... seems like
> > just that it would not replace/expand all occurrences of the
> > variables...
> 
> AC_CONFIG_FILES is usually meant to create/prepare autoconf/automake
> related files needed for the build process, and not to produce plain
> package content to ship.
> 
> Not that quoting autoconf manuals would make the autotools mess any
> better, but there is also this. :)
> 
> "Similarly, you should not rely on AC_CONFIG_FILES to replace bindir
> and friends in your shell scripts and other files; instead, let make
> manage their replacement. For instance Autoconf ships templates of its
> shell scripts ending with ‘.in’, and uses a makefile snippet similar
> to the following to build scripts like autoheader and autom4te:
OK, but is there any difference for us, in the normal non-cross case?
(I guess that make is a bit more efficient, because it parallelizes, but
that step is tiny in any case, so the difference is most likely negligible.)

I asked some more questions about the motivation for this change in
the other branch of the thread. I'm just thinking that if there's a
good reason to change this for people who cross-compile, we should
consider doing it.

Zbyszek

> 
> edit = sed \
>-e 's|@bindir[@]|$(bindir)|g' \
>-e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \
>-e 's|@prefix[@]|$(prefix)|g'
> 
> autoheader autom4te: Makefile
> rm -f $@ $@.tmp
> srcdir=''; \
> test -f ./$@.in || srcdir=$(srcdir)/; \
> $(edit) $${srcdir}$@.in >$@.tmp
> chmod +x $@.tmp
> chmod a-w $@.tmp
> mv $@.tmp $@
> 
> autoheader: $(srcdir)/autoheader.in
> autom4te: $(srcdir)/autom4te.in"
> 
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables
> 
> Kay
> ___
> 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] build: generate pkg-config files during configure

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 12, 2015 at 06:27:14PM +1100, Jeff Waugh wrote:
> On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
>  wrote:
> > What does this fix Jeff, could you please explain?
> 
> Here's the relevant part of a pkg-config file produced during make:
> 
> prefix=/usr
> exec_prefix=/usr
> libdir=/usr/lib
> includedir=/usr/include
> 
> Versus during configure:
> 
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> 
> Which disproportionately affects cross-compiling and similar build situations.
So you prefer the second version to the first, right? Does not
exec_prefix get assigned and then substituted, leading to an identical
result?

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

Re: [systemd-devel] minimal required units

[Aaron_Wright]

Andrei Borzenkov  wrote on 03/12/2015 12:18:15 PM:

> From: Andrei Borzenkov 
> To: aaron_wri...@selinc.com
> Cc: systemd-devel@lists.freedesktop.org
> Date: 03/12/2015 12:18 PM
> Subject: Re: [systemd-devel] minimal required units
> 
> В Thu, 12 Mar 2015 11:09:57 -0700
> aaron_wri...@selinc.com пишет:
> 
> > 
> > I feel like there needs to be a list of required units to get base 
> > functionality out of systemd. So that embedded guys like me can build 
up a 
> > system from scratch, instead of starting from full blown desktop 
support 
> > and guessing at what can be taken out.
> > 
> 
> sysinit.target is supposed to get you minimal working system (more or
> less what you got with single user in the past). It could be considered
> as starting point. Most embedded systems I have seen were running
> something very close to single user anyway.
> 

Right now, I'm starting with the basic.target. Gets me a few more features 
than sysinit.target, such as timers, which I feel I can use in my product 
to replace cron.

> > My question is mainly about whether the list of actual required units 
is 
> > known, or if it is something that requires investigation (digging 
through 
> > a bunch of code).
> > 
> 
> Did you see bootup(7)?

Yes, I've read that a few times, and I love the diagram. It seems to 
suggest to me that I can use basic.target as a good synchronization point, 
and then add my units after that, which makes sense to me.

If I include at least all of the units leading up to basic.target, would 
that cover the units required by systemd? Though, that would include lots 
of things I don't need, such as cryptsetup.target, swap.target, mqueue, 
configfs, debugfs, etc.

I'm concerned because I left out local-fs.target to begin with, as I don't 
need systemd to mount anything, but that seemed to cause systemd to 
unmount everything other than / and the kernel file systems. So I got bit 
by there not being any documentation that says, "local-fs.target is 
Required". Unless, I'm missing something.

PS - Thanks for pointing me at information. I'm still getting up to speed 
on systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] minimal required units

[Andrei Borzenkov]

В Thu, 12 Mar 2015 11:09:57 -0700
aaron_wri...@selinc.com пишет:

> 
> I feel like there needs to be a list of required units to get base 
> functionality out of systemd. So that embedded guys like me can build up a 
> system from scratch, instead of starting from full blown desktop support 
> and guessing at what can be taken out.
> 

sysinit.target is supposed to get you minimal working system (more or
less what you got with single user in the past). It could be considered
as starting point. Most embedded systems I have seen were running
something very close to single user anyway.

> My question is mainly about whether the list of actual required units is 
> known, or if it is something that requires investigation (digging through 
> a bunch of code).
> 

Did you see bootup(7)?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] minimal required units

[Alison Chaiken]

aaron_wri...@selinc.com writes:
> Just for illustration purposes, here are few units listed in
> systemd.special, that I don't feel like I need, but which I'm left
> wondering if systemd needs them:
> cryptsetup.target
> display-manager.service
> getty.target
> graphical.target
> hibernate.target
> hybrid-sleep.target
> halt.target
> initrd-fs.target
> kbrequest.target
> multi-user.target
> network-online.target
> poweroff.target
> remote-fs.target
> initrd-root-fs.target
> runlevel*.target
> sigpwr.target
> sleep.target
> suspend.target
> swap.target

The right way to think about targets in systemd is as synchronous
points.   If target A Requires target B and is After it, then target A
won't try to start until after target B is ready in the sd_notify()
sense.   The targets are part of the signaling system for systemd's
sequencing method. Neil Brown's article at LWN
(https://lwn.net/Articles/584176/) discusses how targets can be used
to pass configuration signals between services.A target that can
be 'isolated' is akin to a run-level, but a target that cannot be
isolated is used for synchronization or signaling.

Some targets may be useful even if you don't strictly need them.   For
example, we old people may prefer to append '3' to bootargs when we
want to come up to the text console, and runlevel3.target provides
that capability.   You can, assuredly, append
'systemd.unit=multi-user.target' to bootargs instead.

The targets contribute to the file count, but not much to the binary
size.For embedded in general, it seems better not to touch
upstream bits if they don't make the binary larger.  Removing
services you don't need also must be done with caution.   For example,
I found out the hard way that getting rid of PAM means no 'systemctl
--user' commands will work.

Consider choosing different options when running configure.That
interface should in principle cleanly remove file sets corresponding
to individual features.   Removing individual files is always more
dangerous.

-- Alison


-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
One consumes a great deal of silence in the course of becoming
educated. -- Matthew B. Crawford
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] networkd: Begin with serial number 1 for netlink requests

[Tom Gundersen]

Great catch Richard! Much appreciated!

However, the patch didn't compile so had to fix it up before applying.
Could you verify that it still fixes the bug for you?

Tom

On Thu, Mar 12, 2015 at 7:14 PM, Richard Maw
 wrote:
> "Notifications are of informal nature and no reply is expected, therefore the
> sequence number is typically set to 0."[1]
>
> If networkd is started soon after recent netlink activity, then there
> will be messages with sequence number 0 in the buffer.
>
> The first thing networkd does is to request a dump of all the links. If
> it uses sequence number 0 for this, then it may confuse the dump request's
> response with that of a notification.
>
> This will result in it failing to properly enumerate all the links,
> but more importantly, when it comes to enumerate all the addresses, it
> will still have the link dump in progress, so the address enumeration
> will fail with -EBUSY.
>
> [1]: http://www.infradead.org/~tgr/libnl/doc/core.html#core_msg_types
> ---
>  src/libsystemd/sd-rtnl/sd-rtnl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c 
> b/src/libsystemd/sd-rtnl/sd-rtnl.c
> index ae49c77..5f54acd 100644
> --- a/src/libsystemd/sd-rtnl/sd-rtnl.c
> +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
> @@ -61,6 +61,11 @@ static int sd_rtnl_new(sd_rtnl **ret) {
>  sizeof(struct nlmsghdr), sizeof(uint8_t)))
>  return -ENOMEM;
>
> +/* Change notification responses have sequence 0, so we must
> + * start our request sequence numbers at 1, or we may confuse our
> + * responses with notifications from the kernel */
> +rtnl->sequence = 1;
> +
>  *ret = rtnl;
>  rtnl = NULL;
>
> --
> 1.9.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] networkd: Begin with serial number 1 for netlink requests

[Richard Maw]

"Notifications are of informal nature and no reply is expected, therefore the
sequence number is typically set to 0."[1]

If networkd is started soon after recent netlink activity, then there
will be messages with sequence number 0 in the buffer.

The first thing networkd does is to request a dump of all the links. If
it uses sequence number 0 for this, then it may confuse the dump request's
response with that of a notification.

This will result in it failing to properly enumerate all the links,
but more importantly, when it comes to enumerate all the addresses, it
will still have the link dump in progress, so the address enumeration
will fail with -EBUSY.

[1]: http://www.infradead.org/~tgr/libnl/doc/core.html#core_msg_types
---
 src/libsystemd/sd-rtnl/sd-rtnl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c b/src/libsystemd/sd-rtnl/sd-rtnl.c
index ae49c77..5f54acd 100644
--- a/src/libsystemd/sd-rtnl/sd-rtnl.c
+++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
@@ -61,6 +61,11 @@ static int sd_rtnl_new(sd_rtnl **ret) {
 sizeof(struct nlmsghdr), sizeof(uint8_t)))
 return -ENOMEM;
 
+/* Change notification responses have sequence 0, so we must
+ * start our request sequence numbers at 1, or we may confuse our
+ * responses with notifications from the kernel */
+rtnl->sequence = 1;
+
 *ret = rtnl;
 rtnl = NULL;
 
-- 
1.9.1

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

[systemd-devel] [PATCH] Fix rare crash on networkd start-up

[Richard Maw]

I could reliably make networkd crash by starting it immediately after
using Open vSwitch to make a lot of links.

This would make most of my system fail to boot, because they were ordered
after network-online.target, and systemd-networkd-wait-online.service
is not restarted when systemd-networkd.service is.

Attempting to use strace or ltrace to debug the failure in networkd
caused it to stop happening.

It turns out that this is because there's still some notification messages
about the new links being broadcast on the netlink socket when networkd
is started.

This wouldn't normally be a problem, since sd-rtnl knows to only pay
attention to responses that have the same serial number as the request,
but sd-rtnl starts its serial numbers at 0, which is what the kernel
uses for its notification messages.

Richard Maw (1):
  networkd: Begin with serial number 1 for netlink requests

 src/libsystemd/sd-rtnl/sd-rtnl.c | 5 +
 1 file changed, 5 insertions(+)

-- 
1.9.1

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

Re: [systemd-devel] minimal required units

[Aaron_Wright]

Andrei Borzenkov  wrote on 03/12/2015 10:38:19 AM:

> From: Andrei Borzenkov 
> To: aaron_wri...@selinc.com
> Cc: systemd-devel@lists.freedesktop.org
> Date: 03/12/2015 10:38 AM
> Subject: Re: [systemd-devel] minimal required units
> 
> В Thu, 12 Mar 2015 09:42:25 -0700
> aaron_wri...@selinc.com пишет:
> 
> > Peter Sztan  wrote on 03/12/2015 09:33:38 AM:
> > 
> > > From: Peter Sztan 
> > > To: aaron_wri...@selinc.com
> > > Cc: systemd Mailing List 
> > > Date: 03/12/2015 09:33 AM
> > > Subject: Re: [systemd-devel] minimal required units
> > > 
> > > Sorry for the noise, I have now read that you have already seen it.
> > > 
> > 
> > Just for illustration purposes, here are few units listed in 
> > systemd.special, that I don't feel like I need, but which I'm left 
> > wondering if systemd needs them:
> > 
> > cryptsetup.target
> > display-manager.service
> > getty.target
> > graphical.target
> > hibernate.target
> > hybrid-sleep.target
> > halt.target
> > initrd-fs.target
> > kbrequest.target
> > multi-user.target
> > network-online.target
> > poweroff.target
> > remote-fs.target
> > initrd-root-fs.target
> > runlevel*.target
> > sigpwr.target
> > sleep.target
> > suspend.target
> > swap.target
> > 
> 
> targets serve as common reference for collection of other units
> (services). They do not do anything by themselves, there is absolutely
> no reason to remove them. Some of them (at least those mentioned in
> systemd.special) do have special meaning and removing them will
> actually break functionality.

In my embedded environment I have to justify everything on the product. 
Given that the product doesn't have a monitor, I find that targets such as 
graphical.target or display-manager.target for example are hard to 
justify.

I would rather not just throw the whole systemd-kitchen-sink at the 
product and call it a day. It seems obvious that not all of the units 
referenced in systemd.special are actually required. Some of them don't 
even exist with my configuration (dbus.service, dbus.socket, 
runlevel*.target, etc).

I feel like there needs to be a list of required units to get base 
functionality out of systemd. So that embedded guys like me can build up a 
system from scratch, instead of starting from full blown desktop support 
and guessing at what can be taken out.

My question is mainly about whether the list of actual required units is 
known, or if it is something that requires investigation (digging through 
a bunch of code).

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Simon McVittie]

On 12/03/15 16:17, Philip Van Hoof wrote:
> I wonder if in a few years libsystemd.pc should have been
> libsystemd-1.0.pc because a libsystemd-2.0.pc became needed?

If libsystemd breaks C API, the systemd developers would just have to
declare that "libsystemd" actually meant "libsystemd API 1.0", and so is
superseded by "libsystemd API 2.0". That wouldn't be the end of the world.

It's how you name your *second* API version (i.e. not the same as the
first) that really matters :-)

> ps. In GLib this isn't being done with a cp in Makefile.am

GLib's API is expected to be long-term-stable (2.0 seems to have been
released in or before 2002), so automating the handling of API breaks
would be unnecessary effort.

Tracker switched API version on a regular basis until recently, which is
presumably why that automation was worth having.

> and yet
> other projects (dconf) don't do API versioning with the .pc filename.

If dconf never breaks API, no problem; if it does, it will hopefully
start including an API version in the .pc filename at that point.

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

Re: [systemd-devel] minimal required units

[Andrei Borzenkov]

В Thu, 12 Mar 2015 09:42:25 -0700
aaron_wri...@selinc.com пишет:

> Peter Sztan  wrote on 03/12/2015 09:33:38 AM:
> 
> > From: Peter Sztan 
> > To: aaron_wri...@selinc.com
> > Cc: systemd Mailing List 
> > Date: 03/12/2015 09:33 AM
> > Subject: Re: [systemd-devel] minimal required units
> > 
> > Sorry for the noise, I have now read that you have already seen it.
> > 
> 
> Just for illustration purposes, here are few units listed in 
> systemd.special, that I don't feel like I need, but which I'm left 
> wondering if systemd needs them:
> 
> cryptsetup.target
> display-manager.service
> getty.target
> graphical.target
> hibernate.target
> hybrid-sleep.target
> halt.target
> initrd-fs.target
> kbrequest.target
> multi-user.target
> network-online.target
> poweroff.target
> remote-fs.target
> initrd-root-fs.target
> runlevel*.target
> sigpwr.target
> sleep.target
> suspend.target
> swap.target
> 

targets serve as common reference for collection of other units
(services). They do not do anything by themselves, there is absolutely
no reason to remove them. Some of them (at least those mentioned in
systemd.special) do have special meaning and removing them will
actually break functionality.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them

[Kay Sievers]

On Fri, Feb 13, 2015 at 10:35 AM, Martin Pitt  wrote:
> Kay Sievers [2015-02-13 10:12 +0100]:
>> This looks awful. We should not litter generic rules with exotic niche
>> use cases like this. It will end up in a mess.
>
> Fully agreed :/

It is a rather small whitelist for now, which should not catch any
newly added device driver added in the future.

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

Re: [systemd-devel] minimal required units

[Aaron_Wright]

Peter Sztan  wrote on 03/12/2015 09:33:38 AM:

> From: Peter Sztan 
> To: aaron_wri...@selinc.com
> Cc: systemd Mailing List 
> Date: 03/12/2015 09:33 AM
> Subject: Re: [systemd-devel] minimal required units
> 
> Sorry for the noise, I have now read that you have already seen it.
> 

Just for illustration purposes, here are few units listed in 
systemd.special, that I don't feel like I need, but which I'm left 
wondering if systemd needs them:

cryptsetup.target
display-manager.service
getty.target
graphical.target
hibernate.target
hybrid-sleep.target
halt.target
initrd-fs.target
kbrequest.target
multi-user.target
network-online.target
poweroff.target
remote-fs.target
initrd-root-fs.target
runlevel*.target
sigpwr.target
sleep.target
suspend.target
swap.target

(and so on)

I can't tell from systemd.special if these are required or not.

> On Thu, Mar 12, 2015 at 5:32 PM, Peter Sztan  wrote:
> > man 7 systemd.special
> >
> > On Thu, Mar 12, 2015 at 4:41 PM,   wrote:
> >> Andrei Borzenkov  wrote on 03/11/2015 08:47:43 
PM:
> >>
> >>> From: Andrei Borzenkov 
> >>> To: aaron_wri...@selinc.com
> >>> Cc: systemd-devel@lists.freedesktop.org
> >>> Date: 03/11/2015 08:47 PM
> >>> Subject: Re: [systemd-devel] minimal required units
> >>>
> >>> В Wed, 11 Mar 2015 12:02:29 -0700
> >>> aaron_wri...@selinc.com пишет:
> >>>
> >>> > I'm trying to make an embedded device, and I would like to start 
with
> >>> > the
> >>> > minimal setup as possible. Are there some units that are required 
by
> >>> > systemd?
> >>> > I ask because systemd is complaining about a missing rescue.target 
unit,
> >>>
> >>> When does it do it?
> >>
> >> It was doing this because my default unit was not set correctly. But 
that
> >> isn't really the question. The question is, what units are required 
by
> >> systemd? How can I figure that out? It seems like rescue.target,
> >> local-fs.target, and local-fs-pre.target are required, but I've only
> >> discovered that after trial and error. I know the systemd.special man 
page
> >> lists a ton of special units, but it seems that not all of them are
> >> required. Right? Well, which ones are? I feel like I need to look 
through
> >> the code to see when a hardcoded unit is referenced, like 
> rescue.target was,
> >> that I don't know about.
> >>
> >> My device doesn't have many of the same requirements of a full 
desktop or
> >> server Linux, so I'm trying to strip out things from systemd, unit 
wise,
> >> that I don't want or need. I've customized sysinit.target and 
basic.target
> >> to just reference the units I want. And that seems to be going 
smooth, but
> >> it appears there are other units, that I didn't know about that are
> >> required, but that aren't documented as such (that I could find). 
This
> >> scares me a bit.
> >>
> >>>
> >>> > but I don't list rescue.target as a dependency of any other unit.
> >>> > However, grep tells me that /usr/lib/systemd/systemd contains the
> >>> > "rescue.target" string, which worries me. Is there a list of all 
the
> >>> > units
> >>> > that are required, even though no other unit lists them?
> >>
> >> ___
> >> 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] minimal required units

[Peter Sztan]

Sorry for the noise, I have now read that you have already seen it.

On Thu, Mar 12, 2015 at 5:32 PM, Peter Sztan  wrote:
> man 7 systemd.special
>
> On Thu, Mar 12, 2015 at 4:41 PM,   wrote:
>> Andrei Borzenkov  wrote on 03/11/2015 08:47:43 PM:
>>
>>> From: Andrei Borzenkov 
>>> To: aaron_wri...@selinc.com
>>> Cc: systemd-devel@lists.freedesktop.org
>>> Date: 03/11/2015 08:47 PM
>>> Subject: Re: [systemd-devel] minimal required units
>>>
>>> В Wed, 11 Mar 2015 12:02:29 -0700
>>> aaron_wri...@selinc.com пишет:
>>>
>>> > I'm trying to make an embedded device, and I would like to start with
>>> > the
>>> > minimal setup as possible. Are there some units that are required by
>>> > systemd?
>>> > I ask because systemd is complaining about a missing rescue.target unit,
>>>
>>> When does it do it?
>>
>> It was doing this because my default unit was not set correctly. But that
>> isn't really the question. The question is, what units are required by
>> systemd? How can I figure that out? It seems like rescue.target,
>> local-fs.target, and local-fs-pre.target are required, but I've only
>> discovered that after trial and error. I know the systemd.special man page
>> lists a ton of special units, but it seems that not all of them are
>> required. Right? Well, which ones are? I feel like I need to look through
>> the code to see when a hardcoded unit is referenced, like rescue.target was,
>> that I don't know about.
>>
>> My device doesn't have many of the same requirements of a full desktop or
>> server Linux, so I'm trying to strip out things from systemd, unit wise,
>> that I don't want or need. I've customized sysinit.target and basic.target
>> to just reference the units I want. And that seems to be going smooth, but
>> it appears there are other units, that I didn't know about that are
>> required, but that aren't documented as such (that I could find). This
>> scares me a bit.
>>
>>>
>>> > but I don't list rescue.target as a dependency of any other unit.
>>> > However, grep tells me that /usr/lib/systemd/systemd contains the
>>> > "rescue.target" string, which worries me. Is there a list of all the
>>> > units
>>> > that are required, even though no other unit lists them?
>>
>> ___
>> 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] minimal required units

[Peter Sztan]

man 7 systemd.special

On Thu, Mar 12, 2015 at 4:41 PM,   wrote:
> Andrei Borzenkov  wrote on 03/11/2015 08:47:43 PM:
>
>> From: Andrei Borzenkov 
>> To: aaron_wri...@selinc.com
>> Cc: systemd-devel@lists.freedesktop.org
>> Date: 03/11/2015 08:47 PM
>> Subject: Re: [systemd-devel] minimal required units
>>
>> В Wed, 11 Mar 2015 12:02:29 -0700
>> aaron_wri...@selinc.com пишет:
>>
>> > I'm trying to make an embedded device, and I would like to start with
>> > the
>> > minimal setup as possible. Are there some units that are required by
>> > systemd?
>> > I ask because systemd is complaining about a missing rescue.target unit,
>>
>> When does it do it?
>
> It was doing this because my default unit was not set correctly. But that
> isn't really the question. The question is, what units are required by
> systemd? How can I figure that out? It seems like rescue.target,
> local-fs.target, and local-fs-pre.target are required, but I've only
> discovered that after trial and error. I know the systemd.special man page
> lists a ton of special units, but it seems that not all of them are
> required. Right? Well, which ones are? I feel like I need to look through
> the code to see when a hardcoded unit is referenced, like rescue.target was,
> that I don't know about.
>
> My device doesn't have many of the same requirements of a full desktop or
> server Linux, so I'm trying to strip out things from systemd, unit wise,
> that I don't want or need. I've customized sysinit.target and basic.target
> to just reference the units I want. And that seems to be going smooth, but
> it appears there are other units, that I didn't know about that are
> required, but that aren't documented as such (that I could find). This
> scares me a bit.
>
>>
>> > but I don't list rescue.target as a dependency of any other unit.
>> > However, grep tells me that /usr/lib/systemd/systemd contains the
>> > "rescue.target" string, which worries me. Is there a list of all the
>> > units
>> > that are required, even though no other unit lists them?
>
> ___
> 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] build: generate pkg-config files during configure

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/03/2015 8:27, Jeff Waugh wrote:

> 
> Finally, a supporting appeal to authority: If you check
> GNOME-land, practically all pkg-config files are generated at
> configure time. :-)

Yes and no. Certain projects in the confusing land of the gnomes do
something like this:

tracker-miner-$(TRACKER_API_VERSION).pc: tracker-miner.pc
cp $< $@

to get the version in the filename of the .pc. But yes that
tracker-miner.pc gets generated at configure time.

I wonder if in a few years libsystemd.pc should have been
libsystemd-1.0.pc because a libsystemd-2.0.pc became needed?

ps. In GLib this isn't being done with a cp in Makefile.am and yet
other projects (dconf) don't do API versioning with the .pc filename.

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJVAbwgAAoJEEP2NSGEz4aD5VUIAIQ4D+sQfJjpig7tOCwphjdB
jyqeZINx28mwUCbKLUCFubieYAKcOoA964fJFpvE6TF6mduv1H7KVZ7LXwhXz552
PaTj182PT3J4lqhB3/lzUg9JzaaKqdHyeDkexY06w5hrAjY5QxAhkMUZFLHZr6HG
bKJN++8UZj4eicSxVkdx90pa3jOkkD0KHWuqsLgcJ0WVdnTs1X0JDKxz3yeUb6sb
qrekyp7I3weWcF3HMb6Mipy/NzzclvC5OKMhlPwP4nE6CHwzFCxBvzkFDsc9W55l
sAZPw0/Yda6BpnNVnplgCCQgiRMoriq5qgXf3pfpilXF/5bOi6c+7LDqXtyex5I=
=FF7A
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] minimal required units

[Aaron_Wright]

Andrei Borzenkov  wrote on 03/11/2015 08:47:43 PM:

> From: Andrei Borzenkov 
> To: aaron_wri...@selinc.com
> Cc: systemd-devel@lists.freedesktop.org
> Date: 03/11/2015 08:47 PM
> Subject: Re: [systemd-devel] minimal required units
> 
> В Wed, 11 Mar 2015 12:02:29 -0700
> aaron_wri...@selinc.com пишет:
> 
> > I'm trying to make an embedded device, and I would like to start with 
the 
> > minimal setup as possible. Are there some units that are required by 
> > systemd?
> > I ask because systemd is complaining about a missing rescue.target 
unit, 
> 
> When does it do it?

It was doing this because my default unit was not set correctly. But that 
isn't really the question. The question is, what units are required by 
systemd? How can I figure that out? It seems like rescue.target, 
local-fs.target, and local-fs-pre.target are required, but I've only 
discovered that after trial and error. I know the systemd.special man page 
lists a ton of special units, but it seems that not all of them are 
required. Right? Well, which ones are? I feel like I need to look through 
the code to see when a hardcoded unit is referenced, like rescue.target 
was, that I don't know about.

My device doesn't have many of the same requirements of a full desktop or 
server Linux, so I'm trying to strip out things from systemd, unit wise, 
that I don't want or need. I've customized sysinit.target and basic.target 
to just reference the units I want. And that seems to be going smooth, but 
it appears there are other units, that I didn't know about that are 
required, but that aren't documented as such (that I could find). This 
scares me a bit.
 
> 
> > but I don't list rescue.target as a dependency of any other unit.
> > However, grep tells me that /usr/lib/systemd/systemd contains the 
> > "rescue.target" string, which worries me. Is there a list of all the 
units 
> > that are required, even though no other unit lists them?

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

Re: [systemd-devel] initrd mount wrongly unmounted during bootup

[Aaron_Wright]

Andrei Borzenkov  wrote on 03/11/2015 08:44:28 PM:

> From: Andrei Borzenkov 
> To: aaron_wri...@selinc.com
> Cc: systemd-devel@lists.freedesktop.org
> Date: 03/11/2015 08:44 PM
> Subject: Re: [systemd-devel] initrd mount wrongly unmounted during 
bootup
> 
> В Wed, 11 Mar 2015 11:26:52 -0700
> aaron_wri...@selinc.com пишет:
> 
> > I'm working with an embedded device that mounts / and /var in initrd. 
It 
> > then switches root and fires up systemd. Early in the boot, after 
paths 
> > target, /var gets unmounted. I want systemd to not do that, but I 
can't 
> > figure out how to stop it.
> > I would like systemd to leave /var mounted, but still unmount it 
during 
> > shutdown. I would rather not move the mounting of /var out of initrd. 
Is 
> > this possible?
> > I'm trying to use a very stripped down systemd. As minimal as 
possible. 
> 
> Do you use udev in initrd?
> 

No. initrd is a custom script I wrote, and it mounts devtmpfs for its 
devices.

> > I'm using systemd-219. The logs say that var.mount is bound to an 
inactive 
> > unit, and it is stopping too. I assume that is why /var gets 
unmounted, 
> > but I don't know what to do to stop it. There is no /etc/fstab file. 
There 
> > is no var.mount file.
> > I assume I'm either missing something simple, or it is not possible.
> 
> Did you try this commit?
> 
> 
> commit 628c89cc68ab96fce2de7ebba5933725d147aecc
> ...snip...
> 

I was finally able to get /var to stay mounted when I included the 
local-fs.target and local-fs-pre.target units on the device. Apparently 
they are used magically by systemd. I'm not sure why or how, but it does 
finally work, so I'm happy. This leads to my other question about what 
units are required. I'll continue on that discussion on that thread. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is there a plan for NIC teaming support ?

[Christian Seiler]

Am 2015-03-12 15:29, schrieb Dax Kelson:

> Could you please explain (or link to description of) what teamd can
> do that bonding cannot?

Table, info, benchmarks here:

http://rhelblog.redhat.com/2014/06/23/team-driver/ [2]


On a side note, out of curiosity: does teamd support ARP monitoring
if the interface is added to a bridge? The bonding driver doesn't and
this is something that always bothered me.

Christian

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

Re: [systemd-devel] is there a plan for NIC teaming support ?

[Dax Kelson]

On Mar 12, 2015 7:21 AM, "Andrei Borzenkov"  wrote:
>
>
> Could you please explain (or link to description of) what teamd can do
> that bonding cannot?

Table, info, benchmarks here:

http://rhelblog.redhat.com/2014/06/23/team-driver/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Michael Biebl]

2015-03-12 8:27 GMT+01:00 Jeff Waugh :
> On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
>  wrote:
>> What does this fix Jeff, could you please explain?
>
> Here's the relevant part of a pkg-config file produced during make:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=/usr/lib
> includedir=/usr/include
>
> Versus during configure:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Which disproportionately affects cross-compiling and similar build situations.

Why is the configure produced .pc file better for suited for cross-compilation?
I must be missing something here.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to factory reset?

[Tom Gundersen]

On Thu, Mar 12, 2015 at 2:41 PM, Andrei Borzenkov  wrote:
> On Thu, Mar 12, 2015 at 4:24 PM, David Herrmann  wrote:
>> Hi
>>
>> On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov  
>> wrote:
>>> On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann  
>>> wrote:
>> With systemd-boot, there will be no config to sign:
>>   
>> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
>>
>
> How exactly putting files in a container solves the problem that they
> are not signed? This is not quite obvious from blog post.

 The config/etc. snippets are now part of the _signed_ EFI binary,
 which is always verified by the firmware. Therefore, we don't need to
 verify the other snippets separately.
>>>
>>> Where signing key comes from? Is this key generated by user on end
>>> system and enrolled in firmware?
>>
>> This is the key used by EFI secure boot. We don't change the semantics
>> in any way.
>> (yes, the key can be provided by the machine owner and stored in
>> firmware, please see EFI specs for information)
>>
>
> I know how secure boot works. You misunderstand the question.
>
> initrd and cmdline are volatile and generated on end-user system. So
> your container must be signed on end user system. End user obviously
> does not have Microsoft or vendor private keys to sign your container,
> so end user must manage own keys. Apparently, it is not quite as
> simple, otherwise we would not need to invent shim in the first place.
>
> So how do you envision signing of container in practice?

In case this was not clear: we envision signed containers (including
static cmdline and initrd) being provided by the vendor. This means we
need general purpose initrd's and cmdline's that will work without
modification on generic systems (which dracut can give us).

If people want to roll their own initrd/commandline and still use
secure boot, they can still do that, but then they have to sign it
themselves (with their own key, which they must enroll, etc).

Cheers,

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

Re: [systemd-devel] How to factory reset?

[David Herrmann]

Hi

On Thu, Mar 12, 2015 at 2:41 PM, Andrei Borzenkov  wrote:
> initrd and cmdline are volatile and generated on end-user system. So
> your container must be signed on end user system. End user obviously
> does not have Microsoft or vendor private keys to sign your container,
> so end user must manage own keys. Apparently, it is not quite as
> simple, otherwise we would not need to invent shim in the first place.

The signed EFI binary is distributed by your
distribution/vendor/key-owner. The machine-owner is responsible of
putting the key of your vendor into the firmware.

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

Re: [systemd-devel] How to factory reset?

[Andrei Borzenkov]

On Thu, Mar 12, 2015 at 4:24 PM, David Herrmann  wrote:
> Hi
>
> On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov  wrote:
>> On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann  
>> wrote:
> With systemd-boot, there will be no config to sign:
>   
> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
>

 How exactly putting files in a container solves the problem that they
 are not signed? This is not quite obvious from blog post.
>>>
>>> The config/etc. snippets are now part of the _signed_ EFI binary,
>>> which is always verified by the firmware. Therefore, we don't need to
>>> verify the other snippets separately.
>>
>> Where signing key comes from? Is this key generated by user on end
>> system and enrolled in firmware?
>
> This is the key used by EFI secure boot. We don't change the semantics
> in any way.
> (yes, the key can be provided by the machine owner and stored in
> firmware, please see EFI specs for information)
>

I know how secure boot works. You misunderstand the question.

initrd and cmdline are volatile and generated on end-user system. So
your container must be signed on end user system. End user obviously
does not have Microsoft or vendor private keys to sign your container,
so end user must manage own keys. Apparently, it is not quite as
simple, otherwise we would not need to invent shim in the first place.

So how do you envision signing of container in practice?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to factory reset?

[David Herrmann]

Hi

On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov  wrote:
> On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann  wrote:
 With systemd-boot, there will be no config to sign:
   
 https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/

>>>
>>> How exactly putting files in a container solves the problem that they
>>> are not signed? This is not quite obvious from blog post.
>>
>> The config/etc. snippets are now part of the _signed_ EFI binary,
>> which is always verified by the firmware. Therefore, we don't need to
>> verify the other snippets separately.
>
> Where signing key comes from? Is this key generated by user on end
> system and enrolled in firmware?

This is the key used by EFI secure boot. We don't change the semantics
in any way.
(yes, the key can be provided by the machine owner and stored in
firmware, please see EFI specs for information)

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

Re: [systemd-devel] is there a plan for NIC teaming support ?

[Andrei Borzenkov]

On Thu, Mar 12, 2015 at 1:08 PM, Michal Sekletar  wrote:
> On Thu, Mar 05, 2015 at 05:41:55AM +0100, Branko wrote:
>> I have a need to put my NICs in "RAID0" so to speak, but according
>> to materials I have found on net I can't use NIC bonding driver
>> because I would need LACP (IEEE whatever) aware L2 switch, so I was
>> refered to teaming driver, which should be ( if those folks is to be
>> believed) replacing bond driver in future.
>>
>> Since systemd doesn't support teaming ( teaming module + libeteam),
>> I had to scotchstape it together under systemd and it was major
>> PITA.
>>
>> libteam doesn't seem to complicated to be included as a module in
>> systemd, which should take away most of the headaches...
>
> I started looking into providing teaming support in networkd. What I am
> currently able to do (not much btw) is to create team netdev and
> enslave interfaces. Everything else is done via GeNetlink and sd-rtnl doesn't
> support that. Also even the most basic balance-rr mode doesn't work without
> teamd instance running. Thus naturally I wanted to use libteam, problem is 
> that
> still quite a lot of logic is implemented in teamd daemon and not in
> library.
>

Could you please explain (or link to description of) what teamd can do
that bonding cannot?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to factory reset?

[Andrei Borzenkov]

On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann  wrote:
> Hi
>
> On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov  wrote:
>> В Wed, 11 Mar 2015 18:50:23 +0100
>> Kay Sievers  пишет:
>>
>>> On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy  
>>> wrote:
>>> > On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger  
>>> > wrote:
>>> >>> If you're concerned about bootloader configuration modification as a
>>> >>> threat vector, then it needs to go on an encrypted volume. This
>>> >>> suggests an initial bootloader configuration that only enables the
>>> >>> user to supply a passphrase/key file to unlock that volume, and then
>>> >>> load a new bootloader configuration file.
>>> >>
>>> >> I am still hoping secure boot and sd-boot will solve this issue
>>> >> mid-term by making sure all the early boot components are signed
>>> >> properly.
>>> >
>>> > The bootloader configuration files aren't signed. Maybe the should be.
>>>
>>> With systemd-boot, there will be no config to sign:
>>>   
>>> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
>>>
>>
>> How exactly putting files in a container solves the problem that they
>> are not signed? This is not quite obvious from blog post.
>
> The config/etc. snippets are now part of the _signed_ EFI binary,
> which is always verified by the firmware. Therefore, we don't need to
> verify the other snippets separately.

Where signing key comes from? Is this key generated by user on end
system and enrolled in firmware?

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

Re: [systemd-devel] overrride env variable

[David Herrmann]

Hi

On Thu, Mar 12, 2015 at 12:33 PM, Reindl Harald  wrote:
>
>
> Am 12.03.2015 um 12:24 schrieb Vasiliy Tolstov:
>>
>> 2015-03-12 14:10 GMT+03:00 Simon McVittie
>> :
>>>
>>> SYSTEMD.EXEC(5)  systemd.exec
>>>
>>> NAME
>>> systemd.exec - Execution environment configuration
>>> ...
>>> EnvironmentFile=
>>> ...
>>> Settings from these files override settings made with
>>> Environment=. If the same variable is set twice from these files,
>>> the files will be read in the order they are specified and the
>>> later setting will override the earlier setting.
>>
>>
>>
>> Thanks, i can't find this is help of systemd.service help
[...]
> maybe it should have a empty line before to be a own paragraph

Makes sense, committed!

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

Re: [systemd-devel] overrride env variable

[Reindl Harald]

Am 12.03.2015 um 12:24 schrieb Vasiliy Tolstov:

2015-03-12 14:10 GMT+03:00 Simon McVittie :

SYSTEMD.EXEC(5)  systemd.exec

NAME
systemd.exec - Execution environment configuration
...
EnvironmentFile=
...
Settings from these files override settings made with
Environment=. If the same variable is set twice from these files,
the files will be read in the order they are specified and the
later setting will override the earlier setting.



Thanks, i can't find this is help of systemd.service help


surely, 
http://www.freedesktop.org/software/systemd/man/systemd.exec.html as 
well as "man systemd.exec" with systemd-208-30.fc20.x86_64 contain 
exactly that at the end


maybe it should have a empty line before to be a own paragraph




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

Re: [systemd-devel] overrride env variable

[Vasiliy Tolstov]

2015-03-12 14:10 GMT+03:00 Simon McVittie :
> SYSTEMD.EXEC(5)  systemd.exec
>
> NAME
>systemd.exec - Execution environment configuration
> ...
>EnvironmentFile=
> ...
>Settings from these files override settings made with
>Environment=. If the same variable is set twice from these files,
>the files will be read in the order they are specified and the
>later setting will override the earlier setting.


Thanks, i can't find this is help of systemd.service help.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] overrride env variable

[Simon McVittie]

On 12/03/15 10:45, Vasiliy Tolstov wrote:
> If service file have Environment and EnvironmentFile in which order it
> parsed and does it possible to define via Environment variables
> default and override it via EnvironmentFile ?

SYSTEMD.EXEC(5)  systemd.exec

NAME
   systemd.exec - Execution environment configuration
...
   EnvironmentFile=
...
   Settings from these files override settings made with
   Environment=. If the same variable is set twice from these files,
   the files will be read in the order they are specified and the
   later setting will override the earlier setting.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Simon McVittie]

On 12/03/15 07:50, Umut Tezduyar Lindskog wrote:
> Ok! I have another problem with pc files but I solve it downstream.
> When I configure systemd with --configure=/usr and set the DESTDIR to
> my host path, the pc files don't have the DESTDIR extension. I solve
> it manually by 'sed'ding the files after installation.

.pc files intentionally do not contain the DESTDIR in their paths.
DESTDIR should never be hard-coded into any installed file, since that
would not work in situations where you have installed the headers,
libraries etc. in their intended target path /usr/include,
/usr/lib{,32,64,/MULTIARCH} etc., as is done on dpkg, rpm etc. systems.

The DESTDIR is for "staged installs" as used by dpkg/rpm. Here is a
massively oversimplified version of how dpkg packages are built:

./configure --prefix=/usr
make
make install DESTDIR=$(pwd)/debian/tmp
tar -C $(pwd)/debian/tmp -czf data.tar.gz .
# now data.tar.gz contains e.g. ./usr/bin/foo, ./usr/include/foo.h,
# ./usr/lib/i386-linux-gnu/libfoo.so*

and most other packaging systems are similar.

-- 
Simon McVittie
Collabora Ltd. 

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

[systemd-devel] overrride env variable

[Vasiliy Tolstov]

Hello.
If service file have Environment and EnvironmentFile in which order it
parsed and does it possible to define via Environment variables
default and override it via EnvironmentFile ?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to factory reset?

[Kay Sievers]

On Thu, Mar 12, 2015 at 11:30 AM, David Herrmann  wrote:
> On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov  wrote:
>> В Wed, 11 Mar 2015 18:50:23 +0100
>> Kay Sievers  пишет:
>>
>>> On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy  
>>> wrote:
>>> > On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger  
>>> > wrote:
>>> >>> If you're concerned about bootloader configuration modification as a
>>> >>> threat vector, then it needs to go on an encrypted volume. This
>>> >>> suggests an initial bootloader configuration that only enables the
>>> >>> user to supply a passphrase/key file to unlock that volume, and then
>>> >>> load a new bootloader configuration file.
>>> >>
>>> >> I am still hoping secure boot and sd-boot will solve this issue
>>> >> mid-term by making sure all the early boot components are signed
>>> >> properly.
>>> >
>>> > The bootloader configuration files aren't signed. Maybe the should be.
>>>
>>> With systemd-boot, there will be no config to sign:
>>>   
>>> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
>>>
>>
>> How exactly putting files in a container solves the problem that they
>> are not signed? This is not quite obvious from blog post.
>
> The config/etc. snippets are now part of the _signed_ EFI binary,
> which is always verified by the firmware. Therefore, we don't need to
> verify the other snippets separately.

http://people.freedesktop.org/~kay/efistub.txt

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

Re: [systemd-devel] How to factory reset?

[David Herrmann]

Hi

On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov  wrote:
> В Wed, 11 Mar 2015 18:50:23 +0100
> Kay Sievers  пишет:
>
>> On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy  
>> wrote:
>> > On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger  
>> > wrote:
>> >>> If you're concerned about bootloader configuration modification as a
>> >>> threat vector, then it needs to go on an encrypted volume. This
>> >>> suggests an initial bootloader configuration that only enables the
>> >>> user to supply a passphrase/key file to unlock that volume, and then
>> >>> load a new bootloader configuration file.
>> >>
>> >> I am still hoping secure boot and sd-boot will solve this issue
>> >> mid-term by making sure all the early boot components are signed
>> >> properly.
>> >
>> > The bootloader configuration files aren't signed. Maybe the should be.
>>
>> With systemd-boot, there will be no config to sign:
>>   
>> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
>>
>
> How exactly putting files in a container solves the problem that they
> are not signed? This is not quite obvious from blog post.

The config/etc. snippets are now part of the _signed_ EFI binary,
which is always verified by the firmware. Therefore, we don't need to
verify the other snippets separately.

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

Re: [systemd-devel] is there a plan for NIC teaming support ?

[Michal Sekletar]

On Thu, Mar 05, 2015 at 05:41:55AM +0100, Branko wrote:
> I have a need to put my NICs in "RAID0" so to speak, but according
> to materials I have found on net I can't use NIC bonding driver
> because I would need LACP (IEEE whatever) aware L2 switch, so I was
> refered to teaming driver, which should be ( if those folks is to be
> believed) replacing bond driver in future.
> 
> Since systemd doesn't support teaming ( teaming module + libeteam),
> I had to scotchstape it together under systemd and it was major
> PITA.
> 
> libteam doesn't seem to complicated to be included as a module in
> systemd, which should take away most of the headaches...

I started looking into providing teaming support in networkd. What I am
currently able to do (not much btw) is to create team netdev and
enslave interfaces. Everything else is done via GeNetlink and sd-rtnl doesn't
support that. Also even the most basic balance-rr mode doesn't work without
teamd instance running. Thus naturally I wanted to use libteam, problem is that
still quite a lot of logic is implemented in teamd daemon and not in
library.

I envision this to work in a following way. networkd will create netdev and
enslave interfaces, then it will call systemd dbus API to create
instance of teamd for the team device. networkd will then communicate with teamd
instance over dbus. Problem I am facing here is not very well designed teamd
dbus interface, i.e. you have to pass json config string as parameter. I am not
sure we want to get into business of stamping out some json to variable
and then passing that string to teamd. It would be much nicer to have v2 of
teamd dbus interface. I had a brief discussion about it with teamd maintainer
and as always patches are welcome.

Michal

> 
> 
> 
> ___
> 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] build: generate pkg-config files during configure

[Kay Sievers]

On Thu, Mar 12, 2015 at 5:09 AM, Lucas De Marchi
 wrote:
> On Tue, Mar 10, 2015 at 3:04 PM, Jeff Waugh  wrote:
>> Generate pkg-config files during configure as God (Havoc) intended. This 
>> fixes
>> all of systemd's pkg-config files when cross-compiling (and possibly other 
>> use
>> cases).

> Kay, please take a look on this. There's a similar patch pending to
> kmod on [1]. I'm still not sure what exactly it's fixing... seems like
> just that it would not replace/expand all occurrences of the
> variables...

AC_CONFIG_FILES is usually meant to create/prepare autoconf/automake
related files needed for the build process, and not to produce plain
package content to ship.

Not that quoting autoconf manuals would make the autotools mess any
better, but there is also this. :)

"Similarly, you should not rely on AC_CONFIG_FILES to replace bindir
and friends in your shell scripts and other files; instead, let make
manage their replacement. For instance Autoconf ships templates of its
shell scripts ending with ‘.in’, and uses a makefile snippet similar
to the following to build scripts like autoheader and autom4te:

edit = sed \
   -e 's|@bindir[@]|$(bindir)|g' \
   -e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \
   -e 's|@prefix[@]|$(prefix)|g'

autoheader autom4te: Makefile
rm -f $@ $@.tmp
srcdir=''; \
test -f ./$@.in || srcdir=$(srcdir)/; \
$(edit) $${srcdir}$@.in >$@.tmp
chmod +x $@.tmp
chmod a-w $@.tmp
mv $@.tmp $@

autoheader: $(srcdir)/autoheader.in
autom4te: $(srcdir)/autom4te.in"

http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables

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

Re: [systemd-devel] How to factory reset?

[Chris Murphy]

On Wed, Mar 11, 2015 at 1:46 PM, Kay Sievers  wrote:
> On Wed, Mar 11, 2015 at 7:45 PM, Chris Murphy  wrote:
>> On Wed, Mar 11, 2015 at 11:50 AM, Kay Sievers  wrote:
>>
>>>There is no
>>> point in handling raid without native firmware support; manual
>>> intervention is needed anyway on these systems if things go wrong, and
>>> that step can just re-create the ESP content if needed.
>>
>> I don't agree with this. OS X supports this for 10+ years on EFI with
>> software raid, and no such thing as firmware raid.
>
> It is the Apple firmware and not OS X. The firmware supports all sorts
> of Apple specific things like HFS+ and drivers for the WiFi hardware.
> And that is exactly what I meant with native support. :)

Apple's raid support is not enabled by Apple firmware. That Apple's
firmware understands HFS+ is completely beside the point. They could
put their bootloader on the ESP, it's the bootloader that understands
Apple raid, finds and loads the kernel. The reason the firmware has
HFS+ support baked in is the HFS+ volume header contains a hint for
the active system, rather than depending on NVRAM.

Back on Linux though, any dependency on proprietary firmware raid,
means Btrfs raid cannot be used at all on those drives so I don't see
how this is a general purpose solution. BIOS permits a superior
solution.


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

Re: [systemd-devel] How to factory reset?

[Chris Murphy]

On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger  wrote:
>> If you're concerned about bootloader configuration modification as a
>> threat vector, then it needs to go on an encrypted volume. This
>> suggests an initial bootloader configuration that only enables the
>> user to supply a passphrase/key file to unlock that volume, and then
>> load a new bootloader configuration file.
>
> I am still hoping secure boot and sd-boot will solve this issue
> mid-term by making sure all the early boot components are signed
> properly.

The bootloader configuration files aren't signed. Maybe the should be.
And maybe done away with in favor of dynamic discovery and "hot" keys
for indicating common boot options. Any general purpose solution
should account for degraded bootable raid, which means each ESP needs
to be identical. Either each ESP bootloader looks to a single location
on raid for configuration, or uses dynamic discovery, or some system
of sequentially updating each ESP needs to be devised.


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

Re: [systemd-devel] [PATCH] vconsole-setup: check error of child process

[David Herrmann]

Hi

On Wed, Mar 11, 2015 at 5:12 PM, Lucas De Marchi
 wrote:
> On Wed, Mar 11, 2015 at 12:55 PM, David Herrmann  
> wrote:
>> Hi
>>
>> On Tue, Mar 10, 2015 at 8:56 PM,   wrote:
>>> From: Lucas De Marchi 
>>>
>>> If we don't check the error of the child process, systemd-vconsole-setup
>>> would exit with 0 even if it could not really setup the console.
>>>
>>> For a simple test, move loadkeys elsewhere and execute
>>> systemd-vconsole-setup:
>>>
>>> [root@localhost ~]# strace -f -e execve 
>>> /usr/lib/systemd/systemd-vconsole-setup
>>> execve("/usr/lib/systemd/systemd-vconsole-setup", 
>>> ["/usr/lib/systemd/systemd-vconsol"...], [/* 15 vars */]) = 0
>>> Process 171 attached
>>> [pid   171] execve("/usr/bin/loadkeys", ["/usr/bin/loadkeys", "-q", 
>>> "-C", "/dev/tty0", "br-abnt2"], [/* 15 vars */]) = -1 ENOENT (No such file 
>>> or directory)
>>> [pid   171] +++ exited with 1 +++
>>> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171, 
>>> si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
>>> +++ exited with 0 +++
>>>
>>> Now systemd-vconsole-setup exits with EXIT_FAILURE if the child failed
>>> for whatever reason.
>>> ---
>>>  src/vconsole/vconsole-setup.c | 17 -
>>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
>>> index bf681d9..601ca4a 100644
>>> --- a/src/vconsole/vconsole-setup.c
>>> +++ b/src/vconsole/vconsole-setup.c
>>> @@ -304,8 +304,12 @@ int main(int argc, char **argv) {
>>>  return EXIT_FAILURE;
>>>  }
>>>
>>> -if (font_pid > 0)
>>> -wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
>>> +if (font_pid > 0) {
>>> +r = wait_for_terminate_and_warn(KBD_SETFONT, font_pid, 
>>> true);
>>> +if (r != 0)
>>> +return EXIT_FAILURE;
>>> +}
>>> +
>>
>> Looks mostly good. However, I'd prefer if we continue on "r > 0" but
>> remember the error for later. This way, we still try loading the right
>> keymap even though the font might have failed.
>
> Is there any reason to continue on r > 0 but not on r < 0? I'm ok with
> changing the current behavior, but just like to know which one is
> better.

Yeah, not sure here. For most helpers here r<0 means serious error
(fork() failed, etc.), r>0 means just the spawned application failed.
I guess we should continue for all !=0. That is, don't return
prematurely at all.

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

Re: [systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope

[David Herrmann]

Hi

On Fri, Feb 27, 2015 at 8:11 PM, Kay Sievers  wrote:
> On Fri, Feb 27, 2015 at 6:12 PM, Marcel Holtmann  wrote:
  CC   src/boot/efi/splash.o
 src/boot/efi/splash.c: In function ‘graphics_splash’:
 src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’ 
 of ‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
 EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
 ^
 In file included from /usr/include/efi/efi.h:39:0,
 from src/boot/efi/splash.c:18:
 /usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
   UINT8 Blue;
 ^
>>>
>>> That patch removes the initializer?
>>
>> indeed, if you do not have background provided, then it is undefined. And 
>> also in the Apple case, the Reserved field would not be set. Anyway, I have 
>> no idea on how to fix this compiler warning the right way.
>>
>> Alternatively doing something like this shuts it up as well:
>>
>>  EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const 
>> EFI_GRAPHICS_OUTPUT_BLT_PIXEL *background) {
>> -EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = {};
>> +EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { 0x00, };
>
> I guess we should just add -Wno-missing-field-initializers, like we do
> for the systemd code?

For completeness, this was done in:

commit 6a333238366b3f28124f724ad607a0f00f41a328
Author: Zbigniew Jędrzejewski-Szmek 
Date:   Fri Feb 27 17:26:48 2015 -0500

build-sys: use -Wno-missing-field-initializers for efi stuff

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

[systemd-devel] [PATCH 6/6] refactor in_addr_to_string()

[Shawn Landden]

---
 src/resolve/resolved-dns-rr.c |  6 ++
 src/shared/in-addr-util.c | 32 +++-
 2 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/src/resolve/resolved-dns-rr.c b/src/resolve/resolved-dns-rr.c
index 78d9e4a..a73ccd7 100644
--- a/src/resolve/resolved-dns-rr.c
+++ b/src/resolve/resolved-dns-rr.c
@@ -527,13 +527,11 @@ int dns_resource_record_to_string(const DnsResourceRecord 
*rr, char **ret) {
 break;
 
 case DNS_TYPE_A: {
-_cleanup_free_ char *x = NULL;
-
-r = in_addr_to_string(AF_INET, (const union in_addr_union*) 
&rr->a.in_addr, &x);
+r = in_addr_to_string(AF_INET, (const union in_addr_union*) 
&rr->a.in_addr, &t);
 if (r < 0)
 return r;
 
-s = strjoin(k, " ", x, NULL);
+s = strjoin(k, " ", t, NULL);
 if (!s)
 return -ENOMEM;
 break;
diff --git a/src/shared/in-addr-util.c b/src/shared/in-addr-util.c
index b7532a6..f23b343 100644
--- a/src/shared/in-addr-util.c
+++ b/src/shared/in-addr-util.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "in-addr-util.h"
+#include "socket-util.h"
 
 int in_addr_is_null(int family, const union in_addr_union *u) {
 assert(u);
@@ -179,31 +180,20 @@ int in_addr_prefix_next(int family, union in_addr_union 
*u, unsigned prefixlen)
 }
 
 int in_addr_to_string(int family, const union in_addr_union *u, char **ret) {
-char *x;
-size_t l;
+union sockaddr_union sa;
 
-assert(u);
-assert(ret);
+sa.sa.sa_family = family;
 
-if (family == AF_INET)
-l = INET_ADDRSTRLEN;
-else if (family == AF_INET6)
-l = INET6_ADDRSTRLEN;
-else
-return -EAFNOSUPPORT;
+if (sa.sa.sa_family == AF_INET) {
+sa.in.sin_addr = u->in;
 
-x = new(char, l);
-if (!x)
-return -ENOMEM;
+return sockaddr_pretty(&sa.sa, (socklen_t)sizeof(sa.in),  
false, false, ret);
+} else if (family == AF_INET6) {
+sa.in6.sin6_addr = u->in6;
 
-errno = 0;
-if (!inet_ntop(family, u, x, l)) {
-free(x);
-return errno ? -errno : -EINVAL;
-}
-
-*ret = x;
-return 0;
+return sockaddr_pretty(&sa.sa, (socklen_t)sizeof(sa.in6), 
false, false, ret);
+} else
+return -EAFNOSUPPORT;
 }
 
 struct in6_addr in_addr_to_in6_addr(struct in_addr ipv4) {
-- 
2.2.1.209.g41e5f3a

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

[systemd-devel] [PATCH 4/6] make in_addr_from_string() accept ipv4 addresses even when using AF_INET6

[Shawn Landden]

if we are going to have a function to fix up the deficiencies of
inet_pton(), better go all the way.
---
 src/shared/in-addr-util.c | 17 +
 src/shared/in-addr-util.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/src/shared/in-addr-util.c b/src/shared/in-addr-util.c
index ade4012..b7532a6 100644
--- a/src/shared/in-addr-util.c
+++ b/src/shared/in-addr-util.c
@@ -206,7 +206,18 @@ int in_addr_to_string(int family, const union 
in_addr_union *u, char **ret) {
 return 0;
 }
 
+struct in6_addr in_addr_to_in6_addr(struct in_addr ipv4) {
+struct in6_addr r = { { {
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xFF, 0xFF, 0, 0, 0, 0
+} } };
+
+r.s6_addr32[3] = ipv4.s_addr;
+
+return r;
+}
+
 int in_addr_from_string(int family, const char *s, void *ret) {
+struct in_addr v4mapped;
 
 assert(s);
 assert(ret);
@@ -214,6 +225,12 @@ int in_addr_from_string(int family, const char *s, void 
*ret) {
 if (!IN_SET(family, AF_INET, AF_INET6))
 return -EAFNOSUPPORT;
 
+if (family == AF_INET6)
+if (inet_pton(AF_INET, s, &v4mapped) == 1) {
+*((struct in6_addr *)ret) = 
in_addr_to_in6_addr(v4mapped);
+return 0;
+}
+
 errno = 0;
 if (inet_pton(family, s, ret) <= 0)
 return errno ? -errno : -EINVAL;
diff --git a/src/shared/in-addr-util.h b/src/shared/in-addr-util.h
index 8b3a07c..f140ec9 100644
--- a/src/shared/in-addr-util.h
+++ b/src/shared/in-addr-util.h
@@ -37,6 +37,7 @@ int in_addr_equal(int family, const union in_addr_union *a, 
const union in_addr_
 int in_addr_prefix_intersect(int family, const union in_addr_union *a, 
unsigned aprefixlen, const union in_addr_union *b, unsigned bprefixlen);
 int in_addr_prefix_next(int family, union in_addr_union *u, unsigned 
prefixlen);
 int in_addr_to_string(int family, const union in_addr_union *u, char **ret);
+struct in6_addr in_addr_to_in6_addr(struct in_addr ipv4) _const_;
 int in_addr_from_string(int family, const char *s, void *ret);
 int in_addr_from_string_auto(const char *s, int *family, union in_addr_union 
*ret);
 unsigned char in_addr_netmask_to_prefixlen(const struct in_addr *addr);
-- 
2.2.1.209.g41e5f3a

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

[systemd-devel] [PATCH 2/6] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c

[Shawn Landden]

---
 src/udev/udev-builtin-usb_id.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/udev/udev-builtin-usb_id.c b/src/udev/udev-builtin-usb_id.c
index 6516d93..3c15b2f 100644
--- a/src/udev/udev-builtin-usb_id.c
+++ b/src/udev/udev-builtin-usb_id.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "udev.h"
 
@@ -179,21 +180,20 @@ static int dev_if_packed_info(struct udev_device *dev, 
char *ifs_str, size_t len
 
 ifs_str[0] = '\0';
 while (pos < size && strpos+7 < len-2) {
-struct usb_interface_descriptor *desc;
+unsigned char *desc = &buf[pos];
 char if_str[8];
 
-desc = (struct usb_interface_descriptor *) &buf[pos];
-if (desc->bLength < 3)
+if (desc[offsetof(struct usb_interface_descriptor, bLength)] < 
3)
 break;
-pos += desc->bLength;
+pos += desc[offsetof(struct usb_interface_descriptor, 
bLength)];
 
-if (desc->bDescriptorType != USB_DT_INTERFACE)
+if (desc[offsetof(struct usb_interface_descriptor, 
bDescriptorType)] != USB_DT_INTERFACE)
 continue;
 
 if (snprintf(if_str, 8, ":%02x%02x%02x",
- desc->bInterfaceClass,
- desc->bInterfaceSubClass,
- desc->bInterfaceProtocol) != 7)
+ desc[offsetof(struct usb_interface_descriptor, 
bInterfaceClass)],
+ desc[offsetof(struct usb_interface_descriptor, 
bInterfaceSubClass)],
+ desc[offsetof(struct usb_interface_descriptor, 
bInterfaceProtocol)]) != 7)
 continue;
 
 if (strstr(ifs_str, if_str) != NULL)
-- 
2.2.1.209.g41e5f3a

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

[systemd-devel] [PATCH] vconsole-setup: check error of child process

[lucas . de . marchi]

From: Lucas De Marchi 

If we don't check the error of the child process, systemd-vconsole-setup
would exit with 0 even if it could not really setup the console.

For a simple test, move loadkeys elsewhere and execute
systemd-vconsole-setup:

[root@localhost ~]# strace -f -e execve 
/usr/lib/systemd/systemd-vconsole-setup
execve("/usr/lib/systemd/systemd-vconsole-setup", 
["/usr/lib/systemd/systemd-vconsol"...], [/* 15 vars */]) = 0
Process 171 attached
[pid   171] execve("/usr/bin/loadkeys", ["/usr/bin/loadkeys", "-q", 
"-C", "/dev/tty0", "br-abnt2"], [/* 15 vars */]) = -1 ENOENT (No such file or 
directory)
[pid   171] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171, 
si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

Now systemd-vconsole-setup exits with EXIT_FAILURE if the child failed
for whatever reason.
---
 src/vconsole/vconsole-setup.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..601ca4a 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -304,8 +304,12 @@ int main(int argc, char **argv) {
 return EXIT_FAILURE;
 }
 
-if (font_pid > 0)
-wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (font_pid > 0) {
+r = wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (r != 0)
+return EXIT_FAILURE;
+}
+
 
 r = keymap_load(vc, vc_keymap, vc_keymap_toggle, utf8, &keymap_pid);
 if (r < 0) {
@@ -313,10 +317,13 @@ int main(int argc, char **argv) {
 return EXIT_FAILURE;
 }
 
-if (keymap_pid > 0)
-wait_for_terminate_and_warn(KBD_LOADKEYS, keymap_pid, true);
+if (keymap_pid > 0) {
+r = wait_for_terminate_and_warn(KBD_LOADKEYS, keymap_pid, 
true);
+if (r != 0)
+return EXIT_FAILURE;
+}
 
-/* Only copy the font when we started setfont successfully */
+/* Only copy the font when we executed setfont successfully */
 if (font_copy && font_pid > 0)
 font_copy_to_all_vcs(fd);
 
-- 
2.3.2

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

[systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.

[Goffredo Baroncelli]

Add a new tmpfiles.d snippets to set the NOCOW attributes for the
journal files. This allow better perfomance when the root file system
is BTRFS. Pay attention that the NOCOW flags disables the checksum and
prevent scrub to rebuild a corrupted journal.
---
 tmpfiles.d/journal-nocow.conf | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 tmpfiles.d/journal-nocow.conf

diff --git a/tmpfiles.d/journal-nocow.conf b/tmpfiles.d/journal-nocow.conf
new file mode 100644
index 000..43a4f2b
--- /dev/null
+++ b/tmpfiles.d/journal-nocow.conf
@@ -0,0 +1,12 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+# See tmpfiles.d(5) for details
+
+
+# set the journal file as NOCOW; only valid for BTRFS filesystem
+h /var/log/journal/%m - - - - +C
-- 
2.1.4

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

[systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes

[Goffredo Baroncelli]

Allow systemd-tmpfiles to set the file/directory attributes, like chattr(1)
does. Two more commands are added: 'H' and 'h' to set the attributes,
recursively and not.
---
 src/tmpfiles/tmpfiles.c | 140 
 1 file changed, 140 insertions(+)

diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..31faeb6 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "log.h"
 #include "util.h"
@@ -90,6 +91,8 @@ typedef enum ItemType {
 ADJUST_MODE = 'm', /* legacy, 'z' is identical to this */
 RELABEL_PATH = 'z',
 RECURSIVE_RELABEL_PATH = 'Z',
+SET_ATTRIB = 'h',
+RECURSIVE_SET_ATTRIB = 'H',
 } ItemType;
 
 typedef struct Item {
@@ -108,12 +111,15 @@ typedef struct Item {
 usec_t age;
 
 dev_t major_minor;
+int attrib_value;
+int attrib_mask;
 
 bool uid_set:1;
 bool gid_set:1;
 bool mode_set:1;
 bool age_set:1;
 bool mask_perms:1;
+bool attrib_set:1;
 
 bool keep_first_level:1;
 
@@ -762,6 +768,115 @@ static int path_set_acls(Item *item, const char *path) {
 return 0;
 }
 
+static int get_attrib_from_arg(Item *item) {
+static const struct { int value; char ch; } attributes[] = {
+{ FS_NOATIME_FL, 'A' },   /* do not update atime */
+{ FS_SYNC_FL, 'S' },  /* Synchronous updates */
+{ FS_DIRSYNC_FL, 'D' },   /* dirsync behaviour (directories 
only) */
+{ FS_APPEND_FL, 'a' },/* writes to file may only append */
+{ FS_COMPR_FL, 'c' }, /* Compress file */
+{ FS_NODUMP_FL, 'd' },/* do not dump file */
+{ FS_EXTENT_FL, 'e'}, /* Top of directory hierarchies*/
+{ FS_IMMUTABLE_FL, 'i' }, /* Immutable file */
+{ FS_JOURNAL_DATA_FL, 'j' }, /* Reserved for ext3 */
+{ FS_SECRM_FL, 's' }, /* Secure deletion */
+{ FS_UNRM_FL, 'u' },  /* Undelete */
+{ FS_NOTAIL_FL, 't' },/* file tail should not be merged */
+{ FS_TOPDIR_FL, 'T' },/* Top of directory hierarchies*/
+{ FS_NOCOW_FL, 'C' }, /* Do not cow file */
+{ 0, 0 }
+};
+char *p = item->argument;
+enum {
+MODE_ADD,
+MODE_DEL,
+MODE_SET
+} mode = MODE_ADD;
+unsigned long value = 0, mask = 0;
+
+if (!p) {
+log_error("\"%s\": setting ATTR need an argument", item->path);
+return -EINVAL;
+}
+
+if (*p == '+') {
+mode = MODE_ADD;
+p++;
+} else if (*p == '-') {
+mode = MODE_DEL;
+p++;
+} else  if (*p == '=') {
+mode = MODE_SET;
+p++;
+}
+
+if (!*p && mode != MODE_SET) {
+log_error("\"%s\": setting ATTR: argument is empty", 
item->path);
+return -EINVAL;
+}
+for (; *p ; p++) {
+int i;
+for (i = 0; attributes[i].ch && attributes[i].ch != *p; i++)
+;
+if (!attributes[i].ch) {
+log_error("\"%s\": setting ATTR: unknown attr '%c'", 
item->path, *p);
+return -EINVAL;
+}
+if (mode == MODE_ADD || mode == MODE_SET)
+value |= attributes[i].value;
+else
+value &= ~attributes[i].value;
+mask |= attributes[i].value;
+}
+
+if (mode == MODE_SET) {
+int i;
+for (i = 0; attributes[i].ch; i++)
+mask |= attributes[i].value;
+}
+
+assert(mask);
+
+item->attrib_mask = mask;
+item->attrib_value = value;
+item->attrib_set = true;
+
+return 0;
+
+}
+
+static int path_set_attrib(Item *item, const char *path) {
+_cleanup_close_ int fd = -1;
+int r;
+unsigned f;
+struct stat st;
+
+/* do nothing */
+if (item->attrib_mask == 0 || !item->attrib_set)
+return 0;
+
+if (lstat(path, &st) == 0 &&
+!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
+return 0;
+}
+
+fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
+
+if (fd < 0)
+return log_error_errno(errno, "Cannot open \"%s\": %m", path);
+
+f = item->attrib_value & item->attrib_mask;
+if (!S_ISDIR(st.st_mode))
+f &= ~FS_DIRSYNC_FL;
+r = change_attr_fd(fd, item->attrib_mask, f);
+if (r < 0)
+return log_error_errno(errno,
+"Can

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Umut Tezduyar Lindskog]

Ok! I have another problem with pc files but I solve it downstream.
When I configure systemd with --configure=/usr and set the DESTDIR to
my host path, the pc files don't have the DESTDIR extension. I solve
it manually by 'sed'ding the files after installation. I thought maybe
your patch solves this problem too. Thanks!


On Thu, Mar 12, 2015 at 8:27 AM, Jeff Waugh  wrote:
> On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
>  wrote:
>> What does this fix Jeff, could you please explain?
>
> Here's the relevant part of a pkg-config file produced during make:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=/usr/lib
> includedir=/usr/include
>
> Versus during configure:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Which disproportionately affects cross-compiling and similar build situations.
>
> OpenWrt includes an equivalent change for kmod (which Lucas mentioned
> as I've submitted it upstream), and without an upstream change will
> have to carry one for systemd too.
>
> Finally, a supporting appeal to authority: If you check GNOME-land,
> practically all pkg-config files are generated at configure time. :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cgtop: fix assert when not on tty

[David Herrmann]

Hi

On Wed, Mar 11, 2015 at 11:24 AM, Umut Tezduyar Lindskog
 wrote:
> systemd-cgtop --dept=1 -b -n 10 -d 0.1 | cat
>
> Assertion 'new_length >= 3' failed at src/shared/util.c:3 \
> 595, function ellipsize_mem(). Aborting.
> Aborted (core dumped)
> ---
>  src/cgtop/cgtop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied (with a small comment added).

Thanks!
David

> diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
> index 3c7ad40..46ba1aa 100644
> --- a/src/cgtop/cgtop.c
> +++ b/src/cgtop/cgtop.c
> @@ -447,7 +447,7 @@ static int display(Hashmap *a) {
>  Group *g;
>  Group **array;
>  signed path_columns;
> -unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 0;
> +unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 3;
>  char buffer[MAX3(21, FORMAT_BYTES_MAX, FORMAT_TIMESPAN_MAX)];
>
>  assert(a);
> --
> 2.1.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

Re: [systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs

[Didier Roche]

Le 10/03/2015 16:53, Lennart Poettering a écrit :

On Mon, 09.03.15 11:27, Didier Roche (didro...@ubuntu.com) wrote:


However, some file systems (seems overlayfs at least) would report a
major(st_dev) as 0 on directories and not on files. The current
path_is_mount_point() fallback logic would thus reports that every files is
a mount point. The enclosed patch introduces a second fallback to read
/proc/mounts, and ensures there is no shadowing by later mounting of parent
directories. This slower path is only used when the 2 first methods failed
to determine with assurance if the path is a mount point or not.

Humppf, I am not convinced this is really a good idea.

I mean, we use name_to_handle_at() precisely for the reason that we
don't want to parse /proc/self/mountinfo, since that is really
cumbersome if you want to do it properly, given that mounts can
obstruct other mounts and symlink/realpath complexity and stuff.

Note that the st_dev thing is the traditional way to detect whether
one crosses a file system boundary. It's used for this by tools like
cp, find,  We slightly enhance this by using name_to_handle_at(),
so that we can also detect bind mounts from file systems onto
themselves. Now, if overlayfs breaks the same file system logic of all
other tools, I am not convinced that systemd should not be broken by
it too.. It sounds surprising that we should work around this in
systemd, but not in all other tools.

Or to turn this around: instead of patching systemd the better idea
would probably be to teach overlayfs name_to_handle_at() support, so
that there's a way to detect the mount id from such a file system in a
safe way.

Hmm, where precisely did you run into problems with this?


The context is bug 
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140, where 
systemd-machine-id-commit unit is entering in failed state (the binary 
handles gracefully the fact that it can't unmount the file) on a default 
ubuntu live system (which is a squashfs/overlayfs system).


This means that a live starts in degraded mode when booted with systemd 
(mostly a cosmetic issue for sure, but we would rather avoid it). Seeing 
that the logic to check if a path is a mount point already had a 
fallback (the traditional way), I thought another one would be 
acceptable, but I understand that you were ok with the first one as it's 
the general way tools are detecting that case. I thought as Ryan told 
that glib was going to a similar approach that this fallback would be a 
little bit more considered as standard…


I agree that the best way would be to get the kernel fixed for this, I 
talked to our kernel team and it doesn't seem we would gain traction on 
having name_to_handle_at() support on overlayfs, so quite stuck on this 
for now. Maybe there is a better option?


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

Re: [systemd-devel] How to factory reset?

[Simon McVittie]

On 10/03/15 16:01, Lennart Poettering wrote:
> Yes, dbus is currently not compatible with stateless bootups. PAM is
> neither. For PAM we ship a tmpfiles snippet to work around this, for
> dbus we don't though, since kdbus kinda makes the problem go away...

In the meantime, you might be interested in
.

S

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

[systemd-devel] [PATCH] [PATCH v2] util: add rename_noreplace

[Alban Crequy]

From: Alban Crequy 

renameat2() exists since Linux 3.15 but btrfs support for the flag
RENAME_NOREPLACE was added later.

This patch implements a fallback when renameat2() returns EINVAL.
EINVAL is the error returned when the filesystem does not support one of
the flags.
---
 src/import/import-raw.c|  2 +-
 src/import/import-tar.c|  2 +-
 src/import/pull-raw.c  |  2 +-
 src/import/pull-tar.c  |  2 +-
 src/shared/copy.c  |  7 ++-
 src/shared/machine-image.c |  2 +-
 src/shared/machine-pool.c  |  2 +-
 src/shared/util.c  | 32 
 src/shared/util.h  |  2 ++
 9 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/src/import/import-raw.c b/src/import/import-raw.c
index 15e5eb2..e354023 100644
--- a/src/import/import-raw.c
+++ b/src/import/import-raw.c
@@ -245,7 +245,7 @@ static int raw_import_finish(RawImport *i) {
 (void) rm_rf_dangerous(i->final_path, false, true, false);
 }
 
-if (renameat2(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path, 
RENAME_NOREPLACE) < 0)
+if (rename_noreplace(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path) 
< 0)
 return log_error_errno(errno, "Failed to move image into 
place: %m");
 
 free(i->temp_path);
diff --git a/src/import/import-tar.c b/src/import/import-tar.c
index d5b6dad..dcbe721 100644
--- a/src/import/import-tar.c
+++ b/src/import/import-tar.c
@@ -201,7 +201,7 @@ static int tar_import_finish(TarImport *i) {
 (void) rm_rf_dangerous(i->final_path, false, true, false);
 }
 
-if (renameat2(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path, 
RENAME_NOREPLACE) < 0)
+if (rename_noreplace(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path) 
< 0)
 return log_error_errno(errno, "Failed to move image into 
place: %m");
 
 free(i->temp_path);
diff --git a/src/import/pull-raw.c b/src/import/pull-raw.c
index d1d77d5..d4b17e7 100644
--- a/src/import/pull-raw.c
+++ b/src/import/pull-raw.c
@@ -384,7 +384,7 @@ static void raw_pull_job_on_finished(PullJob *j) {
 if (r < 0)
 goto finish;
 
-r = renameat2(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path, 
RENAME_NOREPLACE);
+r = rename_noreplace(AT_FDCWD, i->temp_path, AT_FDCWD, 
i->final_path);
 if (r < 0) {
 r = log_error_errno(errno, "Failed to move RAW file 
into place: %m");
 goto finish;
diff --git a/src/import/pull-tar.c b/src/import/pull-tar.c
index 504642f..69df7af 100644
--- a/src/import/pull-tar.c
+++ b/src/import/pull-tar.c
@@ -281,7 +281,7 @@ static void tar_pull_job_on_finished(PullJob *j) {
 if (r < 0)
 goto finish;
 
-if (renameat2(AT_FDCWD, i->temp_path, AT_FDCWD, i->final_path, 
RENAME_NOREPLACE) < 0) {
+if (rename_noreplace(AT_FDCWD, i->temp_path, AT_FDCWD, 
i->final_path) < 0) {
 r = log_error_errno(errno, "Failed to rename to final 
image name: %m");
 goto finish;
 }
diff --git a/src/shared/copy.c b/src/shared/copy.c
index 0239a58..e578d03 100644
--- a/src/shared/copy.c
+++ b/src/shared/copy.c
@@ -404,7 +404,12 @@ int copy_file_atomic(const char *from, const char *to, 
mode_t mode, bool replace
 if (r < 0)
 return r;
 
-if (renameat2(AT_FDCWD, t, AT_FDCWD, to, replace ? 0 : 
RENAME_NOREPLACE) < 0) {
+if (replace) {
+r = renameat(AT_FDCWD, t, AT_FDCWD, to);
+} else {
+r = rename_noreplace(AT_FDCWD, t, AT_FDCWD, to);
+}
+if (r < 0) {
 unlink_noerrno(t);
 return -errno;
 }
diff --git a/src/shared/machine-image.c b/src/shared/machine-image.c
index c6d2850..ad5bff4 100644
--- a/src/shared/machine-image.c
+++ b/src/shared/machine-image.c
@@ -440,7 +440,7 @@ int image_rename(Image *i, const char *new_name) {
 if (!nn)
 return -ENOMEM;
 
-if (renameat2(AT_FDCWD, i->path, AT_FDCWD, new_path, RENAME_NOREPLACE) 
< 0)
+if (rename_noreplace(AT_FDCWD, i->path, AT_FDCWD, new_path) < 0)
 return -errno;
 
 /* Restore the immutable bit, if it was set before */
diff --git a/src/shared/machine-pool.c b/src/shared/machine-pool.c
index e7671a3..7e902a3 100644
--- a/src/shared/machine-pool.c
+++ b/src/shared/machine-pool.c
@@ -140,7 +140,7 @@ static int setup_machine_raw(uint64_t size, sd_bus_error 
*error) {
 goto fail;
 }
 
-if (renameat2(AT_FDCWD, tmp, AT_FDCWD, "/var/lib/machines.raw", 
RENAME_NOREPLACE) < 0) {
+if (rename_noreplace(AT_FDCWD, tmp, AT_FDCWD, "/var/lib/machines.raw") 
< 0) {
 r = sd_bus_error_set_errnof(error, errno, "Failed to move 
/var/lib/machines.raw into place: %m");
 goto fail;

[systemd-devel] [PATCH 3/4] Update the man page of tmpfiles.d(5), to document the new h/H command.

[Goffredo Baroncelli]

Update the man page of tmpfiles.d(5), to document the new h/H command.
---
 man/tmpfiles.d.xml | 32 
 1 file changed, 32 insertions(+)

diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 8815bf9..469deeb 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -303,6 +303,37 @@
 
 
 
+  h
+  Set file/directory attributes. Lines of this type
+  accept shell-style globs in place of normal path names.
+
+  The format of the argument field is 
[+-=][aAcCdDeijsStTu]
+  
+
+  The prefix + causes the
+  attribute(s) to be added; - causes the
+  attribute(s) to be removed; =
+  causes the attributes to set exactly as the following letters.
+  The letters 'aAcCdDeijsStTu' select the new
+  attributes for the files, see
+  chattr
+  1 for further information.
+  
+  Passing only = as argument,
+  reset all the file attributes.
+
+  
+
+
+
+  H
+  Recursively set file/directory attributes. Lines
+  of this type accept shell-style globs in place of normal
+  path names.
+  
+
+
+
   a
   a+
   Set POSIX ACLs (access control lists). If
@@ -529,6 +560,7 @@
   setfattr1,
   setfacl1,
   getfacl1
+  chattr1
 
   
 
-- 
2.1.4

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Jeff Waugh]

On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
 wrote:
> What does this fix Jeff, could you please explain?

Here's the relevant part of a pkg-config file produced during make:

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include

Versus during configure:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Which disproportionately affects cross-compiling and similar build situations.

OpenWrt includes an equivalent change for kmod (which Lucas mentioned
as I've submitted it upstream), and without an upstream change will
have to carry one for systemd too.

Finally, a supporting appeal to authority: If you check GNOME-land,
practically all pkg-config files are generated at configure time. :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to factory reset?

[Lennart Poettering]

On Mon, 09.03.15 12:02, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> Hi everybody,
> 
> I am running a kiosk-like box here and have a read-only copy of /etc
> hidden away in /usr/ somewhere. /etc is a symlink to that directory
> and that works fine.
> 
> Recently I thought I'd experiment with factory reset. My idea was to
> use a tmpfs mounted on /etc instead of that symlink and populate that
> from the directory in /usr on boots. That way I can still experiment
> with changes to the configuration, but on all reboots I get the
> trusted state back.
> 
> So how is factory reset supposed to work is systemd?

So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?

My recommendation would be to set this up within the initrd: mount a
tmpfs as /, then mount the physical /usr into it and transition to the
host OS. 

There's currently no explicit support for this to make this easy from the
initrd. (It is available in nspawn though with the --volatile=)
switch. But it's on the todo list to add that, so that what I describe
above is easily available. We also should provide a scheme that one
can flush /etc explicitly ones for a factory reset, via a kernel
cmdline option.

That said, I figure it should suffice to add entries for / and /usr to
the fstab and get the initrd to make use of it.

> Unfortunately the dbus.service will not come up, claiming that there
> is no /etc/dbus-1/system.conf. This file is in the tarball, and the
> output during boot-up suggests that dbus.service is started only after
> the /etc-tarball is extracted, so that file should be there. There
> seems to be a dbus.socket involved in the start of dbus.service and
> that is started before the tarball is extracted.

Yes, dbus is currently not compatible with stateless bootups. PAM is
neither. For PAM we ship a tmpfiles snippet to work around this, for
dbus we don't though, since kdbus kinda makes the problem go away...

> Should I take a different approach entirely and e.g. populate /etc in
> the initrd? I'd like to keep the initrd generic if I can, so I am not
> happy with that idea.
>
> I am using systemd-nspawn for my experiments. This seems to add some
> files to /etc, which is not ideal, but does not seem to hurt too much
> either. Is there a better way to test setups like the one I intend to
> get?

nspawn's --volatile= switch is how i did most of my own testing...

> Does systemd-nspawn indeed add/change files in /etc of the directory
> it is running from?

Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
create a machine ID, and apply presets and stuff...

Lennart

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

Re: [systemd-devel] [systemd-commits] 9 commits - configure.ac .gitignore Makefile.am Makefile-man.am man/systemd-fsckd.service.xml man/systemd-f...@.service.xml po/de.po po/el.po po/fr.po po/hu.po po

[Lennart Poettering]

On Tue, 10.03.15 08:39, Didier Roche (didro...@ubuntu.com) wrote:

> Le 10/03/2015 08:33, Martin Pitt a écrit :
> >Lennart Poettering [2015-03-09 19:11 +0100]:
> >
> >>Oh, and I am only realizing now that the whole thing doesn't do *at
> >>all* what we discussed. The idea was to invoke the actual fsck tools
> >>with their stdout connected directly to fsckd. Instead the old
> >>systemd-fsck tool still is the one that parses the fsck output and
> >>which now simply forwards that info.
> >That didn't actually come up during review, but that sounds like a
> >nice idea! I see two structures:
> >
> >  - s-fsck runs fsck and forwards its stdout/err fds to fsckd, and then
> >fsckd does all the parsing. This would also automatically eliminate
> >the intermediate socket handling from above.
> 
> We will still need the cancel message back socket (so below).

Use SO_PEERCRED from the systemd-fsckd side to identify the PID of the
connected fsck instance. Then, send the SIGTERM directly to
it. There's no need to proxy this off systemd-fsck.

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] util: add rename_noreplace

[Lennart Poettering]

On Tue, 10.03.15 16:16, Alban Crequy (alban.cre...@gmail.com) wrote:

> -if (renameat2(AT_FDCWD, t, AT_FDCWD, to, replace ? 0 : 
> RENAME_NOREPLACE) < 0) {
> -unlink_noerrno(t);
> -return -errno;
> +if (replace) {
> +if (renameat(AT_FDCWD, t, AT_FDCWD, to) < 0) {
> +unlink_noerrno(t);
> +return -errno;
> +}
> +} else {
> +if (rename_noreplace(AT_FDCWD, t, AT_FDCWD, to) < 0) {
> +unlink_noerrno(t);
> +return -errno;
> +}
>  }

Maybe shorten this by first assigning this to a temporary variable
"r", and then only have one error if check for both cases?

> +++ b/src/shared/util.c
> @@ -8118,3 +8118,37 @@ void cmsg_close_all(struct msghdr *mh) {
>  if (cmsg->cmsg_level == SOL_SOCKET && cmsg->cmsg_type == 
> SCM_RIGHTS)
>  close_many((int*) CMSG_DATA(cmsg), (cmsg->cmsg_len - 
> CMSG_LEN(0)) / sizeof(int));
>  }
> +
> +int rename_noreplace(int olddirfd, const char *oldpath, int newdirfd, const 
> char *newpath)
> +{

Opening { for functions on the same line as the function name please, see 
CODING_STYLE.

> +struct stat buf;
> +int ret;
> +
> +ret = renameat2(olddirfd, oldpath, newdirfd, newpath, 
> RENAME_NOREPLACE);
> +
> +/* Even though renameat2() exists since Linux 3.15, btrfs added
> + * support for it later. If it is not implemented, fallback to 
> another
> + * method. */
> +if (ret != -1 || errno != EINVAL)
> +return ret;

Hmm, not that it would matter much, but in systemd we so far mostly
check for < 0 rather then == -1 when looking for errors in syscalls...

Also, I think it would be a good idea to return "-errno" here, even
though the underlying syscalls don't do that. However, the "return
-errno" thing is pretty ubiquitously used in systemd, and at least as
useful as return the kernel's original -1 here...

> +
> +/* The link()/unlink() fallback does not work on directories. But
> + * renameat() without RENAME_NOREPLACE gives the same semantics on
> + * directories, except when newpath is an *empty* directory. This is
> + * good enough. */
> +ret = fstatat(olddirfd, oldpath, &buf, 0);
> +if (ret == 0 && S_ISDIR(buf.st_mode))
> +return renameat(olddirfd, oldpath, newdirfd,
> newpath);

Hmm, the fstatat() should use AT_SYMLINK_NOFOLLOW, no? 

I figure we should explicitly return with an error on stuff that is
neither S_ISDIR, nor S_ISREG, since neither renameat() nor link()
would work on it, right?

> +
> +/* If it is not a directory, use the link()/unlink() fallback. */
> +ret = linkat(olddirfd, oldpath, newdirfd, newpath, 0);
> +if (ret == -1)
> +return ret;

The usual < 0 and return -errno applies here...

> +
> +ret = unlinkat(olddirfd, oldpath, 0);
> +if (ret != 0) {
> +if (unlinkat(newdirfd, newpath, 0) != 0)
> +log_error("Failed to recover from
> unlinkat() failure.");

In systemd we try to enforce a regime: either functions log errors
themsevles, or they don't. But they should not log some errors and
others not, like it's done here...

Given that this is a low-level library-like call I think it should
never log on its own here. Instead, just eat up the second error...

Looks good otherwise,

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] [PATCHv3] bus-proxy: add support for "GetConnectionCredentials" method

[Lennart Poettering]

On Tue, 10.03.15 16:09, Lukasz Skalski (l.skal...@samsung.com) wrote:

> GetConnectionCredentials method was added to dbus-1 specification
> more than one year ago. This method should return "[...] as many
> credentials as possible for the process connected to the server",
> but at this moment only "UnixUserID", "LinuxSecurityLabel" and
> "ProcessID" are defined by the specification. We should add support
> for next credentials after extending dbus-1 spec.

Thanks! Applied!

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 1/5] fsckd: Don't use strjoina on gettext() call

[Lennart Poettering]

On Tue, 10.03.15 11:32, Didier Roche (didro...@ubuntu.com) wrote:

>  static int manager_send_plymouth_message(Manager *m, const char *message) {
> -const char *plymouth_cancel_message = NULL;
> +_cleanup_free_ const char *plymouth_cancel_message = NULL;
>  int r;
>  
>  r = manager_connect_plymouth(m);
> @@ -258,7 +258,7 @@ static int manager_send_plymouth_message(Manager *m, 
> const char *message) {
>  
>  m->plymouth_cancel_sent = true;
>  
> -plymouth_cancel_message = strjoina("fsckd-cancel-msg:", 
> _("Press Ctrl+C to cancel all filesystem checks in progress"));
> +plymouth_cancel_message = strjoin("fsckd-cancel-msg:", 
> _("Press Ctrl+C to cancel all filesystem checks in progress"), NULL);
>  

Well, there's an OOM check missing now, as strjoin() can fail...

That said, I think using strjoina is actually a good idea here, the
string is not unbounded. Hence I think it would be a good idea to
first assign the result of _() to a const char* variable in one step,
and then concat it in a second...

Lennart

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

Re: [systemd-devel] [systemd-commits] 9 commits - configure.ac .gitignore Makefile.am Makefile-man.am man/systemd-fsckd.service.xml man/systemd-f...@.service.xml po/de.po po/el.po po/fr.po po/hu.po po

[Lennart Poettering]

On Tue, 10.03.15 08:21, Martin Pitt (martin.p...@ubuntu.com) wrote:

> > Please, be more careful with complex code like this, this needs more
> > rounds of review before something like this can be merged...
> 
> Okay. It went through 4 rounds of review on the ML and several folks
> commented, there were no more outstanding/unaddressed review comments,
> and it seemed to me that we had consensus on IRC to land this now.
> Procedurally, what should I/we do next time before landing such large
> patches? Wait for an explicit ack on the ML from you?

Well, if it's complex code like this, get Zbigniew or Kay or Tom or so
to say it's OK...

I mean, I actually *do* appreciate that you don't ask for every patch
to be reviewed on the ML, to keep the traffic minimal. In this case I
would simply have preferred more rounds than usual, since it's not
trivial...

> Thanks and sorry for the hassle,

NP,

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] add REMOTE_ADDR and REMOTE_PORT for Accept=yes

[Lennart Poettering]

On Mon, 09.03.15 14:48, Shawn Landden (sh...@churchofgit.com) wrote:


> > We shouldn't bind us too closely to the precise formatting. I mean, if
> > one day libc decides to format the thing as ipv6 again, or with
> > uppercase hex chars, we shouldn't break.
>
> https://tools.ietf.org/html/rfc5952#section-4.3 says lowercase-only
> https://tools.ietf.org/html/rfc5952#section-5 specifies formatting of
> ipv4-mapped addresses

Well, but you know how these things go. I mean, you are the one using
musl. I'd not be surprised if some of the implementations don't
strictly follow the rfc in some detail and end up with a slightly
different formatting and the code is hosed...

Lennart

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

Re: [systemd-devel] [PATCH 3/5] fsckd: Reduce the SAK window when writing to console

[Lennart Poettering]

On Tue, 10.03.15 11:33, Didier Roche (didro...@ubuntu.com) wrote:

Looks good, applied!

Thanks for looking into this!

> >From 3e877d1d493476f63fa6af7997914f93b50218bd Mon Sep 17 00:00:00 2001
> From: Didier Roche 
> Date: Tue, 10 Mar 2015 09:57:38 +0100
> Subject: [PATCH 3/5] fsckd: Reduce the SAK window when writing to console
> 
> We don't want to keep /dev/console open all the time, but only open it when
> needed, to avoid interfering with SAK.
> ---
>  src/fsckd/fsckd.c | 66 
> ---
>  1 file changed, 39 insertions(+), 27 deletions(-)
> 
> diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
> index 9393379..f73d23b 100644
> --- a/src/fsckd/fsckd.c
> +++ b/src/fsckd/fsckd.c
> @@ -76,12 +76,12 @@ typedef struct Manager {
>  LIST_HEAD(Client, clients);
>  unsigned n_clients;
>  
> -int clear;
> +size_t clear;
>  
>  int connection_fd;
>  sd_event_source *connection_event_source;
>  
> -FILE *console;
> +bool show_status_console;
>  
>  double percent;
>  int numdevices;
> @@ -99,6 +99,36 @@ static void manager_free(Manager *m);
>  DEFINE_TRIVIAL_CLEANUP_FUNC(Client*, client_free);
>  DEFINE_TRIVIAL_CLEANUP_FUNC(Manager*, manager_free);
>  
> +static int manager_write_console(Manager *m, const char *message) {
> +_cleanup_fclose_ FILE *console = NULL;
> +int l;
> +size_t j;
> +
> +assert(m);
> +
> +if (!m->show_status_console)
> +return 0;
> +
> +/* Reduce the SAK window by opening and closing console on every 
> request */
> +console = fopen("/dev/console", "we");
> +if (!console)
> +return -errno;
> +
> +if (message) {
> +fprintf(console, "\r%s\r%n", message, &l);
> +if (m->clear  < (size_t)l)
> +m->clear = (size_t)l;
> +} else {
> +fputc('\r', console);
> +for (j = 0; j < m->clear; j++)
> +fputc(' ', console);
> +fputc('\r', console);
> +}
> +fflush(console);
> +
> +return 0;
> +}
> +
>  static double compute_percent(int pass, size_t cur, size_t max) {
>  /* Values stolen from e2fsck */
>  
> @@ -284,7 +314,7 @@ static int manager_update_global_progress(Manager *m) {
>  Client *current = NULL;
>  _cleanup_free_ char *console_message = NULL;
>  _cleanup_free_ char *fsck_message = NULL;
> -int current_numdevices = 0, l = 0, r;
> +int current_numdevices = 0, r;
>  double current_percent = 100;
>  
>  /* get the overall percentage */
> @@ -311,19 +341,15 @@ static int manager_update_global_progress(Manager *m) {
>  if (asprintf(&fsck_message, "fsckd:%d:%3.1f:%s", 
> m->numdevices, m->percent, console_message) < 0)
>  return -ENOMEM;
>  
> -/* write to console */
> -if (m->console) {
> -fprintf(m->console, "\r%s\r%n", console_message, &l);
> -fflush(m->console);
> -}
> +r = manager_write_console(m, console_message);
> +if (r < 0)
> +return r;
>  
>  /* try to connect to plymouth and send message */
>  r = manager_send_plymouth_message(m, fsck_message);
>  if (r < 0)
>  log_debug("Couldn't send message to plymouth");
>  
> -if (l > m->clear)
> -m->clear = l;
>  }
>  return 0;
>  }
> @@ -435,15 +461,7 @@ static void manager_free(Manager *m) {
>  return;
>  
>  /* clear last line */
> -if (m->console && m->clear > 0) {
> -unsigned j;
> -
> -fputc('\r', m->console);
> -for (j = 0; j < (unsigned) m->clear; j++)
> -fputc(' ', m->console);
> -fputc('\r', m->console);
> -fflush(m->console);
> -}
> +manager_write_console(m, NULL);
>  
>  sd_event_source_unref(m->connection_event_source);
>  safe_close(m->connection_fd);
> @@ -453,9 +471,6 @@ static void manager_free(Manager *m) {
>  
>  manager_disconnect_plymouth(m);
>  
> -if (m->console)
> -fclose(m->console);
> -
>  sd_event_unref(m->event);
>  
>  free(m);
> @@ -479,11 +494,8 @@ static int manager_new(Manager **ret, int fd) {
>  if (r < 0)
>  return r;
>  
> -if (access("/run/systemd/show-status", F_OK) >= 0) {
> -m->console = fopen("/dev/console", "we");
> -if (!m->console)
> -return -errno;
> -}
> +if (access("/run/systemd/show-status", F_OK) >= 0)
> +m->show_status

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Umut Tezduyar Lindskog]

What does this fix Jeff, could you please explain?

On Tue, Mar 10, 2015 at 7:04 PM, Jeff Waugh  wrote:
> Generate pkg-config files during configure as God (Havoc) intended. This fixes
> all of systemd's pkg-config files when cross-compiling (and possibly other use
> cases).
>
> (Note: I might've missed some things to tidy up in Makefile.am, but not 100%
> sure.)
>
> Signed-off-by: Jeff Waugh 
> ---
>  Makefile.am  |  3 ---
>  configure.ac | 10 ++
>  2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 3539e03..d2ebc81 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -6442,9 +6442,6 @@ man/%: man/%.in
>  sysctl.d/%: sysctl.d/%.in
> $(SED_PROCESS)
>
> -%.pc: %.pc.in
> -   $(SED_PROCESS)
> -
>  %.conf: %.conf.in
> $(SED_PROCESS)
>
> diff --git a/configure.ac b/configure.ac
> index 29111f5..21b8008 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1510,6 +1510,16 @@ AC_CONFIG_FILES([
>  docs/libudev/version.xml
>  docs/gudev/Makefile
>  docs/gudev/version.xml
> +src/libudev/libudev.pc
> +src/compat-libs/libsystemd-id128.pc
> +src/compat-libs/libsystemd-daemon.pc
> +src/compat-libs/libsystemd-login.pc
> +src/compat-libs/libsystemd-journal.pc
> +src/libsystemd/sd-id128/libsystemd-id128.pc
> +src/libsystemd/libsystemd.pc
> +src/udev/udev.pc
> +src/core/systemd.pc
> +src/gudev/gudev-1.0.pc
>  ])
>
>  AC_OUTPUT
> --
> 1.9.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