Re: [systemd-devel] journalctl - "Error was encountered while opening journal files: Invalid argument"

[Daniel Mack]

On 06/19/2015 09:31 PM, Johannes Ernst wrote:
> After a reboot, root gets this:
> 
> # journalctl 
> Error was encountered while opening journal files: Invalid argument
> 
> No other output.

What does 'strace journalctl' say?


Thanks,
Daniel



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

[systemd-devel] filtering journal logs

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I am curious if it is possible or planned to add support for pattern
matching and/or negation matching in journal? for example I would like
to view everything except audit entries.
Actually, when we are at it, are audit entries actually distinguished
now, or not?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVhJ5BAAoJEHb1CzgxXKwY6AkP/1OddKSIIoxNAxRof18Ir/oN
bjkGeC5KNAfHeMJqNkr0Gd2vovdZx8Phh6NcWb7zkS9i0kuMFSCu6JFLMosmrsD3
VcRbMXN+7J3U/6Rvvc06bSz/0tSHMIfuIYC0QzzG68FilOQiPycslcHgBrFGflHZ
Swy9Anfkh0uWgbruAnABV/dq80E+g47WouYSvIqHjWHg2pJNS/l81N0SFi7RcymY
tkpwMjSH9vIZmu/GVQEy3yzjdWooR5djcaAlOEd0+aHcA7Ccf4fXSAe2t39JoHFi
K7HfOToX3ZeCu3Uq3Ht8GQETdx9TJBmxrW6ZvRvq6BRUup8Az5AIgpw57VGd3HLC
D0uaZMv6lkjj3Hl+TZiTEJyhVCqD/TpX+4UKU3J37TxIz/o5BPIwp6QuJy7gdbem
Qzxt6JR1bLV/azArrbJhPL+7/JSx7iK9qqdynbfC73vVtew3OclW9tNh0XM4IMWg
ZkMwBOxALloYydrZ8dVkwYpueTz7wRHwG1o473cU8Sh/wVJMoD1Ajk+dLMlIWw77
0T0JFhAULDffhy+um51jLuI2E0gs0luxiEBeWDcQ5oIiuBNFE9dqDlu4VPfk4ttg
wtk1mZKq0VLErYitFm/EnF+L2LE2U9OQOw2/ubKmtW+PKpYbqVi6BrdRxsxJTWeq
pwqKedmzX2F2k4D21gpT
=nC6v
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] journalctl - "Error was encountered while opening journal files: Invalid argument"

[Johannes Ernst]

After a reboot, root gets this:

# journalctl 
Error was encountered while opening journal files: Invalid argument

No other output.
Non-root gets user-specific output.

What might have happened here. and how do I fix it? I upgraded from 220 to 221: 
same behavior.

I briefly ran out of space on a root btrfs filesystem yesterday. Might this 
have anything to do with it?

Thanks,



Johannes.

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

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

[Lennart Poettering]

On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote:

> Heya!
> 
> It's primarily a bugfix release, but we also make sd-bus.h and
> sd-event.h public. (A blog story on sd-bus and how to use it will
> follow shortly.)

The blog story is online now:

http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html

Enjoy,

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] [ANNOUNCE] systemd v221

[Kay Sievers]

On Fri, Jun 19, 2015 at 5:07 PM, Filipe Brandenburger
 wrote:
> Guys let's try to be constructive here...
>
> This time it shouldn't be too painful for downstreams since the revert
> was the last patch to the man subtree so just a git revert of that
> should get your trees to the state you need to get v221 packages for
> Debian and Ubuntu. In that sense, I think we're still (slightly)
> better off than we were in v220 and I think we have all we need to
> solve this one for good in v222.
>
> And let's use the momentum to try to solve this soon, in which case
> you could even replace the revert of that commit with the backport of
> the next one (which will probably remove the disted manpages).

I was involved in the decision to revert it. And I'm sure we should
not add the patch back.

The split-usr option is not much more than an "upgrade path" for
traditional unix layouts to merge the operating system into a single
directory. The split-usr option is nothing upstream systemd could
fully suport. We need the unified layout for several options systemd
offers, and more and more new things will rely on it. Split-usr will
not got away anytime soon, but it will get less and less support
regarding new features we add to systemd.

The last-minute revert was not properly communicated, I am sorry for
that, but the technical reasons for the revert are still true. Not
dist'ing the man pages does not make the feature itself correct. We
should not provide options to render the man page content
inconsistently. The search paths would need to be mangled too, or none
of them. But again, I am against upstream support for man split-usr
man pages because systemd cannot fully support split-usr anyway, and
should not pretend it does. Please do that downstream where the
classic file system layout is supported.

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

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

[Filipe Brandenburger]

Guys let's try to be constructive here...

This time it shouldn't be too painful for downstreams since the revert
was the last patch to the man subtree so just a git revert of that
should get your trees to the state you need to get v221 packages for
Debian and Ubuntu. In that sense, I think we're still (slightly)
better off than we were in v220 and I think we have all we need to
solve this one for good in v222.

And let's use the momentum to try to solve this soon, in which case
you could even replace the revert of that commit with the backport of
the next one (which will probably remove the disted manpages).

Cheers,
Filipe


On Fri, Jun 19, 2015 at 7:40 AM, Michael Biebl  wrote:
> 2015-06-19 16:38 GMT+02:00 Lennart Poettering :
>> On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote:
>>
>>> > If something is not in shape we'll revert it. Regardless of the
>>> > general merits of the patch set: this one actually broke stuff, it
>>> > was incomplete. Either you make the man pages dynamic, or you ship
>>> > them pre-built. The patch set did both. That's broken, and hence has
>>> > no place in a release. And I'd much rather see that stuff removed
>>> > again than having to delay the release further.
>>> >
>>> >> Not amused, not amused at all.
>>> >
>>> > I am sorry you feel that way.
>>> >
>>> > I am not sure though what you suggest: delay releases until zero
>>> > bugfixes have been applied for a week? Well, that would mean we'd
>>> > never do releases again, sorry. We have to release some time. On
>>>
>>> Bullshit. That's been in master for a while and the justification for
>>> reverting appear to totally made up.
>>
>> I wasn't the one who reverted it or even involved in the
>> discussions. But what I saw is that the patch was borked, since it one
>> one hand tried to ship the man pages pre-built but also wanted to make
>> them different depending on ./configure runs. And that's just
>> *broken*.
>
> The justification for the revert basically boil down to:
> let's make it as hard as possible and use systemd as a stick to force
> them to not use split-usr.
>
> The "arguments" for the for the patch being broken are completely made up.
>
>
> --
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 19.06.2015 um 16:32 schrieb Lennart Poettering:

On Fri, 19.06.15 16:15, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 19.06.2015 um 16:06 schrieb Lennart Poettering:

 * If there's a systemd unit and a SysV init script for the
   same service name, and the user executes "systemctl enable"
   for it (or a related call), then this will now enable both
   (or execute the related operation on both), not just the
   unit.


that is an horrible regression in context of someone has written a
systemd-unit for commercial software which only ships a sysv-init-script
like vmware as example


How so? the native unit always overrides the sysv init script. Hence
the fact that the init script is enabled shouldn't really matter.


then all is fine, the text above is not clear about that and "now will 
enable both" implies start both



We did this to be nice to Debian, so that they can support booting
into sysvinit in parallel to systemd, so that the enable status is
kept in sync between systemd and sysvinit

the text above is just misleading
















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] [ANNOUNCE] systemd v221

[Lennart Poettering]

On Fri, 19.06.15 16:40, Michael Biebl (mbi...@gmail.com) wrote:

> 2015-06-19 16:38 GMT+02:00 Lennart Poettering :
> > On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote:
> >
> >> > If something is not in shape we'll revert it. Regardless of the
> >> > general merits of the patch set: this one actually broke stuff, it
> >> > was incomplete. Either you make the man pages dynamic, or you ship
> >> > them pre-built. The patch set did both. That's broken, and hence has
> >> > no place in a release. And I'd much rather see that stuff removed
> >> > again than having to delay the release further.
> >> >
> >> >> Not amused, not amused at all.
> >> >
> >> > I am sorry you feel that way.
> >> >
> >> > I am not sure though what you suggest: delay releases until zero
> >> > bugfixes have been applied for a week? Well, that would mean we'd
> >> > never do releases again, sorry. We have to release some time. On
> >>
> >> Bullshit. That's been in master for a while and the justification for
> >> reverting appear to totally made up.
> >
> > I wasn't the one who reverted it or even involved in the
> > discussions. But what I saw is that the patch was borked, since it one
> > one hand tried to ship the man pages pre-built but also wanted to make
> > them different depending on ./configure runs. And that's just
> > *broken*.
> 
> The justification for the revert basically boil down to:
> let's make it as hard as possible and use systemd as a stick to force
> them to not use split-usr.

Well, to make that clear, we support split-usr for compatibility
reasons, to be nice to debian and ubuntu. But we don't like the
concept, and we'll not compromise for it. For example, ProtectSystem=
isn't really effective with split-usr either. Neither does nspawn's
--volatile= switch or anything else related to the stateless/factory
reset stuff we are working on work with it.

Also, when it comes to file search paths I am strongly of the opinion
that we never should document the paths in the root dir, since they
generally are a form of API: it's an extension point for 3rd party
packages, and we should communicate clearly where that point is and
that it is always the same. If we instead say "it can be anything,
depending on your distro", then we aren't better than sysvinit.

So yes, the split-usr thing is unloved by many of the systemd upstream
devs. We'll continue to support it though, but only the minimal level
necessary to make things work and not regress. And: the quirks it
causes we'll not necessarily document, simply because we want the man
pages clear and clean and not contain a list of compat quirks that
apply to some systems only.



The above is my personal opinion, and again in the specific decision
and discussion about the reverted man patches I was not involved. And
as far as I can see the communication around it wasn't very good. I am
very sorry for that, we should do this better,

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] "Unit type .busname is not supported on this system." when setting up timer

[Kai Hendry]

On Thu, 18 Jun 2015, at 07:04 PM, Lennart Poettering wrote:
> What does "systemctl status" say for it?

http://s.natalian.org/2015-06-18/1434659705_1912x1036.png

Sorry, my fault. Seems like I failed to run: systemctl daemon-reload...




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

Re: [systemd-devel] "Unit type .busname is not supported on this system." when setting up timer

[Kai Hendry]

On Thu, 18 Jun 2015, at 07:04 PM, Lennart Poettering wrote:
> What does "systemctl status" say for it?

http://s.natalian.org/2015-06-18/1434659705_1912x1036.png

Sorry, my fault. Seems like I failed to run: systemctl daemon-reload...




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

Re: [systemd-devel] Why we need to read/save random seed?

[Lennart Poettering]

On Wed, 17.06.15 17:38, Reindl Harald (h.rei...@thelounge.net) wrote:

> * the purpose of systemd-random-seed.service is to seed
>   /dev/random realy at boot so that other services like
>   sshd, vpn, webservers have a random source
> 
> * seed /dev/random *followed* by suck it out again like
>   has the same result as "systemctl mask systemd-random-seed.service"
>   because if there is enough entrophy it would not be needed and if
>   not after suck it out again it's gone

There are ways to read randomness from the pool without decreasing the
entropy estimates. And that kind of reading is good enough for that
purpose.

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] [ANNOUNCE] systemd v221

[Michael Biebl]

2015-06-19 16:38 GMT+02:00 Lennart Poettering :
> On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote:
>
>> > If something is not in shape we'll revert it. Regardless of the
>> > general merits of the patch set: this one actually broke stuff, it
>> > was incomplete. Either you make the man pages dynamic, or you ship
>> > them pre-built. The patch set did both. That's broken, and hence has
>> > no place in a release. And I'd much rather see that stuff removed
>> > again than having to delay the release further.
>> >
>> >> Not amused, not amused at all.
>> >
>> > I am sorry you feel that way.
>> >
>> > I am not sure though what you suggest: delay releases until zero
>> > bugfixes have been applied for a week? Well, that would mean we'd
>> > never do releases again, sorry. We have to release some time. On
>>
>> Bullshit. That's been in master for a while and the justification for
>> reverting appear to totally made up.
>
> I wasn't the one who reverted it or even involved in the
> discussions. But what I saw is that the patch was borked, since it one
> one hand tried to ship the man pages pre-built but also wanted to make
> them different depending on ./configure runs. And that's just
> *broken*.

The justification for the revert basically boil down to:
let's make it as hard as possible and use systemd as a stick to force
them to not use split-usr.

The "arguments" for the for the patch being broken are completely made up.


-- 
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] [ANNOUNCE] systemd v221

[Andrei Borzenkov]

В Fri, 19 Jun 2015 16:15:03 +0200
Reindl Harald  пишет:

> 
> 
> Am 19.06.2015 um 16:06 schrieb Lennart Poettering:
> >  * If there's a systemd unit and a SysV init script for the
> >same service name, and the user executes "systemctl enable"
> >for it (or a related call), then this will now enable both
> >(or execute the related operation on both), not just the
> >unit.
> 
> that is an horrible regression in context of someone has written a 
> systemd-unit for commercial software which only ships a sysv-init-script 
> like vmware as example
> 

Why? If native unit is present it will screen initscript anyway. But
this change ensures that both systemd and sysvinit will see the same
state for similar named services.


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

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

[Lennart Poettering]

On Fri, 19.06.15 16:15, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 19.06.2015 um 16:06 schrieb Lennart Poettering:
> > * If there's a systemd unit and a SysV init script for the
> >   same service name, and the user executes "systemctl enable"
> >   for it (or a related call), then this will now enable both
> >   (or execute the related operation on both), not just the
> >   unit.
> 
> that is an horrible regression in context of someone has written a
> systemd-unit for commercial software which only ships a sysv-init-script
> like vmware as example

How so? the native unit always overrides the sysv init script. Hence
the fact that the init script is enabled shouldn't really matter.

We did this to be nice to Debian, so that they can support booting
into sysvinit in parallel to systemd, so that the enable status is
kept in sync between systemd and sysvinit.

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] [ANNOUNCE] systemd v221

[Reindl Harald]

Am 19.06.2015 um 16:06 schrieb Lennart Poettering:

 * If there's a systemd unit and a SysV init script for the
   same service name, and the user executes "systemctl enable"
   for it (or a related call), then this will now enable both
   (or execute the related operation on both), not just the
   unit.


that is an horrible regression in context of someone has written a 
systemd-unit for commercial software which only ships a sysv-init-script 
like vmware as example




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] Why we need to read/save random seed?

[Reindl Harald]

Am 17.06.2015 um 17:08 schrieb cee1:

2015-06-17 22:03 GMT+08:00 Lennart Poettering :

On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote:


What I means is:
1. Load a saved seed to /dev/urandom.
2. The service read /dev/random, which will block until kernel thinks
there's enough entropy - then the Random Number should be good?
3. Save the random number returned in step 2 on disk.


Blocking at boot for this doesn't really sound like an option. But the
kernel does not provide us with any nice notifications about when the
RNG pool is complete. If we want to do this kind of polishing, then
that'd be great, but we'd need sane notifiers for that, blocking
syscalls are not an option.


That don't mean blocking boot, but a service, let's say
systemd-random-seed.service:
1. systemd-random-seed.service loads a seed from disk to /dev/urandom
2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
3. Instead of quitting immediately, systemd-random-seed.service tries
to read /dev/random, and it blocks ...
4. systemd-random-seed.service at last gets a 'good random number',
and saves it on disk


* the purpose of systemd-random-seed.service is to seed
  /dev/random realy at boot so that other services like
  sshd, vpn, webservers have a random source

* seed /dev/random *followed* by suck it out again like
  has the same result as "systemctl mask systemd-random-seed.service"
  because if there is enough entrophy it would not be needed and if
  not after suck it out again it's gone



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] [ANNOUNCE] systemd v221

[Lennart Poettering]

On Fri, 19.06.15 16:11, Michael Biebl (mbi...@gmail.com) wrote:

> I'm very disappointed (once again) how this release was handled.
> Lot's of last minute changes. 

I disagree. We only made bugfixes in the last days, except maybe one
patch (that came with a lot of unit tests). That's how this works: we
fix things we need to fix before we do a release. Also, due to the
nice CI hookup we have now pretty much all patches are pretty
extensively tested individually before we merge them.

> Especially https://github.com/systemd/systemd/pull/293 really sucks.

If something is not in shape we'll revert it. Regardless of the
general merits of the patch set: this one actually broke stuff, it
was incomplete. Either you make the man pages dynamic, or you ship
them pre-built. The patch set did both. That's broken, and hence has
no place in a release. And I'd much rather see that stuff removed
again than having to delay the release further.

> Not amused, not amused at all.

I am sorry you feel that way.

I am not sure though what you suggest: delay releases until zero
bugfixes have been applied for a week? Well, that would mean we'd
never do releases again, sorry. We have to release some time. On
monday I announced that I'll do a release today, there was ample time
to test things, and we found a number of issues that way and fixed
them as they came along. Since yesterday night there wasn't anything
release-critical open anymore, so I slept one night and did the
release today since nothing of importance popped up in the meantime.

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] [ANNOUNCE] systemd v221

[Lennart Poettering]

On Fri, 19.06.15 16:21, Michael Biebl (mbi...@gmail.com) wrote:

> All this talk about getting downstream patches upstream and then last
> minute reverts without a proper justitification. WTF.

"reverts"? Plural? Which ones are you referring to excluding that man
page path thing?

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] [ANNOUNCE] systemd v221

[Michael Biebl]

All this talk about getting downstream patches upstream and then last
minute reverts without a proper justitification. WTF.

2015-06-19 16:11 GMT+02:00 Michael Biebl :
> I'm very disappointed (once again) how this release was handled.
> Lot's of last minute changes. Especially
> https://github.com/systemd/systemd/pull/293
> really sucks.
>
> Not amused, not amused at all.
>
> 2015-06-19 16:06 GMT+02:00 Lennart Poettering :
>> Heya!
>>
>> It's primarily a bugfix release, but we also make sd-bus.h and
>> sd-event.h public. (A blog story on sd-bus and how to use it will
>> follow shortly.)
>>
>> http://www.freedesktop.org/software/systemd/systemd-221.tar.xz
>>
>> Reminder: Note again that the git repository and bug tracking moved to
>> github with this release. The new github page is this:
>>
>> https://github.com/systemd/systemd
>>
>> Reporting bugs via the fdo bugzilla is closed now. Changes to existing
>> bugs can still be made, and discussion should continue there, but no
>> new ones may be filed. We will not migrate individual bug reports from
>> fdo to github. File new bugs as github issues, please.
>>
>> Please submit new patches preferable as github PRs now, however we
>> will continue to accept patches via the ML, too.
>>
>> If you have a git checkout, don't forget to migrate to the new github
>> GIT repository as origin:
>>
>> https://github.com/systemd/systemd.git
>>
>> The fdo git repo still exists though and is sporadically synced from
>> the github repository.
>>
>> CHANGES WITH 221:
>>
>> * The sd-bus.h and sd-event.h APIs have now been declared
>>   stable and have been added to the official interface of
>>   libsystemd.so. sd-bus implements an alternative D-Bus client
>>   library, that is relatively easy to use, very efficient and
>>   supports both classic D-Bus as well as kdbus as transport
>>   backend. sd-event is a generic event loop abstraction that
>>   is built around Linux epoll, but adds features such as event
>>   prioritization or efficient timer handling. Both APIs are good
>>   choices for C programs looking for a bus and/or event loop
>>   implementation that is minimal and does not have to be
>>   portable to other kernels.
>>
>> * kdbus support is no longer compile-time optional. It is now
>>   always built-in. However, it can still be disabled at
>>   runtime using the kdbus=0 kernel command line setting, and
>>   that setting may be changed to default to off, by specifying
>>   --disable-kdbus at build-time. Note though that the kernel
>>   command line setting has no effect if the kdbus.ko kernel
>>   module is not installed, in which case kdbus is (obviously)
>>   also disabled. We encourage all downstream distributions to
>>   begin testing kdbus by adding it to the kernel images in the
>>   development distributions, and leaving kdbus support in
>>   systemd enabled.
>>
>> * The minimal required util-linux version has been bumped to
>>   2.26.
>>
>> * Support for chkconfig (--enable-chkconfig) was removed in
>>   favor of calling an abstraction tool
>>   /lib/systemd/systemd-sysv-install. This needs to be
>>   implemented for your distribution. See "SYSV INIT.D SCRIPTS"
>>   in README for details.
>>
>> * If there's a systemd unit and a SysV init script for the
>>   same service name, and the user executes "systemctl enable"
>>   for it (or a related call), then this will now enable both
>>   (or execute the related operation on both), not just the
>>   unit.
>>
>> * The libudev API documentation has been converted from gtkdoc
>>   into man pages.
>>
>> * gudev has been removed from the systemd tree, it is now an
>>   external project.
>>
>> * The systemd-cgtop tool learnt a new --raw switch to generate
>>   "raw" (machine parsable) output.
>>
>> * networkd's IPForwarding= .network file setting learnt the
>>   new setting "kernel", which ensures that networkd does not
>>   change the IP forwarding sysctl from the default kernel
>>   state.
>>
>> * The systemd-logind bus API now exposes a new boolean
>>   property "Docked" that reports whether logind considers the
>>   system "docked", i.e. connected to a docking station or not.
>>
>> Contributions from: Alex Crawford, Andreas Pokorny, Andrei
>> Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez,
>> Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann,
>> David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed
>> Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario,
>> Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek,
>> Jason Pleau, Jason S. McMullan, J

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

[Michael Biebl]

I'm very disappointed (once again) how this release was handled.
Lot's of last minute changes. Especially
https://github.com/systemd/systemd/pull/293
really sucks.

Not amused, not amused at all.

2015-06-19 16:06 GMT+02:00 Lennart Poettering :
> Heya!
>
> It's primarily a bugfix release, but we also make sd-bus.h and
> sd-event.h public. (A blog story on sd-bus and how to use it will
> follow shortly.)
>
> http://www.freedesktop.org/software/systemd/systemd-221.tar.xz
>
> Reminder: Note again that the git repository and bug tracking moved to
> github with this release. The new github page is this:
>
> https://github.com/systemd/systemd
>
> Reporting bugs via the fdo bugzilla is closed now. Changes to existing
> bugs can still be made, and discussion should continue there, but no
> new ones may be filed. We will not migrate individual bug reports from
> fdo to github. File new bugs as github issues, please.
>
> Please submit new patches preferable as github PRs now, however we
> will continue to accept patches via the ML, too.
>
> If you have a git checkout, don't forget to migrate to the new github
> GIT repository as origin:
>
> https://github.com/systemd/systemd.git
>
> The fdo git repo still exists though and is sporadically synced from
> the github repository.
>
> CHANGES WITH 221:
>
> * The sd-bus.h and sd-event.h APIs have now been declared
>   stable and have been added to the official interface of
>   libsystemd.so. sd-bus implements an alternative D-Bus client
>   library, that is relatively easy to use, very efficient and
>   supports both classic D-Bus as well as kdbus as transport
>   backend. sd-event is a generic event loop abstraction that
>   is built around Linux epoll, but adds features such as event
>   prioritization or efficient timer handling. Both APIs are good
>   choices for C programs looking for a bus and/or event loop
>   implementation that is minimal and does not have to be
>   portable to other kernels.
>
> * kdbus support is no longer compile-time optional. It is now
>   always built-in. However, it can still be disabled at
>   runtime using the kdbus=0 kernel command line setting, and
>   that setting may be changed to default to off, by specifying
>   --disable-kdbus at build-time. Note though that the kernel
>   command line setting has no effect if the kdbus.ko kernel
>   module is not installed, in which case kdbus is (obviously)
>   also disabled. We encourage all downstream distributions to
>   begin testing kdbus by adding it to the kernel images in the
>   development distributions, and leaving kdbus support in
>   systemd enabled.
>
> * The minimal required util-linux version has been bumped to
>   2.26.
>
> * Support for chkconfig (--enable-chkconfig) was removed in
>   favor of calling an abstraction tool
>   /lib/systemd/systemd-sysv-install. This needs to be
>   implemented for your distribution. See "SYSV INIT.D SCRIPTS"
>   in README for details.
>
> * If there's a systemd unit and a SysV init script for the
>   same service name, and the user executes "systemctl enable"
>   for it (or a related call), then this will now enable both
>   (or execute the related operation on both), not just the
>   unit.
>
> * The libudev API documentation has been converted from gtkdoc
>   into man pages.
>
> * gudev has been removed from the systemd tree, it is now an
>   external project.
>
> * The systemd-cgtop tool learnt a new --raw switch to generate
>   "raw" (machine parsable) output.
>
> * networkd's IPForwarding= .network file setting learnt the
>   new setting "kernel", which ensures that networkd does not
>   change the IP forwarding sysctl from the default kernel
>   state.
>
> * The systemd-logind bus API now exposes a new boolean
>   property "Docked" that reports whether logind considers the
>   system "docked", i.e. connected to a docking station or not.
>
> Contributions from: Alex Crawford, Andreas Pokorny, Andrei
> Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez,
> Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann,
> David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed
> Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario,
> Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek,
> Jason Pleau, Jason S. McMullan, Jean Delvare, Jeff Huang,
> Jonathan Boulle, Karel Zak, Kay Sievers, kloun, Lennart
> Poettering, Marc-Antoine Perennou, Marcel Holtmann, Mario
> Limonciello, Martin Pitt, Michael Biebl, Michael Olbrich,
> Michal Schmidt, Mike Gilbert, Nick Owens

[systemd-devel] [ANNOUNCE] systemd v221

[Lennart Poettering]

Heya!

It's primarily a bugfix release, but we also make sd-bus.h and
sd-event.h public. (A blog story on sd-bus and how to use it will
follow shortly.)

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

Reminder: Note again that the git repository and bug tracking moved to
github with this release. The new github page is this:

https://github.com/systemd/systemd

Reporting bugs via the fdo bugzilla is closed now. Changes to existing
bugs can still be made, and discussion should continue there, but no
new ones may be filed. We will not migrate individual bug reports from
fdo to github. File new bugs as github issues, please.

Please submit new patches preferable as github PRs now, however we
will continue to accept patches via the ML, too.

If you have a git checkout, don't forget to migrate to the new github
GIT repository as origin:

https://github.com/systemd/systemd.git

The fdo git repo still exists though and is sporadically synced from
the github repository.

CHANGES WITH 221:

* The sd-bus.h and sd-event.h APIs have now been declared
  stable and have been added to the official interface of
  libsystemd.so. sd-bus implements an alternative D-Bus client
  library, that is relatively easy to use, very efficient and
  supports both classic D-Bus as well as kdbus as transport
  backend. sd-event is a generic event loop abstraction that
  is built around Linux epoll, but adds features such as event
  prioritization or efficient timer handling. Both APIs are good
  choices for C programs looking for a bus and/or event loop
  implementation that is minimal and does not have to be
  portable to other kernels.

* kdbus support is no longer compile-time optional. It is now
  always built-in. However, it can still be disabled at
  runtime using the kdbus=0 kernel command line setting, and
  that setting may be changed to default to off, by specifying
  --disable-kdbus at build-time. Note though that the kernel
  command line setting has no effect if the kdbus.ko kernel
  module is not installed, in which case kdbus is (obviously)
  also disabled. We encourage all downstream distributions to
  begin testing kdbus by adding it to the kernel images in the
  development distributions, and leaving kdbus support in
  systemd enabled.

* The minimal required util-linux version has been bumped to
  2.26.

* Support for chkconfig (--enable-chkconfig) was removed in
  favor of calling an abstraction tool
  /lib/systemd/systemd-sysv-install. This needs to be
  implemented for your distribution. See "SYSV INIT.D SCRIPTS"
  in README for details.

* If there's a systemd unit and a SysV init script for the
  same service name, and the user executes "systemctl enable"
  for it (or a related call), then this will now enable both
  (or execute the related operation on both), not just the
  unit.

* The libudev API documentation has been converted from gtkdoc
  into man pages.

* gudev has been removed from the systemd tree, it is now an
  external project.

* The systemd-cgtop tool learnt a new --raw switch to generate
  "raw" (machine parsable) output.

* networkd's IPForwarding= .network file setting learnt the
  new setting "kernel", which ensures that networkd does not
  change the IP forwarding sysctl from the default kernel
  state.

* The systemd-logind bus API now exposes a new boolean
  property "Docked" that reports whether logind considers the
  system "docked", i.e. connected to a docking station or not.

Contributions from: Alex Crawford, Andreas Pokorny, Andrei
Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez,
Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann,
David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed
Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario,
Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek,
Jason Pleau, Jason S. McMullan, Jean Delvare, Jeff Huang,
Jonathan Boulle, Karel Zak, Kay Sievers, kloun, Lennart
Poettering, Marc-Antoine Perennou, Marcel Holtmann, Mario
Limonciello, Martin Pitt, Michael Biebl, Michael Olbrich,
Michal Schmidt, Mike Gilbert, Nick Owens, Pablo Lezaeta Reyes,
Patrick Donnelly, Pavel Odvody, Peter Hutterer, Philip
Withnall, Ronny Chevalier, Simon McVittie, Susant Sahani,
Thomas Hindoe Paaboel Andersen, Tom Gundersen, Torstein
Husebø, Umut Tezduyar Lindskog, Viktar Vauchkevich, Werner
Fink, Zbigniew Jędrzejewski-Szmek

-- Berlin, 2015-06-19

Lennart

-- 
Lennart Poettering, Red Hat

[systemd-devel] [PATCH][v1]random-seed: Save random seed as early as possible

[cee1]

Hi all,

As discussed at
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033075.html,
this patch saves seed with ** good ** random number as early as
possible, as opposed to the original behavior, which saves a random
number when shutdown.

Note:
1. If seed loading failed, it will not save a new seed. May not be the
proper behavior?
2. The STATUS sent by the second and third sd_notify() are not shown
in "systemctl status systemd-random-seed.service", need some kind of
improvement.

Please comment and give suggestions :)



-- 
Regards,

- cee1


0001-random-seed-Save-seed-with-a-good-random-number-earl.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] leftover interface

[Lennart Poettering]

On Thu, 18.06.15 21:11, Johannes Ernst (johannes.er...@gmail.com) wrote:

> Not sure how I just managed to do that, but after an nspawn run with
> -n, I have a leftover ve-xxx interface on the host. The
> container/machine is gone, the (ephemeral) file system is gone, just
> the interface is still there.

Hmm, and the other side of the veth tunnel, where is that?

The kernel actually cleans up veth links automatically when a network
namespace owningone side goes away... If you really managed to make
one side of the veth link go away, but the other one is still around
then this would be a kernel bug...

> Also sometimes it seems that the ephemeral subvolume stays around if
> the container has been shut down with ‘machinectl poweroff’.

Hmm, can you retry this with v221 (hopefully released today)?

Lennart

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

[systemd-devel] [lenn...@poettering.net: Re: systemd-nspawn network interface name collisions]

[Lennart Poettering]

Forgot to readd the ML to CC... Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
--- Begin Message ---
On Thu, 18.06.15 22:03, Florian Koch (florian.koch1...@gmail.com) wrote:

> >> Now if you use similar names for conatiners, like
> >>
> >> com.$company.$devision.$name1
> >> com.$company.$devision.$name2
> >> com.$company.$devision.$name3
> >>
> >> the network device name handling is broken.
> >>
> >> I tryed to prefix the machinename with a uuid (uuidgen) but the the
> >> names are to long.
> >>
> >> Why not using a 11 Caracter uuid / random  for network interface
> >> names, and avoid all the naming trouble?
> >
> > Well, because we want to keep things easy to grok for users. If you
> > type "ip link" and see the container names for the veth links, then
> > that's certainly a lot more useful than seeing some random
> > gibberish
> 
> that is totally understandable, but what is with macvlan interfaces?
> these are not shown in ip link (they are moved to the container
> namespace)
> The macvlan are my main Problem , we do not use veth interfaces.

Hmm, not sure I follow: the macvlan ones exist inside the container
namespace only (modulo a short time window during container setup),
and hence don't have to carry unique names across the whole
system. It's completely OK if we have an interface by the same name
every single container...

The reason I named ned macvlan interfaces like the ifaces they are
generated from is to help admins understand the relation...

Lennart

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

Re: [systemd-devel] [PATCH 7/9] nspawn: escape paths in overlay mount options

[Lennart Poettering]

On Fri, 19.06.15 11:17, Richard Maw (richard@codethink.co.uk) wrote:

> > Also, it's really inefficient, since strreplace() goes through the
> > string each time from the beginning.
> 
> I was looking to do something simple rather than fast, as this isn't a
> particularly latency sensitive bit of code, and I wasn't confident in
> the need of a generic solution, but if you think it'll have wider use,
> that's fine by me.

Yeah, the need for a shell-like rather than C-like escaping function
comes up every now and then, and we should really fix this properly
for once...

> > I think it would make sense to add a generic 
> > 
> >   char *shell_escape(const char *s, const char *bad);
> > 
> > that works like xescape() but applies shell-style escaping instead of
> > C-style escaping.
> 
> This isn't exactly shell escaping as I understand it, as that would also
> require putting quotation marks aroud the string in certain circumstances,
> and shell_maybe_quote() handles that already.

Well, it *is* shell escaping, but a different kind. After all for the
shell 

   "foo bar" 

and 

   foo\ bar

are equivalent. Most folks would argue though that the first is
prettier to look at, and that's what shell_maybe_quote() does. But the
second is valid shell escaping too, and in the overlayfs case what we
actually need. Hence I think we need both calls...

> I'd call it backslash_escape() and possibly use it inside
> shell_maybe_quote().

Well, C-style escaping also uses backslashes... I think we should
still call it shell_escape() and shell_maybe_quote()...

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/9] util: Add unescape_first_word()

[Lennart Poettering]

On Fri, 19.06.15 10:56, Richard Maw (richard@codethink.co.uk) wrote:

> On Thu, Jun 18, 2015 at 08:30:22PM +0200, Lennart Poettering wrote:
> > On Thu, 28.05.15 13:02, Richard Maw (richard@codethink.co.uk) wrote:
> > 
> > > This is a superset of the functionality of unquote_first_word, allowing
> > > non-whitespace separators, and doesn't interpret quotes unless
> > > UNQUOTE_QUOTES is included in flags.
> > 
> > Hmm, makes sense, but I'd actually just have one function
> > extract_first_word() then, which replaces unquote_first_word() but has
> > the signature of your unescape_first_word(). It would take the
> > separators parameter, which would default to WHITESPACE if passed as
> > NULL. THe flags should all be renamed EXTRACT_xyz instead of
> > UNQUOTE_xyz then, and EXTRACT_UNQUOTE should be a prominent flag.
> 
> Thanks, I was sweating the nomeclature and wasn't happy with what I came up
> with, but couldn't think of anything better.
> 
> > Then, all our current users of unquote_first_word() should be changed
> > to use this new call.
> > 
> > Does that make sense?
> 
> Sure, I was just a little wary of making such wide changes across
> the codebase.

We are not afraid of refactoring things like this, if it makes our
internal APIs simpler and cleaner!

> I also saw a couple of TODOs to convert uses of FOREACH_WORD family to the
> unquote_many_words family. I'll see if I can feasibly convert those while I'm
> changing string handling elsewhere.

Yes, we should stop using FOREACH_WORD, and move everything to
extract_first_word() loops, but I fear that's a major
endeavour... Would love patches for that, though.

Moving things over would slightly change behaviour of systemd when we
parse things, but I am sure it's a good thing actually. 

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] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object

[Lennart Poettering]

On Fri, 19.06.15 12:06, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote:

> From: Lennart Poettering 
> Subject: Re: [systemd-devel] A missing SELinux unit access check due to 
> unexpected UNIT_NOT_FOUND unit object
> Date: Thu, 18 Jun 2015 13:23:25 +0200
> 
> > On Thu, 18.06.15 18:14, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote:
> > 
> >> Currently, there's a behavior that an unit object in UNIT_NOT_FOUND
> >> generated via After= dependency is unexpectedly? left in
> >> manager->units hash table and SELinux unit access check is not
> >> performed.
> > 
> > No this is expected and intended behaviour. All units that are
> > *referenced* have a Unit object that is in the manager->units hash
> > table, and that includes units that do not exist on disk.
> > 
> > I am note sure what this means for SELinux though. It probably should
> > fall back to some generic label or so if a Unit object doesn't have a
> > unit file associated on disk.
> > 
> 
> Thanks for your explanation. I have one more quesiton. That is, this
> is a kind of backpatching technique used in compiler parsers to
> represent different symbol references by a unique single object, is
> this correct?

Yes, that does play a role: units may have multiple names, and while
loading the units we learn which ones belong together, and only then
can merge them and possibly find the backing unit file. That means we
need to make sure that we track unit files in the dependency tree even
if we don't have a unit file for them.

That said, it's also beneficial in other cases, like for example for
debugging purposes, to get a full idea of what's going on.

Also, there are some unit types (for example .device units) that are
synthesized dynamically, and usually don't have any unit file. 

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-detect-virt and virtualbox 5.0

[Lennart Poettering]

On Fri, 19.06.15 11:13, Igor Bukanov (i...@mir2.org) wrote:

> Hello,
> 
> forthcoming VirtualBox 5.0 hypervisor (currently at RC1) supports
> paravirtualization using Hyper-V or KVM interfaces. When the latter is
> used with a linux guest then systemd-detect-virt prints kvm. I suppose
> at least the manual page for systemd-detect-virt should be updated to
> indicate that  the command output does not reflect a particular
> implementation but names hupervisor technology.
> 
> However, the issue then is what to do with ConditionVirtualization=
> testing for oracle in unit files. Under kvm mode that gives false
> preventing in my case mounting a host directory with config files
> using vboxsf module. I suppose I should just deal with that and try to
> mount vboxsf share both under kvm and oracle, but perhaps
> systemd-detect-virt should be updated to still print oracle even when
> VirtualBox uses paravirtualization?

Yeah, I am pretty sure we should update src/shared/virt.c then and
ensure we detect the new version correctly.

I am pretty sure there's a way how to discern kvm and vbox5 even then,
it's just a matter of figuring out how.

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 7/9] nspawn: escape paths in overlay mount options

[Richard Maw]

On Thu, Jun 18, 2015 at 08:39:10PM +0200, Lennart Poettering wrote:
> On Thu, 28.05.15 13:02, Richard Maw (richard@codethink.co.uk) wrote:
> 
> > Overlayfs uses , as an option separator and : as a list separator. These
> > characters are both valid in file paths, so overlayfs allows file paths
> > which contain these characters to backslash escape these values.
> > ---
> >  src/nspawn/nspawn.c | 63 
> > +++--
> >  1 file changed, 56 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
> > index c40d50f..f7580f9 100644
> > --- a/src/nspawn/nspawn.c
> > +++ b/src/nspawn/nspawn.c
> > @@ -1237,6 +1237,42 @@ static int mount_tmpfs(const char *dest, CustomMount 
> > *m) {
> >  return 0;
> >  }
> >  
> > +static char *escaped_overlay_path(const char *path) {
> > +_cleanup_free_ char *colon_escaped = NULL;
> > +char *comma_escaped = NULL;
> > +
> > +colon_escaped = strreplace(path, ":", "\\:");
> > +if (!colon_escaped)
> > +return NULL;
> > +
> > +comma_escaped = strreplace(colon_escaped, ",", "\\,");
> > +
> > +return comma_escaped;
> 
> This looks incomplete. What happens with "\\" itself?

Ah, yes. --overlay='\\a' would become '\a' after command-line parsing,
and overlayfs' unescaping would turn that into 'a'. I'll sort it out.

> Also, it's really inefficient, since strreplace() goes through the
> string each time from the beginning.

I was looking to do something simple rather than fast, as this isn't a
particularly latency sensitive bit of code, and I wasn't confident in
the need of a generic solution, but if you think it'll have wider use,
that's fine by me.

> I think it would make sense to add a generic 
> 
>   char *shell_escape(const char *s, const char *bad);
> 
> that works like xescape() but applies shell-style escaping instead of
> C-style escaping.

This isn't exactly shell escaping as I understand it, as that would also
require putting quotation marks aroud the string in certain circumstances,
and shell_maybe_quote() handles that already.

I'd call it backslash_escape() and possibly use it inside
shell_maybe_quote().

> > +}
> > +
> > +static char *joined_and_escaped_lower_dirs(char * const *lower) {
> > +_cleanup_free_ char *s = NULL;
> > +char *ret = NULL;
> > +char * const *path;
> > +bool first = true;
> > +
> > +STRV_FOREACH_BACKWARDS(path, lower) {
> > +_cleanup_free_ char *escaped_path = NULL;
> > +escaped_path = escaped_overlay_path(*path);
> > +if (first) {
> > +if (!strextend(&s, escaped_path, NULL))
> > +return NULL;
> > +first = false;
> > +} else
> > +if (!strextend(&s, ":", escaped_path, NULL))
> > +return NULL;
> > +}
> > +
> > +ret = s;
> > +s = NULL;
> > +return ret;
> > +}
> 
> I'd prefer if we could have a routine:
> 
> char **shell_escape_strv(char **l, const char *bad);
> 
> that goes through the strv list "l", and replaces all items in-place
> with shell_escape() and returns that.
> 
> If we have that, then we can nicely invoke strv_join() after
> shell_escape_strv(), and all would be good and simple.

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

Re: [systemd-devel] [PATCH 1/9] util: Add unescape_first_word()

[Richard Maw]

On Thu, Jun 18, 2015 at 08:30:22PM +0200, Lennart Poettering wrote:
> On Thu, 28.05.15 13:02, Richard Maw (richard@codethink.co.uk) wrote:
> 
> > This is a superset of the functionality of unquote_first_word, allowing
> > non-whitespace separators, and doesn't interpret quotes unless
> > UNQUOTE_QUOTES is included in flags.
> 
> Hmm, makes sense, but I'd actually just have one function
> extract_first_word() then, which replaces unquote_first_word() but has
> the signature of your unescape_first_word(). It would take the
> separators parameter, which would default to WHITESPACE if passed as
> NULL. THe flags should all be renamed EXTRACT_xyz instead of
> UNQUOTE_xyz then, and EXTRACT_UNQUOTE should be a prominent flag.

Thanks, I was sweating the nomeclature and wasn't happy with what I came up
with, but couldn't think of anything better.

> Then, all our current users of unquote_first_word() should be changed
> to use this new call.
> 
> Does that make sense?

Sure, I was just a little wary of making such wide changes across the codebase.

I also saw a couple of TODOs to convert uses of FOREACH_WORD family to the
unquote_many_words family. I'll see if I can feasibly convert those while I'm
changing string handling elsewhere.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-detect-virt and virtualbox 5.0

[Igor Bukanov]

Hello,

forthcoming VirtualBox 5.0 hypervisor (currently at RC1) supports
paravirtualization using Hyper-V or KVM interfaces. When the latter is
used with a linux guest then systemd-detect-virt prints kvm. I suppose
at least the manual page for systemd-detect-virt should be updated to
indicate that  the command output does not reflect a particular
implementation but names hupervisor technology.

However, the issue then is what to do with ConditionVirtualization=
testing for oracle in unit files. Under kvm mode that gives false
preventing in my case mounting a host directory with config files
using vboxsf module. I suppose I should just deal with that and try to
mount vboxsf share both under kvm and oracle, but perhaps
systemd-detect-virt should be updated to still print oracle even when
VirtualBox uses paravirtualization?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Improve boot-time of systemd-based device, revisited

[Daniel Mack]

On 06/19/2015 09:34 AM, Chaiken, Alison wrote:
> ceel, are you aware that readahead is deprecated in systemd and has not 
> been included since about release 216?   Some of us in automotive are 
> still working on it.   I have some patches here
> 
> https://github.com/chaiken/systemd-hacks/tree/packfilelist
> 
> against 215 that add various features.   We may soon be forward-porting 
> these, along with readahead itself, to the latest version.

FWIW, an approach that will probably save you a lot of rebasing work in
the future would be to rip out the readahead bits from that tree and put
it into a repository of it own. It's a standalone tool that just
happened to live in the systemd repo in the past. Some of the helper
functions would need to be copied over as well, but that should be
manageable.

That way, you can even accept patches from other people and roll your
own releases etc.


HTH,
Daniel

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

Re: [systemd-devel] nspawn: No Return key in machinectl login?

[Tobias Hunger]

Thanks for the reply!

I'll try to collect all requested info tonight or over the weekend.

Best Regards,
Tobias

On Thu, Jun 18, 2015 at 9:24 PM, Lennart Poettering
 wrote:
> On Tue, 26.05.15 21:40, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
>> This is stty -a from outside the container:
>>
>> speed 38400 baud; rows 46; columns 114; line = 0;
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?;
>> eol2 = M-^?; swtch = ; start = ^Q;
>> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
>> min = 1; time = 0;
>> -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
>> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
>> -ixon -ixoff -iuclc ixany imaxbel -iutf8
>> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 
>> ff0
>> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
>> -echoprt echoctl echoke
>>
>> This is stty -a inside the nspawn-container:
>>
>> speed 38400 baud; rows 46; columns 114; line = 0;
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
>> eol2 = ; swtch = ; start = ^Q;
>> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
>> min = 1; time = 0;
>> -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
>> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
>> -ixon -ixoff -iuclc -ixany -imaxbel iutf8
>> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 
>> ff0
>> isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop
>> -echoprt -echoctl echoke
>>
>> The difference is:
>> eol, eol2, -icrnl -ixany -imaxbel iutf8 -iexten -echoctl
>
> Sorry for the late reply...
>
> Hmm, I think the most interesting info would actually be to see stty
> -a from a working instance, and from a non-working
> instance. I.e. start the container, log into it, type "stty -a" command when
> everything works, and when it doesn't, and let me know the diff of it.
>
> Also, right after doing the "stty -a" in the container, please run the
> same commands on the host, in a seperate xterm, but connect to the
> host side container tty using "stty -a -F /dev/pts/xyz", where
> /dev/pts/xyz is the pts that nspawn itself is running on.
>
> Or to explain it in more steps:
>
> a) open an xterm of some form
>
> b) type "tty" into it, and remember the pty name it responds. It
>should be something like "/dev/pts/xyz".
>
> c) now run systemd-nspawn inside the xterm, and login there, then type
>"stty -a" in it, and save the output that command generated
>somewhere.
>
> d) now, leave everything as it is now, open a second xterm. In it run
>"stty -a -F /dev/pts/xyz", replacing "/dev/pts/xyz" with the pty
>name from step b) and save the output somwhere.
>
> Then, close both xterms. Do these steps once for a container where
> things work, and once for a container where things are borked. Then
> let me know the diffs between the working and non-working outputs from
> both runs of c), as we as the diffs between the working and
> non-working outputs from both runs of d).
>
> Make sure you take the stty snapshots at the exact same states each
> time, because shells and so on tend to toggle some bits of it
> depending on whether they are in the fg or not...
>
> Also, it would be good, to check if different xterm implementations
> (gnome, kde, original xterm) behave differently.
>
> 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] Improve boot-time of systemd-based device, revisited

[Chaiken, Alison]

cee1  writes:

2. Add a kernel sockopt for AF_UNIX to increase the maximum datagram
queue length for SOCK_DGRAM sockets.


ceel, are you aware of the (hopefully) pending full merge of kdbus in 
kernel 4.2?   And that it is essentially a bottoms-up redesign of IPC 
that supports the existing D-Bus API?



3. Since boot-up tends to be IO bound, some IO optimization:


That's not true in many systems, of course, notably the ones that need 
network to come up, as discussed previously.



3.1 "consider disabling readahead collection in the shipped devices,
but leave readahead replay enabled."


ceel, are you aware that readahead is deprecated in systemd and has not 
been included since about release 216?   Some of us in automotive are 
still working on it.   I have some patches here


https://github.com/chaiken/systemd-hacks/tree/packfilelist

against 215 that add various features.   We may soon be forward-porting 
these, along with readahead itself, to the latest version.



The readahead doesn't work very well on my experiment,


I spent considerable time performing boot experiments on production 
hardware, including trying different I/O schedulers.My conclusion 
was that readahead provides benefits in boot-time only when large, 
monolithic binaries start. If these gigantic applications were 
rearchitected to be more modular and could load libraries dynamically 
when needed instead of all at once, I suspect that the speedup 
associated with readahead would vanish.   Nonetheless, under the right 
conditions, readahead may speed up boot on real hardware in 
product-relevant conditions.


The problem is actually quite complex in the case of eMMC boot devices, 
which have their own sophisticated embedded controllers.   To properly 
optimize the whole system, we need to know the behavior of that 
controller and model what happens at boot in the full system using 
different Linux I/O schedulers and readahead strategies.   Unfortunately 
we don't have all that information.   My suspicion is that we might 
actually boot faster from raw NAND flash, but then of course we have to 
perform our own wear-levelling and block sparing.



The replaying sequence: A, B, C
The actual requesting sequence: C, B, A
If we can figure out the requesting sequence, it can achieve real read 
"ahead"[1].


I have verified in detail that readahead worked as intended: the degree 
to which the system was I/O-bound did decrease, even in cases where 
there was no net speedup.


4. Get rid of systemd-cgroups-agent. This requires introduction of a
new kernel interface to get notifications for cgroups running empty,
for example via fanotify() on cgroupfs.
Is there any related work in processing?


Are you aware of "JoinControllers"?   You appear to have old versions of 
software, which doesn't garner much sympathy from developers.



These makes it hard to use systemd in a customized system.


The Linux services business benefits from churn in userspace code . . .


What I call
for is to make the cold boot logic "declarative", something like:
main.c:
log_to_A
mount_X
mount_Y


Good news: you are free to choose SysVInit.


I wonder whether a property system also makes sense in systemd's world?


systemd unit files are already declarative lists of properties, right?

Best wishes,
Alison

---
"Tunable parameter values found on the Internet . . . [are] akin to 
raiding someone else's medicine cabinet . . . "  -- Brendan Gregg, 
_Systems Performance_, p.23

http://brendangregg.com/linuxperf.html

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

Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan

[Kai Krakow]

Lennart Poettering  schrieb:

> On Sat, 30.05.15 19:55, Kai Krakow (hurikha...@gmail.com) wrote:
> 
>> The next issue with your argument is: AFAIR nspawn doesn't create a
>> macvlan interface based on the machine name. You have to pass the name of
>> a physical interface which transports this macvlan. The man page at least
>> states that you use an existing physical interface:
> 
> True, I was a bit confused there...

:-) Fine. I thought I was totally wrong.

>> So your assumption about macvlan seems to be incorrect. The other network
>> types may be based off the machine name but it doesn't work this way with
>> macvlan.
> 
> Yeah, nspawn creates a n interface "mv-foo" from a network interface
> "foo" on the host.

Yes, it creates it on the host. In the guest, AFAIR (I cannot currently try 
this), it creates host0 as interface.

Correct me if I'm wrong, but I see macvlan as a sort of peer-to-peer level2 
LAN. The host endpoint is mv-foo, each guest has its own endpoint host0, 
spanning a virtual switch accross all peers, thus between mv-foo and each 
host0.

>> I think the logic is wrong here in systemd-nspawn. Instead of trying to
>> create the host-side macvlan itself it should insist of it being there
>> already (to have one well-defined state to start with, and only
>> optionally create it by itself). Then, it can join multiple machines to
>> the same macvlan.
> 
> I don't grok this?
> 
> "the same macvlan"?

Well, the level2 peer-to-peer LAN...

So, in this context, mv-foo should only be created once. Successive guests 
should only be joined to the existing macvlan.

> I have the suspicion that the confusion here stems from the fact that
> nspawn creates the macvlan iface on the host first, then moves it into
> the container. but if you already have an iface by that name on the
> host, then it cannot create the macvlan under that name.

I don't think this is how it worked as far as I remember, but as already 
pointed out: I still have to try that again. Currently my setup refuses to 
run the machines, I need to reconfigure the system first to get one machine 
up and running.

In this context: I think when it worked, it created mv-foo on the host (so 
you are true here), but it won't move it into the container. It creates a 
companion device there called host0. This is a level2 peer-to-peer network 
in the kernel. So maybe host0 is created in the host, then moved into the 
container - I'm not sure. Other peers could be joined.

The mv-foo interface is a virtual MAC address on the host. If you created it 
manually, you would join more virtual interfaces to the physical interface, 
i.e. host0 from the container.

Each peer interface can communicate with the others but not with the 
physical interface directly, except your switch has packet mirroring 
capabilities and would send packages back to the port they originated from - 
this is usually not encouraged by the ethernet switch specification.

The kernel's MACVLAN implementation won't pass packets to the physical 
interface directly but always through the medium connecting to the switch, 
and the switch won't pass it back on the same physical port by sane 
reasoning. However, the kernel would pass packets between MACVLAN peers it 
locally knows without touching the physical interface. The physical 
interface is only a transport medium for non-local (from view of MACVLAN 
known MACs) packets.

To overcome this issue, I need to configure mv-foo to receive my DHCP lease 
instead of the physical interface. Now each peer can communicate with my LAN 
and each other MACVLAN peer of my physical interface (which now includes my 
host mv-foo on layer3). The ḾAC address of the physical interface is more or 
less unused.

> I figure we can fix that by creating the iface under a random name
> first on the host, then move it into the container, and then rename it
> to the right name afterwarads.

The problem is with the interface that stays in the host, not with the 
interface in the container. This fix may be for a second problem I did not 
yet observe.

> A work-around would be to name the .netdev iface of yours something
> else than "mv-enp5s0", call it "waldi" or so, so that it doesn't
> conflict with the name for the contaainer in the short time-frame that
> the iface nspawn creates exists on the host...

I need to create this manually with networkd and configure it as DHCP client 
for the above reasons. Otherwise my host communicates through the physical 
interface "foo" instead of "mv-foo", which effectively disables 
communication with the MACVLAN peers for the above outlined reasons.

> Can you verify if such a change fixes your issue? If so, we can
> randomoize the name initially, as sugegsted above.

I'll first restore a configuration which gets one container up and running 
again with working MACVLAN, then we can figure out where the problem is. I 
somehow believe your guess about the source of the issue is currently not 
quite right. Such a machine cou