Discussion:
[ANNOUNCE] systemd 210
(too old to reply)
Lennart Poettering
2014-02-24 22:08:58 UTC
Permalink
Heya,

And here's the next release 210:

http://www.freedesktop.org/software/systemd/systemd-210.tar.xz

Many bugfixes, but also a couple of new features (see below).

One of the more relevant changes is that the compatibility library
support no longer makes use of IFUNC. This allows them to build fine ARM
where the toolchain is not really at the level of the other archs like
x86. Fore more details see below.

Oh, and one reminder that kinda got lost when we announced 209: you have
to enable CONFIG_FHANDLE in your kernel to use systemd >= 209
successfully, otherwise udev won't find any devices.

This release is already available in Rawhide.

Thanks,

Lennart

CHANGES WITH 210:

* systemd will now relabel /dev after loading the SMACK policy
according to SMACK rules.

* A new unit file option AppArmoreProfile= has been added to
set the AppArmor profile for the processes of a unit.

* A new condition check ConditionArchitecture= has been added
to conditionalize units based on the system architecture, as
reported by uname()'s "machine" field.

* systemd-networkd now supports matching on the system
virtualization, architecture, kernel command line, host name
and machine ID.

* logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.

* logind will now watch SW_DOCK switches and inhibit reaction
to the lid switch if it is pressed. This means that logind
will not suspend the machine anymore if the lid is closed
and the systemd is docked, if the laptop supports SW_DOCK
notifications via the input layer. Note that ACPI docking
stations do not generate this currently. Also note that this
logic is usually not fully sufficient and Desktop
Environments should take a lid switch inhibitor lock when an
external display is connected, as systemd will not watch
this on its own.

* nspawn will now make use of the devices cgroup controller by
default, and only permit creation of and access to the usual
API device nodes like /dev/null or /dev/random, as well as
access to (but not creation of) the pty devices.

* We will now ship a default .network file for
systemd-networkd that automatically configures DHCP for
network interfaces created by nspawn's --network-veth or
--network-bridge= switches.

* systemd will now understand the usual M, K, G, T suffixes
according to SI conventions (i.e. to the base 1000) when
referring to throughput and hardware metrics. It will stay
with IEC conventions (i.e. to the base 1024) for software
metrics, according to what is customary according to
Wikipedia. We explicitly document which base applies for
each configuration option.

* The DeviceAllow= setting in unit files now supports a syntax
to whitelist an entire group of devices node majors at once,
based on the /proc/devices listing. For example, with the
string "char-pts" it is now possible to whitelist all
current and future pseudo-TTYs at once.

* sd-event learned a new "post" event source. Event sources of
this type are triggered by the dispatching of any event
source of a type that is not "post". This is useful for
implementing clean-up and check event sources that are
triggered by other work being done in the program.

* systemd-networkd is no longer statically enabled, but uses
the usual [Install] sections so that it can be
enabled/disabled using systemctl. It still is enabled by
default however.

* When creating a veth interface pair with systemd-nspawn the
host side will now be prefixed with "vb-" if
--network-bridge= is used, and with "ve-" if --network-veth
is used. This way it is easy to distinguish these cases on
the host, for example to apply different configuration to
them with systemd-networkd.

* The compatibility libraries for libsystemd-journal.so,
libsystem-id128.so, libsystemd-login.so and
libsystemd-daemon.so do not make use of IFUNC
anymore. Instead we now build libsystemd.so multiple times
under these alternative names. This means that the footprint
is drastically increased, but given that these are
transitional compatibility libraries this shouldn't matter
much. This change has been made necessary to support the ARM
platform for these compatibility libraries, as the ARM
toolchain isn't really at the same level as the toolchain
for other architectures like x86 and does not support
IFUNC. Please make sure to use --enable-compat-libs only
during a transitional period!

Contributions from: Andreas Fuchs, Armin K, Colin Walters,
Daniel Mack, Dave Reisner, David Herrmann, Djalal Harouni,
Holger Schurig, Jason A. Donenfeld, Jason St. John, Jasper
St. Pierre, Kay Sievers, Lennart Poettering, Łukasz Stelmach,
Marcel Holtmann, Michael Scherer, Michal Sekletar, Mike
Gilbert, Samuli Suominen, Thomas Bächler, Thomas Hindoe
Paaboel Andersen, Tom Gundersen, Umut Tezduyar Lindskog,
Zbigniew Jędrzejewski-Szmek

-- Berlin, 2014-02-24

Lennart
--
Lennart Poettering, Red Hat
David Timothy Strauss
2014-02-25 00:30:49 UTC
Permalink
On Mon, Feb 24, 2014 at 2:08 PM, Lennart Poettering
Post by Lennart Poettering
logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.
What about being able to run laptops lid-closed as long as there's an
external display and input device? I don't personally do this, but I'm
curious how widely it might be needed.
Lennart Poettering
2014-02-25 01:35:40 UTC
Permalink
Post by David Timothy Strauss
On Mon, Feb 24, 2014 at 2:08 PM, Lennart Poettering
Post by Lennart Poettering
logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.
What about being able to run laptops lid-closed as long as there's an
external display and input device? I don't personally do this, but I'm
curious how widely it might be needed.
What we'll probably do is two things:

1) Enumerate connected displays in logind from sysfs and inhibit lid
close suspends if a number != 1 is found.

2) Avoid suspend due to lid close for 1min after the last suspend and
3min after boot or so.

Thing #1 has been traditionally done by GNOME which took an inhibitor
lock when it detected multiple connected displays. We probably should
move this one layer down into logind to open this up for other DEs and
more importantly to close the race where GNOME would be started after
logind which means the inhibitor lock GNOME could take would be too late
to make sure logind doesn't already suspend due to the lid closed.

Thing #2 is then necessary to cover for USB docking stations for which
we simply never know when they fully reappear after a supend or at boot,
since that's unbounded on USB. Of course this rule #2 isn't that great
on my own Yoga laptop, since it means if I by accident power on the
laptop in my backpack it will only resuspend after 1min instead of
instantly... But I figure that's the price to pay for being general
purpose.

Those two items are now on the TODO list.

Lennart
--
Lennart Poettering, Red Hat
Cecil Westerhof
2014-02-25 07:57:12 UTC
Permalink
Post by David Timothy Strauss
On Mon, Feb 24, 2014 at 2:08 PM, Lennart Poettering
Post by Lennart Poettering
logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.
What about being able to run laptops lid-closed as long as there's an
external display and input device? I don't personally do this, but I'm
curious how widely it might be needed.
Should be possible to overrule: I can think of someone having an
external monitor but still wanting to do a shutdown.
Mathieu Bridon
2014-02-25 01:04:33 UTC
Permalink
Post by Lennart Poettering
* A new unit file option AppArmoreProfile= has been added to
set the AppArmor profile for the processes of a unit.
I think that should be « AppArmorProfile= », not « AppArmoreProfile= ».

At least that's what systemd.exec(5) says.
--
Mathieu Bridon <***@fedoraproject.org>
Lennart Poettering
2014-02-25 01:38:04 UTC
Permalink
Post by Mathieu Bridon
Post by Lennart Poettering
* A new unit file option AppArmoreProfile= has been added to
set the AppArmor profile for the processes of a unit.
I think that should be « AppArmorProfile= », not « AppArmoreProfile= ».
At least that's what systemd.exec(5) says.
Fixed in git, the announcement mail OTOH is already sent, of course,
can't fix that anymore... :-(

Lennart
--
Lennart Poettering, Red Hat
Kai Krakow
2014-02-26 19:22:04 UTC
Permalink
Post by Mathieu Bridon
Post by Lennart Poettering
* A new unit file option AppArmoreProfile= has been added to
set the AppArmor profile for the processes of a unit.
I think that should be « AppArmorProfile= », not « AppArmoreProfile= ».
At least that's what systemd.exec(5) says.
Well, every app needs some love from time to time... ;-)
(yeah, I know it's still spelled wrong then)
--
Replies to list only preferred.
Colin Guthrie
2014-02-25 13:05:34 UTC
Permalink
Post by Lennart Poettering
* systemd will now understand the usual M, K, G, T suffixes
according to SI conventions (i.e. to the base 1000) when
referring to throughput and hardware metrics. It will stay
with IEC conventions (i.e. to the base 1024) for software
metrics, according to what is customary according to
Wikipedia. We explicitly document which base applies for
each configuration option.
It would seem to me that use of upper and lower case suffixes is fairly
wide-spread (at least in my head) for choosing which base (1000 vs
1024). Of course I can't remember which is which, but perhaps using this
approach would actually be better - and default values can just use
whichever letter-case they deem appropriate for the use-case.

I guess what I mean to say is that a general rule is easier to grok than
a per-directive rule, although I may have missed some important
subtleties and back discussion here.


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

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Lennart Poettering
2014-02-25 13:29:34 UTC
Permalink
Post by Colin Guthrie
Post by Lennart Poettering
* systemd will now understand the usual M, K, G, T suffixes
according to SI conventions (i.e. to the base 1000) when
referring to throughput and hardware metrics. It will stay
with IEC conventions (i.e. to the base 1024) for software
metrics, according to what is customary according to
Wikipedia. We explicitly document which base applies for
each configuration option.
It would seem to me that use of upper and lower case suffixes is fairly
wide-spread (at least in my head) for choosing which base (1000 vs
1024). Of course I can't remember which is which, but perhaps using this
approach would actually be better - and default values can just use
whichever letter-case they deem appropriate for the use-case.
Hmm, I thought about something like that, but I thought we'd the ones
inventing it, so I opted not to use that. Do you have some links which
could show that this is a more commonly accepted rule?

Note that in SI "m" is milli, and "M" is mega. Would be fun to store a
couple of millibyte on disk!
Post by Colin Guthrie
I guess what I mean to say is that a general rule is easier to grok than
a per-directive rule, although I may have missed some important
subtleties and back discussion here.
This new rule we adopted basically results in IEC everywhere with the
exception of a few things like networkd's BitsPerSecond= setting. But
there it should be really obvious that it is SI that is meant, after all
"100Mbit Ethernet" or "Gigabit Ethernet" refer to SI prefixes. That
means the SI vs. IEC should come pretty natural I think for all
technical people the way it is right now. Or to turn this around, which
administrator would expect that setting BitsPerSecond= to 954K is the
right way to go for Gigabit Ethernet?

Lennart
--
Lennart Poettering, Red Hat
Colin Guthrie
2014-02-26 12:30:21 UTC
Permalink
Post by Lennart Poettering
Post by Colin Guthrie
Post by Lennart Poettering
* systemd will now understand the usual M, K, G, T suffixes
according to SI conventions (i.e. to the base 1000) when
referring to throughput and hardware metrics. It will stay
with IEC conventions (i.e. to the base 1024) for software
metrics, according to what is customary according to
Wikipedia. We explicitly document which base applies for
each configuration option.
It would seem to me that use of upper and lower case suffixes is fairly
wide-spread (at least in my head) for choosing which base (1000 vs
1024). Of course I can't remember which is which, but perhaps using this
approach would actually be better - and default values can just use
whichever letter-case they deem appropriate for the use-case.
Hmm, I thought about something like that, but I thought we'd the ones
inventing it, so I opted not to use that. Do you have some links which
could show that this is a more commonly accepted rule?
Now you're testing me.... I'm convinced I've seen this before, but now
that the pressure is on, I cannot think of what projects used that
scheme... (all the obvious ones I looked at don't do that: dd,
dd_rescue, mke2fs etc. etc. parted sort of does it but uses multiple
letters so it's not the same).
Post by Lennart Poettering
Note that in SI "m" is milli, and "M" is mega. Would be fun to store a
couple of millibyte on disk!
:)
Post by Lennart Poettering
This new rule we adopted basically results in IEC everywhere with the
exception of a few things like networkd's BitsPerSecond= setting. But
there it should be really obvious that it is SI that is meant, after all
"100Mbit Ethernet" or "Gigabit Ethernet" refer to SI prefixes. That
means the SI vs. IEC should come pretty natural I think for all
technical people the way it is right now. Or to turn this around, which
administrator would expect that setting BitsPerSecond= to 954K is the
right way to go for Gigabit Ethernet?
Actually, yeah, thinking about this more, I guess you don't really need
to learn the rule at all anyway... I mean doing the expected thing in
the expected place should be sufficient and I shouldn't worry about what
it means... I guess I may look it up the first time, but then thereafter
forget about it and not worry.

So after thinking about it a bit, I actually do think it's good how it's
done now :)

Cheers!

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

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Jan Engelhardt
2014-02-25 15:32:52 UTC
Permalink
Post by Lennart Poettering
* logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.
Interesting. I have some medium-aged Sony VPCM11M1E which too has a
power button (more like a *slider*) that could be said to be prone to
activation; however, the machine will not react to the slider or keypress
while the lid is closed, which is a good thing.

Am I correct in the assumption that your Yoga machines are not
as "smart" and thus desired this change? :)
Post by Lennart Poettering
Also note that this
logic is usually not fully sufficient and Desktop
Environments should take a lid switch inhibitor lock when an
external display is connected, as systemd will not watch
this on its own.
Does logind handle the case of {textconsole environment with
external display and usbkbd}?
Kay Sievers
2014-02-25 15:41:26 UTC
Permalink
Post by Jan Engelhardt
Post by Lennart Poettering
* logind is now a lot more aggressive when suspending the
machine due to a closed laptop lid. Instead of acting only
on the lid close action it will continuously watch the lid
status and act on it. This is useful for laptops where the
power button is on the outside of the chassis so that it can
be reached without opening the lid (such as the Lenovo
Yoga). On those machines logind will now immediately
re-suspend the machine if the power button has been
accidentally pressed while the laptop was suspended and in a
backpack or similar.
Interesting. I have some medium-aged Sony VPCM11M1E which too has a
power button (more like a *slider*) that could be said to be prone to
activation; however, the machine will not react to the slider or keypress
while the lid is closed, which is a good thing.
Am I correct in the assumption that your Yoga machines are not
as "smart" and thus desired this change? :)
Normal button, just switches the box on. Might be, that this is even a
"feature", that the power button works, so it can be used with the USB
docking stations and the closed lid.
Post by Jan Engelhardt
Post by Lennart Poettering
Also note that this
logic is usually not fully sufficient and Desktop
Environments should take a lid switch inhibitor lock when an
external display is connected, as systemd will not watch
this on its own.
Does logind handle the case of {textconsole environment with
external display and usbkbd}?
The difference between text and graphic will not be interesting in the
future. All consoles will be "graphic", just don't look like it.

Kay
Continue reading on narkive:
Loading...