Re: [systemd-devel] [ANNOUNCE] systemd v229

[Jóhann B . Guðmundsson]

On 02/11/2016 05:47 PM, Lennart Poettering wrote:

On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

 * The coredump collection logic has been reworked: when a coredump is
   collected it is now written to disk, compressed and processed
   (including stacktrace extraction) from a new instantiated service
   systemd-coredump@.service.

Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in coredump.conf
and or other tweaks and if so which ones?

Try the man page systemd-coredump(8), first paragraph.


I do believe that's not enough to completely disable this and confusing 
at best I mean is the man page refering to 
/usr/lib/sysctl.d/50-coredump.conf
or /etc/systemd/coredump.conf which is what the administrator would 
associate this with since you know he was reading that particular man page.


There is a quite the difference of doing "ln -s /dev/null 
/etc/sysctl.d/50-coredump.conf && sysctl -p or 
/lib/systemd/systemd-sysctl" if systemd does not pick up the sysctl changes
vs administrators creating a symlink to /etc/systemd/coredump.conf 
disable this and run systemctl daemon-reload while the former is 
probably what's being refereed to.


And based on how that got implemented I have to ask cant this be disable 
completely as a switch in /etc/systemd/coredump.conf without having to 
have administrators jump through hoops, create symlinks and what not?





 * A new service setting RuntimeMaxSec= has been added that may be used
   to specify a maximum runtime for a service. If the timeout is hit, 
the
   service is terminated and put into a failure state.

This does not sound right, why put it into failure state if I as an admin
specifically told the the service it could run for maximum X time and then
it should stop? ( after that time period the type unit should be stopped
cleanly basically systemctl stop foo.service and the state be exactly the
same as it yields right ? )

I think yours appears to be a different usecase than what
RUntimeMaxSec= currently covers.


What's the usecase you had in mind and why leave it in failed state?

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

Re: [systemd-devel] [RFC] the chopping block

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
> On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > > Heya!
> > > 
> > > So I am thinking about some spring cleaning, and would love to remove
> > > the following bits from the systemd package:
> > > 
> > > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> > >time Debian was still using that, maybe this changed now?
> > > 
> > > 2) compat support for libsystemd-login.so and friends (these were
> > >merged into a single libsystemd.so a long time ago). We are still
> > >building compat libraries to ease the transition, but that was a
> > >long time ago, hence I'd really love to see this go. Any distro
> > >still using this?
> > Fedora ;)
> > https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> > But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> > maybe it'd be enough to rebuild samba without the compat headers
> > >installed.
> 
> As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.

Our compat support consists of two parts:
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.

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

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

>2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.



The upstream bug is few months short of it's 2 year anniversary and this 
move will just get the samba developers to apply the patch in that 
upstream report and close that bug.


Andrew is there any reason the patch in that upstream report has not 
been applied and samba moved to use libsystemd.so?


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

Re: [systemd-devel] [RFC] the chopping block

[Armin K.]

On 11.02.2016 20:44, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
>> On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
>> wrote:
>>
>>> On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
 Heya!

 So I am thinking about some spring cleaning, and would love to remove
 the following bits from the systemd package:

 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?

 2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?
>>> Fedora ;)
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
>>> But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
>>> maybe it'd be enough to rebuild samba without the compat headers
installed.
>>
>> As long as it's only one package I am happy to break this I must say...
> I check this now, and samba compiles fine with systemd-compat-libs.rpm
> removed. So no problem here.
> 
> Our compat support consists of two parts:
> libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> should still keep the .pc files for now.

Yes, please! I've been doing just that ever since libsystemd was introduced.
Sadly, the change to always install .pc files even when libraries weren't
built was rejected.



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

Re: [systemd-devel] [HEADS-UP] Preparing for v229

[Michael Biebl]

There seems to be a regression in git master (v228-1303-gcf92d86):

$ systemctl enable getty@tty1.service
Failed to execute operation: File exists
$ echo $?
1

This didn't fail with v228

2016-02-11 12:00 GMT+01:00 Lennart Poettering :
> Heya,
>
> just wanted to say that v229 is around the corner. Maybe later today
> or tomorrow we'll do the release. If you want to test this before the
> release, please do so now.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Preparing for v229

[Michael Biebl]

Nvm, seems I had a stray /etc/systemd/system/getty@tty1.service from running
systemctl edit --full getty@tty1.service

I didn't have that in my pristine test VM with v228


2016-02-11 14:13 GMT+01:00 Michael Biebl :
> There seems to be a regression in git master (v228-1303-gcf92d86):
>
> $ systemctl enable getty@tty1.service
> Failed to execute operation: File exists
> $ echo $?
> 1
>
> This didn't fail with v228
>
> 2016-02-11 12:00 GMT+01:00 Lennart Poettering :
>> Heya,
>>
>> just wanted to say that v229 is around the corner. Maybe later today
>> or tomorrow we'll do the release. If you want to test this before the
>> release, please do so now.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?



-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I want to run systemd inside of a locked down base docker container

[Daniel J Walsh]

On 02/10/2016 05:21 PM, Lennart Poettering wrote:
> On Wed, 10.02.16 16:43, Daniel J Walsh (dwa...@redhat.com) wrote:
>
> I don't see why one would want to mask systemd-logind.service. If you
> permit logins and PAM at all, you really need that. 
 If I wanted to add a login program I could enable/unmask these.
 No one runs docker containers as login services, that would require
 getty. 
>>> Well, "machinectl shell", "cron" and all those things do PAM... In
>>> fact the fact that "machinectl shell" goes through PAM and registers
>>> with logind through that is one of the major benefits over naked
>>> "nsenter".
>> I wonder if any of these work correctly inside of a docker container?
>>
>> Can these be customized or do they require systemd as pid 1 inside of
>> the container.  Docker has a "docker exec"
> No, "machinectl shell" requires PID 1 in the container to be systemd.
>
> Unlike "nsenter" (and docker exec, as I presume), "machinectl shell"
> will not try to take a process from the host and patch around in its
> process attributes until it appears to be a process from within the
> container (by joining namespaces, cgroups, uids, gids, selinux labels,
> audit creds, …). It will instead allocate a pty in the container and
> then use ask systemd inside the container using the "transient units"
> API to spawn a shell on it. It then does nothing else than forward
> data between this pty and the tty it was invoked from. 
>
> This way the only processes you see in the container have actually
> been started by systemd inside the container. They are properly
> tracked and maintained like any other process invoked in the container
> by the systemd instance that is running it. They inherit the process
> attributes from PID 1 in the container, and the PPID reported for them
> will actually be 1 as it should. – They are not these weird alien
> processes like nsenter creates that are half-way part of the host
> system and half-way member of the container, for which PPID returns 0
> in the container, because they actually don't have a parent process
> inside of the container.
>
> Long story short: "machinectl shell" should work fine even with docker
> containers – as long as systemd runs as PID 1 in them.
>
>>> I added this to the TODO list now.
>> Sounds fine with me.  I went back to the original container and I can
>> remove all of the other modifications, I can live with the warnings at the
>> beginning and remove the /etc/fstab.  We just need to get this into more
>> people hands to see what happens and what breaks. 
> Quite frankly, I don't understand why /etc/fstab is populated at all
> on Fedora by default. It should only exists if there are actual
> external file systems configured in it, and otherwise just not exist.
>
>> This is what I am seeing now with just /etc/fstab removed.
>>
>> Welcome to Fedora 23 (Twenty Three)!
>>
>> Set hostname to <654f7872d331>.
>> dev-hugepages.mount: Cannot add dependency job, ignoring: Unit 
>> dev-hugepages.mount is masked.
>> sys-fs-fuse-connections.mount: Cannot add dependency job, ignoring: Unit 
>> sys-fs-fuse-connections.mount is masked.
>> systemd-remount-fs.service: Cannot add dependency job, ignoring: Unit 
>> systemd-remount-fs.service is masked.
>> systemd-logind.service: Cannot add dependency job, ignoring: Unit 
>> systemd-logind.service is masked.
>> getty.target: Cannot add dependency job, ignoring: Unit getty.target
>> is masked.
> Again, there should be no need to mask dev-hugepages.mount and
> getty.target at all. And if you drop /etc/fstab there's no need to
> mask systemd-remount-fs.target either. Please unmask those three
> units!
>
> As soon as my patch to add the ConditionCapability= check to
> sys-fs-fuse-connections.mount you should also be able to unmask that
> unit and get a clean boot.
>
> Lennart
>
I am now masking nothing, just removing /etc/fstab.   We will probably
need to back port the dev-hugepages.mount fix
to rhel7 at some point.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I want to run systemd inside of a locked down base docker container

[Michal Sekletar]

On Thu, Feb 11, 2016 at 2:48 PM, Daniel J Walsh  wrote:

> I am now masking nothing, just removing /etc/fstab.   We will probably
> need to back port the dev-hugepages.mount fix
> to rhel7 at some point.

On RHEL-7.2 dev-hugepages.mount already has ConditionCapability=CAP_SYS_ADMIN.

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

Re: [systemd-devel] [RFC] the chopping block

[Martin Pitt]

Martin Pitt [2016-02-11 21:59 +0100]:
> This would apply if you boot with systemd, then install sysvinit, and
> want to reboot the machine (using SysV's /sbin/reboot), right? Or the
> other way around?
> 
> This is still somewhat relevant for Debian, but maybe there's
> something simpler that can be done for that case? If there's any other
> way to reboot the machine in that situation, it can also become
> documentation.

... I figure "systemctl reboot" should do?

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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Dave Reisner]

On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> Heya!
> 
> I just tagged the v229 release of systemd. Enjoy!
> 
> CHANGES WITH 229:
> 
> 
> 
> * When the stacktrace is extracted from processes of system users, 
> this
>   is now done as "systemd-coredump" user, in order to sandbox this
>   potentially security sensitive parsing operation. (Note that when
>   processing coredumps of normal users this is done under the user ID
>   of process that crashed, as before.) Packagers should take notice
>   that it is now necessary to create the "systemd-coredump" system 
> user
>   and group at package installation time.
> 

Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Dave Reisner]

On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
> 
> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
> >On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> >>I just tagged the v229 release of systemd. Enjoy!
> >>
> >>CHANGES WITH 229:
> >>
> >>
> >>
> >> * When the stacktrace is extracted from processes of system users, 
> >> this
> >>   is now done as "systemd-coredump" user, in order to sandbox this
> >>   potentially security sensitive parsing operation. (Note that when
> >>   processing coredumps of normal users this is done under the user 
> >> ID
> >>   of process that crashed, as before.) Packagers should take notice
> >>   that it is now necessary to create the "systemd-coredump" system 
> >> user
> >>   and group at package installation time.
> >>
> >
> >Why is it left to downstream to create this user? What makes it
> >different from the other 4 users which systemd already creates?
> 
> systemd don't create any user. nowhere, rpm-scritrs downstream does

You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 09:44 PM, Andrew Bartlett wrote:

On Thu, 2016-02-11 at 20:04 +, Jóhann B. Guðmundsson wrote:

On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these
were
merged into a single libsystemd.so a long time ago). We are
still
building compat libraries to ease the transition, but that
was a
long time ago, hence I'd really love to see this go. Any
distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
installed.


The upstream bug is few months short of it's 2 year anniversary and
this
move will just get the samba developers to apply the patch in that
upstream report and close that bug.

Andrew is there any reason the patch in that upstream report has not
been applied and samba moved to use libsystemd.so?

There isn't a patch for upstream master and the 4.1 patch doesn't
apply.

(I realise it may be trivial to fix it, but we need it tested against
old and new systemd installs etc, so if I can get such a patch it will
be much easier)

Sorry,


There was someone ( Armin ) on this thread that responded this had 
already been applied upstream since last summer which inconsistent with 
the current status of the bug in your tracker and your response and I 
think it's safe to assume you know better anyway you are aware of what's 
about to take place and need to adjust accordingly as do rest of 
downstreams that still might be using/relying on this although ( thus 
far ) samba seems to be the only affected by this change.


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

Re: [systemd-devel] [RFC] the chopping block

[Armin K.]

On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:
> 
> 
> On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> >2) compat support for libsystemd-login.so and friends (these were
>>> >merged into a single libsystemd.so a long time ago). We are still
>>> >building compat libraries to ease the transition, but that was a
>>> >long time ago, hence I'd really love to see this go. Any distro
>>> >still using this?
>> Fedora;)
>> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
>> But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
>> maybe it'd be enough to rebuild samba without the compat headers installed.
>>
> 
> The upstream bug is few months short of it's 2 year anniversary and this move 
> will just get the samba developers to apply the patch in that upstream report 
> and close that bug.
> 
> Andrew is there any reason the patch in that upstream report has not been 
> applied and samba moved to use libsystemd.so?

It has been applied at least since the last summer.



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

Re: [systemd-devel] [RFC] the chopping block

[Michael Biebl]

2016-02-11 18:06 GMT+01:00 Lennart Poettering :
> Heya!
>
> So I am thinking about some spring cleaning, and would love to remove
> the following bits from the systemd package:
>
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?

Debian still uses that, yes. Is this causing any maintenance issues?
It's a pretty isolated component after all.


> 2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?

As Martin already pointed out, we dropped the comapt libs a while ago.

> 3) systemd-reply-password – this is really old stuff used by the GNOME
>ask-password stuff which was experimental at best, and never found
>much use. Unless am very wrong pretty much nobody is using this,
>and we can just kill this without replacement. Anybody knows a user
>of this that I am not aware of?

Not actually sure what this tool is actually supposed to do and why it
was added in the first place.
Does GNOME shell implement the password agent interface now natively?

> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr.

I'm worried about this one. /var can hold a lot of data and is often
backed by complex setups (iSCSI, nbd, involving remote access).
Pulling all that into the initramfs seems like a huge amount of work.
Can you enumerate the problems that a split-off of /var is causing?


> 6) The .snapshot unit type. These sounded like a smart idea, I am
>pretty sure though nobody is using them properly, and they are
>pretty hard to use. If anything like this should exist at al, then
>probably as a concept of "transient targets", but not as a separate
>unit type. Anyone knows any real users of this stuff?

Seems fine to drop.

Michael



-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 11.02.2016 um 20:37 schrieb Jóhann B. Guðmundsson:

Arguably you should chop away the environment files support in the
process since you are already wielding the axe...


no - damned there are a ton of reasons to use them where it *do not 
matter* if you would do whatever this way or not


they can be shared between a dozens sepearated but related local 
services what you can't do with systemd snippets


please refrain from propose remove *useful* featzres with *zero* 
maintaince costs just because *you* won't use them - just don't use them 
and you are done but stop trying to dicatate the world how all others 
have to configure their systems - it's NOT your business




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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Reindl Harald]

Am 11.02.2016 um 22:19 schrieb Dave Reisner:

On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:

I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:



 * When the stacktrace is extracted from processes of system users, this
   is now done as "systemd-coredump" user, in order to sandbox this
   potentially security sensitive parsing operation. (Note that when
   processing coredumps of normal users this is done under the user ID
   of process that crashed, as before.) Packagers should take notice
   that it is now necessary to create the "systemd-coredump" system user
   and group at package installation time.



Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?


systemd don't create any user. nowhere, rpm-scritrs downstream does




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

Re: [systemd-devel] [RFC] the chopping block

[Jóhann B . Guðmundsson]

On 02/11/2016 08:41 PM, Armin K. wrote:

On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote:


On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?

Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.


The upstream bug is few months short of it's 2 year anniversary and this move 
will just get the samba developers to apply the patch in that upstream report 
and close that bug.

Andrew is there any reason the patch in that upstream report has not been 
applied and samba moved to use libsystemd.so?

It has been applied at least since the last summer.


If that's the case the samba community does not close open bugs as 
fixed, what a waste of time that must be for everybody anyway then the 
only concern ( thus far ) has already been fixed upstream.


JBG

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

Re: [systemd-devel] [RFC] the chopping block

[Reindl Harald]

Am 11.02.2016 um 22:11 schrieb Martin Pitt:

Martin Pitt [2016-02-11 21:59 +0100]:

This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?

This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.


... I figure "systemctl reboot" should do?


"reboot -f" helped a lot for the *one time change* as systemd was 
introdocued into Fedora long ago.




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

[systemd-devel] [ANNOUNCE] systemd v229

[Lennart Poettering]

Heya!

I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

* The systemd-resolved DNS resolver service has gained a substantial
  set of new features, most prominently it may now act as a DNSSEC
  validating stub resolver. DNSSEC mode is currently turned off by
  default, but it is expected that this is turned on by default in one
  of the next releases. For now, we invite everybody to test the DNSSEC
  logic by setting DNSSEC=allow-downgrade in
  /etc/systemd/resolved.conf. The service also gained a full set of
  D-Bus interfaces, including calls to configure DNS and DNSSEC
  settings per link (for consumption by external network management
  software). systemd-resolved (and systemd-networkd along with it) now
  know to distinguish between "search" and "routing" domains. The
  former are used to qualify single-label names, the latter are purely
  used for routing lookups within certain domains to specific
  links. resolved will now also synthesize RRs for all entries from
  /etc/hosts.

* The systemd-resolve tool (which is a client utility for
  systemd-resolved, and previously experimental) has been improved
  considerably and is now fully supported and documented. Hence it has
  moved from /usr/lib/systemd to /usr/bin.

* /dev/disk/by-path/ symlink support has been (re-)added for virtio
  devices.

* The coredump collection logic has been reworked: when a coredump is
  collected it is now written to disk, compressed and processed
  (including stacktrace extraction) from a new instantiated service
  systemd-coredump@.service, instead of directly from the
  /proc/sys/kernel/core_pattern hook we provide. This is beneficial as
  processing large coredumps can take up a substantial amount of
  resources and time, and this previously happened entirely outside of
  systemd's service supervision. With the new logic the core_pattern
  hook only does minimal metadata collection before passing off control
  to the new instantiated service, which is configured with a time
  limit, a nice level and other settings to minimize negative impact on
  the rest of the system. Also note that the new logic will honour the
  RLIMIT_CORE setting of the crashed process, which now allows users
  and processes to turn off coredumping for their processes by setting
  this limit.

* The RLIMIT_CORE resource limit now defaults to "unlimited" for PID 1
  and all forked processes by default. Previously, PID 1 would leave
  the setting at "0" for all processes, as set by the kernel. Note that
  the resource limit traditionally has no effect on the generated
  coredumps on the system if the /proc/sys/kernel/core_pattern hook
  logic is used. Since the limit is now honoured (see above) its
  default has been changed so that the coredumping logic is enabled by
  default for all processes, while allowing specific opt-out.

* When the stacktrace is extracted from processes of system users, this
  is now done as "systemd-coredump" user, in order to sandbox this
  potentially security sensitive parsing operation. (Note that when
  processing coredumps of normal users this is done under the user ID
  of process that crashed, as before.) Packagers should take notice
  that it is now necessary to create the "systemd-coredump" system user
  and group at package installation time.

* The systemd-activate socket activation testing tool gained support
  for SOCK_DGRAM and SOCK_SEQPACKET sockets using the new --datagram
  and --seqpacket switches. It also has been extended to support both
  new-style and inetd-style file descriptor passing. Use the new
  --inetd switch to request inetd-style file descriptor passing.

* Most systemd tools now honor a new $SYSTEMD_COLORS environment
  variable, which takes a boolean value. If set to false, ANSI color
  output is disabled in the tools even when run on a terminal that
  supports it.

* The VXLAN support in networkd now supports two new settings
  DestinationPort= and PortRange=.

* A new systemd.machine_id= kernel command line switch has been added,
  that may be used to set the machine ID in /etc/machine-id if it is
  not initialized yet. This command line option has no effect if the
  file is already initialized.

* systemd-nspawn gained a new --as-pid2 switch that invokes any
  specified command line as PID 2 rather than PID 1 in the
  container. In this mode PID 1 will be a minimal stub init process
  that implements the special 

[systemd-devel] [RFC] the chopping block

[Lennart Poettering]

Heya!

So I am thinking about some spring cleaning, and would love to remove
the following bits from the systemd package:

1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
   time Debian was still using that, maybe this changed now?

2) compat support for libsystemd-login.so and friends (these were
   merged into a single libsystemd.so a long time ago). We are still
   building compat libraries to ease the transition, but that was a
   long time ago, hence I'd really love to see this go. Any distro
   still using this?

3) systemd-reply-password – this is really old stuff used by the GNOME
   ask-password stuff which was experimental at best, and never found
   much use. Unless am very wrong pretty much nobody is using this,
   and we can just kill this without replacement. Anybody knows a user
   of this that I am not aware of?

4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
   of capabilities. They are pretty useless, as fcaps reduce them to
   nothing in pretty much all cases, which is precisely why the
   ambient caps were created. I am pretty sure nothing uses this, as
   it's not realistic to use this at all.

5) Here's the controversial one I think: support for booting up
   without /var. We have kludges at quite a few places because we
   cannot access /var early during boot. I am tempted to stop
   supporting this altogether. Of course, this does *not* mean that
   people with split off /var would be left in the cold. It just means
   that they have to mount /var from the initrd, exactly like this is
   already handled from /usr. 

6) The .snapshot unit type. These sounded like a smart idea, I am
   pretty sure though nobody is using them properly, and they are
   pretty hard to use. If anything like this should exist at al, then
   probably as a concept of "transient targets", but not as a separate
   unit type. Anyone knows any real users of this stuff?

And that's all for now. Opinions?

Lennart

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

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 20:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 11.02.2016 20:06, Lennart Poettering пишет:
> > 
> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot. I am tempted to stop
> >supporting this altogether. Of course, this does *not* mean that
> >people with split off /var would be left in the cold. It just means
> >that they have to mount /var from the initrd, exactly like this is
> >already handled from /usr. 
> > 
> 
> Does it apply to whole /var, to each part of /var or to specific subdirs
> in /var? In openSUSE various subtrees under /var are split off in
> individual volumes on btrfs, forcing mounting them all in initrd is not
> much appealing.

btrfs's subvolumes are pretty nice as they are just special
directories. There's no need to mount them in any special way.

That said, this is about /var/log and these kinds of things. If some
random late-boot package needs something under /var (let's say mysql
needs /var/lib/mysql), then systemd really doesn't care about it...

Lennart

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

Re: [systemd-devel] [RFC] the chopping block

[Andrei Borzenkov]

11.02.2016 20:52, Lennart Poettering пишет:
> On Thu, 11.02.16 20:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> 11.02.2016 20:06, Lennart Poettering пишет:
>>>
>>> 5) Here's the controversial one I think: support for booting up
>>>without /var. We have kludges at quite a few places because we
>>>cannot access /var early during boot. I am tempted to stop
>>>supporting this altogether. Of course, this does *not* mean that
>>>people with split off /var would be left in the cold. It just means
>>>that they have to mount /var from the initrd, exactly like this is
>>>already handled from /usr. 
>>>
>>
>> Does it apply to whole /var, to each part of /var or to specific subdirs
>> in /var? In openSUSE various subtrees under /var are split off in
>> individual volumes on btrfs, forcing mounting them all in initrd is not
>> much appealing.
> 
> btrfs's subvolumes are pretty nice as they are just special
> directories. There's no need to mount them in any special way.
> 

There is, but this is off topic here.

> That said, this is about /var/log and these kinds of things. If some

You will need to be specific, which kind of things then. And yes,
/var/log is mount point by default as well. Please if you are going to
drop support for these things being mount point, list them precisely and
exhaustively.

> random late-boot package needs something under /var (let's say mysql
> needs /var/lib/mysql), then systemd really doesn't care about it...
> 
> Lennart
> 

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Reindl Harald]

Am 11.02.2016 um 17:50 schrieb Lennart Poettering:

 * A new service setting RuntimeMaxSec= has been added that may be used
   to specify a maximum runtime for a service. If the timeout is hit, 
the
   service is terminated and put into a failure state


failure state makes no sense at all here

when i say "start and stop after 20 minutes" i mean stop it not fail

usecase?

some PHP service "while (1==1)" and exclude the complete logic of "stop 
after 20 minutes" and use instead the systemd-option




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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Reindl Harald]

Am 11.02.2016 um 18:48 schrieb Lennart Poettering:

On Thu, 11.02.16 19:47, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:


11.02.2016 19:32, Jóhann B. Guðmundsson пишет:


  * A new service setting RuntimeMaxSec= has been added that
may be used
to specify a maximum runtime for a service. If the timeout
is hit, the
service is terminated and put into a failure state.


This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )


And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?


Sure, if that's how you configure things, then systemd does what you
are asking it for


there is a difference between main-PID disappears unannounced (failure) 
and "RuntimeMaxSec reached" with a clean stop




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

Re: [systemd-devel] [RFC] the chopping block

[Matthias Urlichs]

On 11.02.2016 18:49, Lennart Poettering wrote:
> Again: this does not break systems with split off /var, as I tried to
> make very clear in my original mail. All that's needed is that the
> initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P

However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention".

The number of such systems is definitely not zero. In addition to
multi-boot machines with shared /var/{log,tmp,cache} sub-mounts, there's
the "somewhat-embedded system with root on SDHC card and /var on hard
disk / NFS / whatever" usecase. Some of these may not even *have* an initrd.

-- 
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Jan Alexander Steffens]

On Feb 11, 2016 7:03 PM, "Reindl Harald"  wrote:
>
>
>
> Am 11.02.2016 um 17:50 schrieb Lennart Poettering:
>>
>>  * A new service setting RuntimeMaxSec= has been added that may
be used
>>to specify a maximum runtime for a service. If the timeout is
hit, the
>>service is terminated and put into a failure state
>
>
> failure state makes no sense at all here
>
> when i say "start and stop after 20 minutes" i mean stop it not fail
>
> usecase?

I wanted to say "aborting Type=oneshot services," but that's what
TimeoutStartSec is for. So I was wondering what the point of this is, too.

Apparently it's for instantiated services like systemd-coredump@.service.
Why can't a service for an Accept=yes socket be Type=oneshot and use
TimeoutStartSec?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> Heya!
> 
> So I am thinking about some spring cleaning, and would love to remove
> the following bits from the systemd package:
> 
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?
> 
> 2) compat support for libsystemd-login.so and friends (these were
>merged into a single libsystemd.so a long time ago). We are still
>building compat libraries to ease the transition, but that was a
>long time ago, hence I'd really love to see this go. Any distro
>still using this?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.

> 3) systemd-reply-password – this is really old stuff used by the GNOME
>ask-password stuff which was experimental at best, and never found
>much use. Unless am very wrong pretty much nobody is using this,
>and we can just kill this without replacement. Anybody knows a user
>of this that I am not aware of?
> 
> 4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
>of capabilities. They are pretty useless, as fcaps reduce them to
>nothing in pretty much all cases, which is precisely why the
>ambient caps were created. I am pretty sure nothing uses this, as
>it's not realistic to use this at all.
> 
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr. 
Dunno, this is a very visible change. How big are the benefits?

> 6) The .snapshot unit type. These sounded like a smart idea, I am
>pretty sure though nobody is using them properly, and they are
>pretty hard to use. If anything like this should exist at al, then
>probably as a concept of "transient targets", but not as a separate
>unit type. Anyone knows any real users of this stuff?
Already gone: 36b4a7ba555

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Lennart Poettering]

On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> >I just tagged the v229 release of systemd. Enjoy!
> >
> >CHANGES WITH 229:
> >
> > * The coredump collection logic has been reworked: when a coredump 
> > is
> >   collected it is now written to disk, compressed and processed
> >   (including stacktrace extraction) from a new instantiated service
> >   systemd-coredump@.service.
> 
> Is it enough to disable this type service unit to completely disable
> coredump or will users have to for example set Storage=none in coredump.conf
> and or other tweaks and if so which ones?

Try the man page systemd-coredump(8), first paragraph.

> > * A new service setting RuntimeMaxSec= has been added that may be 
> > used
> >   to specify a maximum runtime for a service. If the timeout is 
> > hit, the
> >   service is terminated and put into a failure state.
> 
> This does not sound right, why put it into failure state if I as an admin
> specifically told the the service it could run for maximum X time and then
> it should stop? ( after that time period the type unit should be stopped
> cleanly basically systemctl stop foo.service and the state be exactly the
> same as it yields right ? )

I think yours appears to be a different usecase than what
RUntimeMaxSec= currently covers.

Lennart

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Jóhann B . Guðmundsson]

On 02/11/2016 04:50 PM, Lennart Poettering wrote:

Heya!

I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

 * The coredump collection logic has been reworked: when a coredump is
   collected it is now written to disk, compressed and processed
   (including stacktrace extraction) from a new instantiated service
   systemd-coredump@.service.


Is it enough to disable this type service unit to completely disable 
coredump or will users have to for example set Storage=none in 
coredump.conf and or other tweaks and if so which ones?





 * A new service setting RuntimeMaxSec= has been added that may be used
   to specify a maximum runtime for a service. If the timeout is hit, 
the
   service is terminated and put into a failure state.


This does not sound right, why put it into failure state if I as an 
admin specifically told the the service it could run for maximum X time 
and then it should stop? ( after that time period the type unit should 
be stopped cleanly basically systemctl stop foo.service and the state be 
exactly the same as it yields right ? )


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

Re: [systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
> > Heya!
> > 
> > So I am thinking about some spring cleaning, and would love to remove
> > the following bits from the systemd package:
> > 
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >time Debian was still using that, maybe this changed now?
> > 
> > 2) compat support for libsystemd-login.so and friends (these were
> >merged into a single libsystemd.so a long time ago). We are still
> >building compat libraries to ease the transition, but that was a
> >long time ago, hence I'd really love to see this go. Any distro
> >still using this?
> Fedora ;)
> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
> But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
> maybe it'd be enough to rebuild samba without the compat headers
> >installed.

As long as it's only one package I am happy to break this I must say...

> 
> > 5) Here's the controversial one I think: support for booting up
> >without /var. We have kludges at quite a few places because we
> >cannot access /var early during boot. I am tempted to stop
> >supporting this altogether. Of course, this does *not* mean that
> >people with split off /var would be left in the cold. It just means
> >that they have to mount /var from the initrd, exactly like this is
> >already handled from /usr. 
>
> Dunno, this is a very visible change. How big are the benefits?

Well, there's no single big benefit, just a lot of small ones
everywhere. We can drop deps from various units, we can do clock
bumping via timestamp files from PID1 and things like that. We could
properly order log message from the PID1 invocation on on systems
lacking an RTC, and so on.

> 
> > 6) The .snapshot unit type. These sounded like a smart idea, I am
> >pretty sure though nobody is using them properly, and they are
> >pretty hard to use. If anything like this should exist at al, then
> >probably as a concept of "transient targets", but not as a separate
> >unit type. Anyone knows any real users of this stuff?
> Already gone: 36b4a7ba555

Fun! I am an idiot!

Lennart

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

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Mikhail Kasimov]

11.02.2016 19:32, Jóhann B. Guðmundsson пишет:

>>  * A new service setting RuntimeMaxSec= has been added that
>> may be used
>>to specify a maximum runtime for a service. If the timeout
>> is hit, the
>>service is terminated and put into a failure state.
> 
> This does not sound right, why put it into failure state if I as an
> admin specifically told the the service it could run for maximum X time
> and then it should stop? ( after that time period the type unit should
> be stopped cleanly basically systemctl stop foo.service and the state be
> exactly the same as it yields right ? )

And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?


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

Re: [systemd-devel] [RFC] the chopping block

[Matthias Urlichs]

Hi,

Lennart Poettering:
> 5) Here's the controversial one I think: support for booting up
>without /var.

Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.

Thus: if you must, deprecate this now, but please leave the actual code
alone until next spring.

-- 
-- Matthias Urlichs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Andrei Borzenkov]

11.02.2016 20:06, Lennart Poettering пишет:
> 
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot. I am tempted to stop
>supporting this altogether. Of course, this does *not* mean that
>people with split off /var would be left in the cold. It just means
>that they have to mount /var from the initrd, exactly like this is
>already handled from /usr. 
> 

Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Lennart Poettering]

On Thu, 11.02.16 19:47, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:

> 11.02.2016 19:32, Jóhann B. Guðmundsson пишет:
> 
> >>  * A new service setting RuntimeMaxSec= has been added that
> >> may be used
> >>to specify a maximum runtime for a service. If the timeout
> >> is hit, the
> >>service is terminated and put into a failure state.
> > 
> > This does not sound right, why put it into failure state if I as an
> > admin specifically told the the service it could run for maximum X time
> > and then it should stop? ( after that time period the type unit should
> > be stopped cleanly basically systemctl stop foo.service and the state be
> > exactly the same as it yields right ? )
> 
> And if additional option Restart=on-failure is defined in [Service], the
> unit will be restarted again immediately. So, user will get unit, that
> will be active due to RuntimeMaxSec=, then it will be marked as "failed"
> and, if additional option Restart=on-failure is defined, will be
> restarted again... failed...restart and so on for eternity. Right?

Sure, if that's how you configure things, then systemd does what you
are asking it for.

Lennart

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