Re: [systemd-devel] journalctl - "Error was encountered while opening journal files: Invalid argument"
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
-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"
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
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
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
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
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
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
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
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?
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
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
В 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
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
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?
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
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
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
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
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
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
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
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]
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
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()
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
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
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
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()
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
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
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?
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
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
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