Re: [systemd-devel] Is systemd-cryptsetup binary internal?

[Dimitri John Ledkov]

On Mon, 18 Sept 2023, 17:43 Nils Kattenbeck,  wrote:

> > Why was the decision taken to put these into /usr/lib/systemd instead of
>> > /usr/libexec/systemd/?
>>
>> That's a Fedoraism. Why would one put something there?
>>
>> /usr/lib/ is where private arch-dependent package stuff goes. What's
>> the rationale for /usr/libexec/ though?
>>
>
> I am not aware of it being a Fedoraism. It is at least also used/populated
> on an Ubuntu server I use and documented as part of the filesystem
> hierarchy (hier(7)):
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528
>


On Ubuntu we mostly use multiarch locations for shared libraries i.e.
/usr/lib/(arch triplet) and /usr/libexec/(native only binaries). To allow
us to have additional places for native only and cross only tools. But it
is not set in stone. Many gnome, KDE, dbus things ship their binaries or
daemons or plugins under /usr/libexec. It sort of makes sense as /usr/lib
is confusing when it mixes public libraries, with private libraries and
binaries.

We can move things around in systemd as well, but on grand scheme of things
it is fairly minor tidy up, as neither locations are in default executable
paths. /usr/lib is in library search path, which was recently abused to
attack remote hosts to load unintended libraries at runtime and clear nx
(the recent ssh attack is hallarious and did use systemd to show really fun
stuff). So keeping only public libraries in /usr/lib going forward might be
a good idea.

>

Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support

[Dimitri John Ledkov]

On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen  wrote:
>
> On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 
> at 7:15 PM Jarkko Sakkinen  wrote:
> > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote:
> > > > Hello,
> > > >
> > > > this patch implements UKI support for kexec_file_load. It will require 
> > > > support
> > > > in the kexec-tools userspace utility. For testing purposes the 
> > > > following can be used:
> > > > https://github.com/Cydox/kexec-test/
> > > >
> > > > There has been discussion on this topic in an issue on GitHub that is 
> > > > linked below
> > > > for reference.
> > > >
> > > >
> > > > Some links:
> > > > - Related discussion: https://github.com/systemd/systemd/issues/28538
> > > > - Documentation of UKIs: 
> > > > https://uapi-group.org/specifications/specs/unified_kernel_image/
> > > >
> > > > Jan Hendrik Farr (1):
> > > >   x86/kexec: UKI support
> > > >
> > > >  arch/x86/include/asm/kexec-uki.h   |   7 ++
> > > >  arch/x86/include/asm/parse_pefile.h|  32 +++
> > > >  arch/x86/kernel/Makefile   |   2 +
> > > >  arch/x86/kernel/kexec-uki.c| 113 +
> > > >  arch/x86/kernel/machine_kexec_64.c |   2 +
> > > >  arch/x86/kernel/parse_pefile.c | 110 
> > > >  crypto/asymmetric_keys/mscode_parser.c |   2 +-
> > > >  crypto/asymmetric_keys/verify_pefile.c | 110 +++-
> > > >  crypto/asymmetric_keys/verify_pefile.h |  16 
> > > >  9 files changed, 278 insertions(+), 116 deletions(-)
> > > >  create mode 100644 arch/x86/include/asm/kexec-uki.h
> > > >  create mode 100644 arch/x86/include/asm/parse_pefile.h
> > > >  create mode 100644 arch/x86/kernel/kexec-uki.c
> > > >  create mode 100644 arch/x86/kernel/parse_pefile.c
> > > >
> > > > --
> > > > 2.40.1
> > >
> > > What the heck is UKI?
> >
> > Unified Kernel Images. More details available here:
> > https://uapi-group.org/specifications/specs/unified_kernel_image/
> >
> > It's a way of creating initramfs-style images as fully generic,
> > reproducible images that can be built server-side.
>
> You can build today a kernel with these compiled in:
>
> 1. EFI stub
> 2. initeramfs
> 3. cmdline
>
> Why another way (and label 'UKI') for a pre-existing feature?
>

In Ubuntu, we have considered to use the existing kernel features
before going off to use UKI. Here are some of the reasons why we
didn't opt to use the kernel builtin things:
1) we wanted to have ability to have TPM measured kernel commandline
performed before kernel is being executed, which is what sd-stub
provides us
2) we wanted to have ability to update / regenerate initrd, without
rebuilding kernel. Thus whenever userspace in the initrd needs
updating, we can generate new initrd for existing kernel build, create
new kernel.efi, whilst using existing .linux / vmlinuz build. I don't
believe it is currently trivial to relink vmlinuz with builtin initrd.
3) licensing wise it was not clear if initrd has to be GPLv2
compatible when linked inside vmlinuz, or if it can contain GPLv3 /
LGPLv3 userspace code - with UKI it is believed unambigiously true,
because vmlinuz boots by itself standalone and is compiled separately
of the UKI.
4) we wanted to have ability to override cmdline via kernel args
without secureboot, and use stock cmdline args under secureboot, to
allow debugging & production behaviour from a single signed kernel.efi
(that was custom development, and could be done in the stock vmlinuz
too).
5) obvious mention, the intention here is to have TPM PCR measurements
and Secureboot signature for vmlinuz and initrd and cmdline and dtb.
There is otherwise no support for standalone signed initrd, cmdline,
dtb today. Nor does vendoring it into vmlinuz achieves this to the
same extent (and ease of predicting for sealing / resealing purposes).
6) in Ubuntu kernel.efi also has sbat section for targeted revocations
(discussed separately elsewhere)

Overall, it is mostly about flexibility to be able to reuse the same
initrd against multiple kernel builds, or update use multiple initrd
against the same kernel build. This is imho the biggest issue with
using initrd built-into the vmlinuz itself.
Resource wise, the initrd passed in via kernel.efi can be freed, as
far as I understand. I don't know if the one built-into the vmlinuz is
freeable.

Improving design to do something else instead of UKI would be
welcomed. Or for example improving the zimg linus upstream format to
be a partial or a valid UKI would help as well. For example, building
the kernel built-in initrd as a .initrd section that is replacable
would be nice, or allowing to preload zimg with .dtb or .cmdline
sections would help, and appropriately improve the linux efi stab to
do measurements and loading of .dtb / .initrd from itself would be
nice. Because then all the benefits / requirements described above
could be made available out of the box and be trivially 

Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Dimitri John Ledkov]

On Mon, 7 Aug 2023 at 17:26, Lennart Poettering  wrote:
>
> On Do, 20.07.23 01:59, Dimitri John Ledkov (dimitri.led...@canonical.com) 
> wrote:
>
> > Some deployments that switch back their modern v2 host to hybrid or v1, are
> > the ones that need to run old workloads that contain old systemd. Said old
> > systemd only has experimental incomplete v2 support that doesn't work with
> > v2-only (the one before current stable magick mount value).
>
> What's stopping you from mounting a private "named" cgroup v1
> hierarchy to such containers (i.e. no controllers). systemd will then
> use that when taking over and not bother with mounting anything on its
> own, such as a cgroupv2 tree.
>
> that should be enough to make old systemd happy.
>

Let me see if I can create all the right config files to attempt that.
I have some other constraints which may prevent this, but hopefully i
can provide sufficient workarounds to get this over the barrier.


--
okurrr,

Dimitri

Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Dimitri John Ledkov]

Some deployments that switch back their modern v2 host to hybrid or v1, are
the ones that need to run old workloads that contain old systemd. Said old
systemd only has experimental incomplete v2 support that doesn't work with
v2-only (the one before current stable magick mount value).

Specifically that is trying to run sustemd v229 in a container:

https://bugs.launchpad.net/ubuntu/xenial/+source/systemd/+bug/1962332

When cgroupsv2 got added in the kernel doesn't matter, as much as, when
systemd started to correctly support cgroupsv2.
https://github.com/systemd/systemd/commit/099619957a0/

This shipped in v230 in May 2016, and I failed to backport this to v229 and
make it work in a container on an otherwise v2-only host - it still failed
to start for me.

230 was one month too late, and hence v229 shipped in Xenial Ubuntu 16.04
LTS, which will be supported through to 2026, including as a container on
newer hosts. Which for now only works if host is in hybrid or v1 modes.

To me, 6 years support is too short for the case of old container on a new
host.

And I wish to resolve inability for v229 to start as a container on v2-only
host and open to ship any minimal backport fix to unblock this.

The inverse problem of running newer containers on older systems also
exists, but usually such deployments find a way to also get newer hosts
easily.

Has anyone else managed to run v229 in a container on a v2-only host?



On Thu, 21 Jul 2022, 10:04 Lennart Poettering, 
wrote:

> Heya!
>
> It's currently a terrible mess having to support both cgroupsv1 and
> cgroupsv2 in our codebase.
>
> cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago
> (kernel 3.16). We soon intend to raise the baseline for systemd to
> kernel 4.3 (because we want to be able to rely on the existance of
> ambient capabilities), but that also means, that all kernels we intend
> to support have a well-enough working cgroupv2 implementation.
>
> hence, i'd love to drop the cgroupv1 support from our tree entirely,
> and simplify and modernize our codebase to go cgroupv2-only. Before we
> do that I'd like to seek feedback on this though, given this is not
> purely a thing between the kernel and systemd — this does leak into
> some userspace, that operates on cgroups directly.
>
> Specifically, legacy container infra (i.e. docker/moby) for the
> longest time was cgroupsv1-only. But as I understand it has since been
> updated, to cgroupsv2 too.
>
> Hence my question: is there a strong community of people who insist on
> using newest systemd while using legacy container infra? Anyone else
> has a good reason to stick with cgroupsv1 but really wants newest
> systemd?
>
> The time where we'll drop cgroupv1 support *will* come eventually
> either way, but what's still up for discussion is to determine
> precisely when. hence, please let us know!
>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Dimitri John Ledkov]

Hi,

On Tue, 13 Jun 2023 at 16:01, Richard Purdie
 wrote:
>
> On Tue, 2023-06-13 at 15:56 +0100, Dimitri John Ledkov wrote:
> > Nobody is retroactively changing existing systemd releases.
> >
> > Stay on a previously released systemd version which will continue to
> > have features it used to have.
>
> I've seen the responses to bug reports with "not latest" releases of
> systemd so I doubt that is really to be recommended.
>

I don't believe Yocto is a blocker to land this change in the new
systemd upstream release, given the sufficient notice previously
issued.

If Yocto is so out of date, affected users can also migrate to other
embedded immutable distributions available out there: Ubuntu Core,
Fedora IOT, openSUSE MicroOS and similar.

-- 
okurrr,

Dimitri

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Dimitri John Ledkov]

Nobody is retroactively changing existing systemd releases.

Stay on a previously released systemd version which will continue to have
features it used to have.


On Tue, 13 Jun 2023, 15:53 Richard Purdie, <
richard.pur...@linuxfoundation.org> wrote:

> On Tue, 2023-06-13 at 15:31 +0100, Luca Boccassi wrote:
> > On Tue, 13 Jun 2023 at 15:15, Richard Purdie
> >  wrote:
> > >
> > > On Tue, 2023-06-13 at 11:29 +0100, Luca Boccassi wrote:
> > > > On Tue, 20 Sept 2022 at 20:18, Luca Boccassi 
> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Following this thread started back in April:
> > > > >
> > > > >
> https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html
> > > > >
> > > > > As far as we understand there are no distributions running or
> > > > > optionally supporting systemd that have not either completed, or at
> > > > > least started, the transition to merged-usr systems.
> > > > >
> > > > > So, we are planning to drop support for unmerged-usr systems in the
> > > > > first release that will happen in the second half of next year,
> I.E.:
> > > > > any time starting from July 2023 (while we tend to release somewhat
> > > > > regularly we do not have strict dates and deadlines, so right now
> it's
> > > > > not possible to tell the exact version, but it will be of course
> > > > > communicated once it becomes clear).
> > > >
> > > > As previously announced, this is being prepared now and will be part
> of v254:
> > > >
> > > > https://github.com/systemd/systemd/pull/27999
> > >
> > > I'd note that nobody did resolve the issues for Yocto Project yet so
> > > our CI will break if we try and upgrade :(.
> >
> > Those issues are purely internal to Yocto's custom CI and completely
> > unrelated to systemd, as they manifest without systemd being even
> > enabled. The 'usrmerge' distro feature was added six years ago, in
> > 2017, by Yocto developers:
> >
> >
> https://git.yoctoproject.org/poky/commit/?id=178e983cf745fe32b199e0cbfe9777270124b186
> >
> > If even Yocto developers cannot manage to fix internal CI issues
> > created by internal features added by Yocto developers in 6 years,
> > there's hardly anything outsiders could possibly do, I'm afraid.
>
> The issue is that Yocto Project supports a variety of configurations
> and systemd has decided to drop support for some of them.
>
> Nobody has done the work to migrate the configuration combinations
> being dropped in Yocto Project.
>
> Distro features are optional in Yocto Project, we don't force people to
> use them. There are plenty of people with products shipping in the wild
> which do not use the "usrmerge" feature. Our own test matrix hasn't
> been adjusted to force usrmerge for systemd, nor is the documentation
> or migration information present for that change.
>
> This is not an issue caused by our "internal features" and to claim
> that is farcical.
>
> Richard
>
>
>
>
>
>
>
>
>

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Dimitri John Ledkov]

On Tue, Nov 23, 2021 at 12:09 PM Lennart Poettering
 wrote:
>
> On Di, 23.11.21 11:53, Dimitri John Ledkov (dimitri.led...@canonical.com) 
> wrote:
>
> > Just an update from Ubuntu - for the upcoming release of Jammy (22.04
> > LTS targeting release in April 2022) we have started transition to
> > OpenSSL 3 and currently upgrading to systemd v249.
>
> Did Ubuntu adopt Debian's stance of accepting OpenSSL as system
> component? i.e. is OpenSSL 3 compatible with both (L)GPL 2.x code
> *and* GPL3 code in Ubuntu's eyes? Or only the latter?

I cannot possibly comment on or answer the above questions.

You might find some related comments from Ubuntu Archive team at
https://lists.ubuntu.com/archives/technical-board/2021-October/002587.html

Jammy will ship OpenSSL v3. Once it migrates, I will enable Jammy CI
against systemd pull requests, to ensure that the next systemd release
works on Jammy.

Regards,

Dimitri.

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Dimitri John Ledkov]

Just an update from Ubuntu - for the upcoming release of Jammy (22.04
LTS targeting release in April 2022) we have started transition to
OpenSSL 3 and currently upgrading to systemd v249.

W.r.t. library choice usually GnuTLS APIs are nicer to use; however
OpenSSL library tends to be the more performant one with more HW
optimizations, and easier to certify. These two properties alone make
me prefer OpenSSL whenever possible.

Regards,

Dimitri.

Re: [systemd-devel] Suppressing spam error messages in the system journal

[Dimitri John Ledkov]

I agree that i should have had much lower log level.

This is now fixed properly upstream via
https://github.com/systemd/systemd/pull/18638/files

I will try to backport that to stable series or at least drop the log
level to debug.


On Mon, 19 Oct 2020 at 15:05, Michael Biebl  wrote:
>
> Am Mo., 19. Okt. 2020 um 15:56 Uhr schrieb Lennart Poettering
> :
> >
> > >   2) Could resolved be changed so that this message is only emitted
> > > (say) once for every 100 or 500 times that the condition is
> > > detected.
> >
> > We actually try hard to suppress unnecessary log lines, but I think
> > this one is a downstream change.
> >
>
>
> https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch?h=ubuntu/focal-updates
>
> Bringing Dimitri into the loop here.
>
> Michael



-- 
Regards,

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

Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

[Dimitri John Ledkov]

On Mon, 22 Jun 2020 at 18:03, Reindl Harald  wrote:
>
>
>
> Am 22.06.20 um 17:21 schrieb Mantas Mikulėnas:
> > On Mon, Jun 22, 2020 at 5:01 PM Reindl Harald  > > wrote:
> >
> > what is the best way to get a Fedora using legacy-boot to UEFI and at
> > the same time switch from grub2 to systemd-boot?
> >
> >
> > This isn't a Fedora mailing list?
>
> but a systemd-list, sorry for mention the distribution instead as others
> only throw "how can i get systemd-bott working" into the ring
>
> > can /boot holding the kernel itself still be a Linux RAID1 or classical
> > ext4 partition or is it required that the kernel and initrd live on the
> > EFI partition too?
> >
> > For systemd-boot, the kernel is required to be on the same EFI partition
> ok, so it will become grub in uefi mode, no way that i store my kernel
> on vfat

You can enroll your own PK, KEK, DB keys, and sign & install your own
UEFI drivers which implement other file systems see
https://github.com/pbatard/efifs/tree/master/EfiFsPkg

-- 
Regards,

Dimitri.

-- 
Regards,

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

Re: [systemd-devel] What is the point of making timesyncd bus-activatible?

[Dimitri John Ledkov]

On Tue, 19 May 2020 at 10:31, Arian Van Putten  wrote:
>
> Hey list,
>
> systemd-timesyncd has an Alias=dbus-org.freedesktop.timesync1.service and an 
> accompanying dbus service file too.
>
>  It is started in early boot; `Before=sysinit.target`  so why would making it 
> dubs-activatible ever make sense? It is always started way before 
> dbus.service itself is started.
>
> It also seems that the unit type is not Type=dbus (and doesn't set a BusName) 
> which confuses me a bit. So maybe I'm misunderstanding how dbus integration 
> works here. Ist that because we want to consider the services "ready" before 
> they even register a name on the bus?
>
> Similarly systemd-resolved.service and systemd-networkd.service have such 
> aliases whilst they're both pulled in by `multi-user.target` and also do not 
> have `Type=dbus` and `BusName=` set.
>
> What are the reasons for that?   For resolve1 i guess it makes sense as you 
> dont have to think about ordering when making dns calls in services. But I am 
> still confused why it is not of Type=dbus. Is that because it not only gives 
> a dbus API but also a DNS api?
>

it serves requests on 127.0.0.53 and provides dynamic files generated
in /run/systemd/resolve/ which can be targets of /etc/resolv.conf
symlink. Hence even without anything talking to it over dbus or lo
interface, it can be serving information to the system. I.e. it
populates both /run/systemd/resolve/resolv.conf and
/run/systemd/resolve/stub-resolv.conf either of which can be symlinked
to /etc/resolv.conf for nss modules to use.

-- 
Regards,

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

[systemd-devel] initrd.target indirection no longer available

[Dimitri John Ledkov]

Hi,

In v245 systemd started to default to `initrd.target`, instead of
`default.target` in the initrd. However, unlike `default.target` in
the running system, `initrd.target` is not an indirection symlink.

Specifically, default.target is a symlink to like graphical.target or
like multi-user.target and nothing depends on it. Thus one can bake
images that that make default.target to be a symlink to something
else, which can divert boot to a different transaction (reach it,
start a few other transactions) and then isolate to regular
graphical.target/multi-user.target etc.

initrd.target however, is not an indirection symlink, but it s a real
one. So in my case, I do want to subvert initrd boot, reach the
transaction, run a few more transactions, and then start initrd.target
to complete the initrd stage of the boot and pivot to real root.

However it is not trivial to do so, because initrd.target semantics
are those closer to "multi-user.target" or "graphical.target", rather
than default.target (which is strictly only a symlink).

Solution 1 - Would people be open to creating:
1) default-initrd.target which is a symlink to initrd.target
2) changing main.c initrd special target to be default-initrd.target

This way, in the initrd "out of the box" things boot to
default-initrd.target -> initrd.target, but also allow to subvert
default-initrd.target to something else, and later start initrd.target
without modifying any third party that already integrates with
initrd.target (ie. dracut etc).

This also fixes regression from v244, where initrd used to boot to
default.target symlink, and one used to be able to point that symlink
to something else, instead of initrd.target, whilst preserving the
out-of-the-box correct behaviour.

Or in a closer spirit to v244 can we do something like:
Solution 2:
1) if rd.systemd.unit / --unit args passed use those
2) if default.target exists use that
3) else use initrd.target ?

Because v245 has lost sensitivity to
/etc/systemd/system/default.target symlink pointing at something else
but initrd.target.

-- 
Regards,

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

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Dimitri John Ledkov]

On Wed, 26 Feb 2020 at 09:59, Andreas Kempe  wrote:
>
> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.
>

I would expect the /etc/machine-id to exist, and be an empty file on
the RO underlay, then systemd should setup machine-id in /run, and
then after the overlay of /etc is setup to use and is RW, fire the
systemd-machine-id-commit.service unit which will transfer the
machine-id from /run into the RW /etc overlay, after that everything
else should operate "normal".

We do this in Ubuntu live installer images, which use overlayfs across
all of / on top of read-only squashfs rootfs.


> At this point we're considering a number of workarounds, but I thought
> it worthwhile asking the experts before we go patching Systemd or
> similar.

I think didrocks or pitti introduced above for all the cases we had in
ubuntu where we have RO rootfs with a writable overlay which "appears"
later.

No idea if above is suitable for you at all, and/or need tweaking.
I.e. self-transfer machine-id from /run to /etc with like adding
wants=/before= systemd-machine-id-commit.service or some such?

-- 
Regards,

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

[systemd-devel] How does systemd (pid1) connect to system DBus?

[Dimitri John Ledkov]

I see that systemd pid1 manager is available on the system DBus.

But when/how does it connect to it?

I'm failing to trace it in both systemd & dbus code. I assume that
systemd starts, eventually starts dbus.socket/service, dbus starts,
and then something causes systemd to connect to the system bus.

I see that there is USR1 signal handler, but I'm failing to find
anything that sends it to PID1.

Please send links to source code line numbers / functions. Somehow I'm
failing to trace this stuff.

-- 
Regards,

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

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

[Dimitri John Ledkov]

On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas  wrote:
>
> On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer  wrote:
>>
>> Hi Lennart, hi Tim,
>>
>> thanks a lot for your feedback, Lennart. It's much appreciated!
>>
>> Tim Dittler:
>> > On 09.10.19 19:26, Lennart Poettering wrote:
>> >> On Mi, 09.10.19 12:20, Jonas Meurer (jo...@freesources.org) wrote:
>> >>> We[1] are working on bringing luksSuspend for LUKS devices before system
>> >>> suspend to Debian. The basic idea is to remove the encryption keys of
>> >>> encrypted devices from RAM before suspending the system.
>> >>>
>> >>> While working on it, we figured out that systemd probably is the best
>> >>> place to implement this. Would you be willed to accept related patches
>> >>> into systemd? We're still early in the design process, but probably the
>> >>> relevant parts will be:
>> >>>
>> >>> [...]
>> >>>
>> >>> Lennart's talk[2] about systemd-homed mentions luksSuspend support for
>> >>> system suspend, but it's limited to home directories. The whole ramfs
>> >>> foo wouldn't be necessary to do that. So a direct question: would you
>> >>> still be ok with support for luksSuspending the encrypted root
>> >>> filesystem in systemd?
>> >>>
>> >>> Before spending days of work on implementing this in systemd only to get
>> >>> the patches rejected in the end, we thought it would be better to ask
>> >>> beforehands ;)
>> >>
>> >> The thing is, this is far from easy to implement, to the point I don't
>> >> think it's viable in the long run at all. I mean, in order to be able
>> >> to unlock the root disk after suspend you need the full input and
>> >> display stack to be up, i.e. wayland/x11/gnome in the general
>> >> case. And that's an awful lot to place in a ramdisk. You will end up
>> >> having another copy of the OS as a whole in there in the end...
>> >>
>> >> systemd-homed maintains only the home directory via LUKS encryption,
>> >> and leaves the OS itself unencrypted (under the assumption it's
>> >> protected differently, for example via verity – if immutable —  or via
>> >> encryption bound to the TPM), and uses the passphrase only for
>> >> home. THis means the whole UI stack to prompt the user is around
>> >> without problems, and the problem gets much much easier.
>> >>
>> >> So what's your story on the UI stack? Do you intend to actually copy
>> >> the full UI stack into the ramdisk? If not, what do you intend to do
>> >> instead?
>>
>> As Tim already wrote, the UI stack was not our focus so far. But I
>> agree, that it's a valid concern. My silent hope was to find a solution
>> for a simple passwort prompt that can be overlayed over whatever
>> graphical stack is running on the system. But we haven't looked into it
>> yet, so it might well be impossible to do something like this.
>>
>> But since the graphical interface is running already, I doubt that we
>> would have to copy the whole stack into the ramfs. We certainly need to
>> take care of all *new* dependencies that a password prompt application
>> pulls in, but the wayland/x11/gnome basics should just be there, as they
>> have been in use just before the suspend started, no?
>

Well, one can do what Mac OS X used to do. Take a screenshot, apply
blur, use as a background in a graphical plymouth to type unlock
password and slowly fade in as things are unfrozen.

Most desktop systems, already might include graphical plymouth already
(and like framebuffer / dri modules needed for it, among with
cryptsetup tooling but maybe not TPM one). Such that it should be
possible to "just use the initrd" one uses for boot anyway.

>
> They might not be 100% available from just memory. What happens if the DE 
> needs to load assets (fonts, .ui files) for the passphrase prompt from disk? 
> (Actually, do any GPU drivers need to load firmware from /lib on resume?)
>

In Ubuntu, casper component, we work around it by reading the files to
ensure they are in the fscache, and then if one force unmounts the
filesystem underneath them (cdrom eject) plymouth can still "read"
fonts and display late boot messages. So there are ways of doing this.

-- 
Regards,

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

[systemd-devel] /cdrom mounted from initrd is stopped on boot, possibly confused about device-bound

[Dimitri John Ledkov]

Ubuntu installer images use initrd, which has udevd but no systemd.

It mounts /dev/sr0 as /root/cdrom, then pivots to /root, meaning
/root/cdrom becomes just /cdrom and exec systemd as pid 1.

At this point cdrom.mount is stopped as it's bound to an inactive
dev-sr0.device. Then sometime later dev-sr0.device becomes active, but
nothing remounts /cdrom back in.

My question is why on startup, when processing cdrom.mount it
determines that dev-sr0 is inactive, when clearly it's fully
operational (it contains media, media is locked, and is mounted, and
is serving content).

I notice that SYSTEMD_MOUNT_DEVICE_BOUND is set to 1 on the udev
device, and it seems impossible to undo via mount unit.

I also wonder why, initially, /dev/sr0 is inactive, but later becomes
active - as in what causes it to become active, and what is missing in
the initrd.

Things appear to work if I specify in the 60-cdrom_id.rules
SYSTEMD_READY=1, then on boot there are no working messages that
cdrom.mount is bound to an inactive device.

Shouldn't 60-cdrom_id.rules set SYSTEMD_READY=1 if after importing
cdrom_id variables ID_CROM_MEDIA is not-empty? Such that
dev-sr0.device initial state is correct, if one booted with cdrom
media in place.

-- 
Regards,

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

Re: [systemd-devel] On every 'sysctl enable/disable' Systemd Reload is happening

[Dimitri John Ledkov]

On Mon, 25 Feb 2019 at 19:05, Mahesh Mylarappa  wrote:
>
> Hi,
>
> I am working on Linux host which has old 219 systemd build. We are trying to 
> create/enable/start  multiple service instances at same time. Basically we 
> create 15 to 20 unit files in /etc/systemd/system directory and call 
> 'systemctl enable' on each one of them. There is only 30 to 50ms gap between 
> each enable commands and  i could see few of those taking 10s of seconds to 
> complete. If i put log level to debug, i could see that every time a new 
> 'sysctl enable' is fired for new service instance,  there is complete reload 
> happening and queued jobs are cancelled and reissued.
>
> I understand build 219 is very old, but wanted to know if there was a similar 
> issue which was fixed in later builds.
>

What you seem to be looking for is to execute enable command
"client-side" without communicating with systemd, to check if the
units exist and are valid, and simply operate on the [Install] stanzas
requirements on the filesystem alone.

There are a number of checks that are done to switch to client side,
please see 
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L296

I don't know how old those are, but please try

1) systemctl --root=/ enable ...
2) SYSTEMCTL_INSTALL_CLIENT_SIDE=1 systemctl enable ...

I think --root=/ should be supported to switch to client-side/chroot
install mode even in 219. I have never used the undocumented
environmental variable, but maybe it is easier to use that for you, if
it works in v219.

-- 
Regards,

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

Re: [systemd-devel] GithHub / private repos

[Dimitri John Ledkov]

On Sat, 26 Jan 2019 at 12:43, Lennart Poettering  wrote:
>
> On Di, 15.01.19 21:21, Alex Dzyoba (a...@dzyoba.com) wrote:
>
> > When you create a new organization you can choose "Team For Open
> > Source" plan. Here is the link
> > https://github.com/account/organizations/new
> >
> > Though, I don't know if it's possible to upgrade the existing systemd
> > organization, sorry. Maybe it's possible to contact github support to
> > ask for this.
>
> So I had a closer look at this, and found this:
>
> https://help.github.com/articles/github-s-products/
>
> IIUC "GitHub Team for Open Source" doesn't actually add anything we
> need. Because what we need would actually be the ability for arbitrary
> people (i.e. not people who necessarily are members of our systemd
> team on github) to send us private PRs and issues in order to handle
> security issues.
>
> It appears to me that plan does not provide the core need we have:
> allow those random folks from the Internet to report security issues
> in privacy to us... Or what am I missing?
>

It doesn't seem to be exactly that.

Reading help, I guess one can create a secret issues-only repository
https://help.github.com/articles/creating-an-issues-only-repository/
The permissions look almost ok, but I fear that everyone will be able
to see all the issues. Whilst we would want to restrict issues to be
visible only by "author + write/admins". Ditto pull requests.

I guess we could create a private repository per issue. but that
will get messy quickly, although I would expect each one to be
short-lived for each individual CVE.

-- 
Regards,

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

Re: [systemd-devel] How to set `InitRDTimestampMonotonic` from console?

[Dimitri John Ledkov]

Hi,

On 4 July 2018 at 10:22, Lennart Poettering  wrote:
> On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
> wrote:
>
>> Dear systemd folks,
>>
>>
>> Debian uses a shell script as `/init` in initrd, and I like to extend that,
>> to set the time stamps for the initrd execution.
>
> This is part of the data that is serialized during the transition from
> the systemd instance in the initrd to the systemd instance on the
> host. The serialization is internal to systemd, and this is unlikely
> to change, as it contains numerous bits of information that are
> fragile and sensitive as the serialization really contains the full
> service manager state with all its units and so on.
>
>> Is it possible to set that value from a shell script? If yes, could you
>> please tell me how?
>
> It's not, and quite frankly I am not enthusiastic about the idea to
> make this configurable...

At one point, I was considering to serialize just enough data to add
these in the initramfs-tools (and/or systemd) as Debian specific
patches to start supporting these measurements.
And have a distro patch in systemd to read these measurements from a
separately serialized file on boot-up.

Also, there are bootloader measurements, that I think we do not
receive either from grub.

-- 
Regards,

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

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 16 April 2018 at 18:20, Paul Menzel
<pmenzel+systemd-de...@molgen.mpg.de> wrote:
> Dear Dimitri,
>
>
> On 04/16/18 18:51, Dimitri John Ledkov wrote:
>
>> On 16 April 2018 at 14:25, Paul Menzel wrote:
>
>
>>> On 04/16/18 12:47, Dimitri John Ledkov wrote:
>>>>
>>>>
>>>> On 13 April 2018 at 16:40, Paul Menzel wrote:
>>>
>>>
>>>>> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
>>>>> ordering of systemd-resolved.service was changed. (How do I find the
>>>>> merge
>>>>> request to find possible discussion? Also the commit message
>>>>> description
>>>>> is
>>>>> too specific in my opinion, as it doesn’t give a clue that more is
>>>>> changed.)
>>>>
>>>>
>>>>
>>>> https://github.com/systemd/systemd/pull/7609
>>>
>>>
>>> Thank you, no idea, why I didn’t find it with `git log --oneline
>>> --graph`.
>>> Hmm, looks like, Lennart directly put that commit in master without
>>> merging
>>> the pull request.
>>>
>>>>> I like starting systemd-resolved earlier, but unfortunately ordering it
>>>>> before `network.target` adds a delay on systems wanting to start as
>>>>> fast
>>>>> as
>>>>> possible. But why did you change it from `network-online.target` to
>>>>> `network.target`? I’d say `network-online.target` is more correct.
>>>>>
>>>>> For my use case of a fast system start-up, this change delays it by at
>>>>> least
>>>>> 100 ms, as now it takes longer to reach the end of the network target.
>>>>
>>>>
>>>>
>>>> cloud-init initializes networking configuration by fetching,
>>>> potentially, remote sources to customize an instance on first boot.
>>>> Specifically it may dhcp any interface, to reach a metadata source,
>>>> download the real networking configuration, reconfigure networking to
>>>> match the final networking details (all interfaces / public ip
>>>> addresses / etc), and proceed to complete networking.target and
>>>> network-online.target.
>>>>
>>>> This means that resolved is required earlier in the boot cycle. Before
>>>> networking.target.
>>>
>>>
>>>
>>> Just to be sure, you mean *network.target*, right?
>>>
>>> Thank you for specifying the requirement. I agree, that it should be
>>> started
>>> as early as possible, but I disagree with the rest.
>>>
>>>> There are things that expect network to be up in
>>>> "network-online.target", which by some is implied to mean DNS
>>>> resolution too, unfortunately.
>>>
>>>
>>>
>>> Sorry for being ignorant, but could you please be specific, what these
>>> things are. If these units have that requirement order them after
>>> `network-online.target`.
>>>
>>>>> If your systems have problems with it, they have wrong dependencies,
>>>>> don’t
>>>>> they? Also, they should probably be able to deal with the situation,
>>>>> that
>>>>> DNS does not work, as that can happen during operation.
>>>>>
>>>>> So, I’d really like to rework that ordering change.
>>>>
>>>>
>>>>
>>>> Reworking that change will break certain public cloud providers
>>>> unfortunately because of public clouds metadata providers being odd.
>>>>
>>>> Note, we cannot use dbus activation in this case as dbus-daemon is not
>>>> up yet, and systemd-resolve command line client also does not work at
>>>> this point.
>>>>
>>>> If you want to make it an optional dependency that early, maybe it
>>>> will be possible to convert systemd-resolved to be socket activated on
>>>> tcp/udp?
>>>>
>>>> Alternatively, as a system integrator, you may want to change these
>>>> dependencies in your distro, especially if you do not configure
>>>> resolved _stub resolver_ as the default provider of /etc/resolv.conf
>>>> or for example to do not use the recommended default stub-provider
>>>> over 127.0.0.53 and instead use the nss module over dbus.
>>>>
>>>> The above dependencies are correct and recommend, for the default
>>>>

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 16 April 2018 at 14:25, Paul Menzel
<pmenzel+systemd-de...@molgen.mpg.de> wrote:
> Dear Dimitri,
>
>
> Thank you for your quick response.
>
>
> On 04/16/18 12:47, Dimitri John Ledkov wrote:
>>
>> On 13 April 2018 at 16:40, Paul Menzel wrote:
>
>
>>> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
>>> ordering of systemd-resolved.service was changed. (How do I find the
>>> merge
>>> request to find possible discussion? Also the commit message description
>>> is
>>> too specific in my opinion, as it doesn’t give a clue that more is
>>> changed.)
>>
>>
>> https://github.com/systemd/systemd/pull/7609
>
>
> Thank you, no idea, why I didn’t find it with `git log --oneline --graph`.
> Hmm, looks like, Lennart directly put that commit in master without merging
> the pull request.
>
>>> I like starting systemd-resolved earlier, but unfortunately ordering it
>>> before `network.target` adds a delay on systems wanting to start as fast
>>> as
>>> possible. But why did you change it from `network-online.target` to
>>> `network.target`? I’d say `network-online.target` is more correct.
>>>
>>> For my use case of a fast system start-up, this change delays it by at
>>> least
>>> 100 ms, as now it takes longer to reach the end of the network target.
>>
>>
>> cloud-init initializes networking configuration by fetching,
>> potentially, remote sources to customize an instance on first boot.
>> Specifically it may dhcp any interface, to reach a metadata source,
>> download the real networking configuration, reconfigure networking to
>> match the final networking details (all interfaces / public ip
>> addresses / etc), and proceed to complete networking.target and
>> network-online.target.
>>
>> This means that resolved is required earlier in the boot cycle. Before
>> networking.target.
>
>
> Just to be sure, you mean *network.target*, right?
>
> Thank you for specifying the requirement. I agree, that it should be started
> as early as possible, but I disagree with the rest.
>
>> There are things that expect network to be up in
>> "network-online.target", which by some is implied to mean DNS
>> resolution too, unfortunately.
>
>
> Sorry for being ignorant, but could you please be specific, what these
> things are. If these units have that requirement order them after
> `network-online.target`.
>
>>> If your systems have problems with it, they have wrong dependencies,
>>> don’t
>>> they? Also, they should probably be able to deal with the situation, that
>>> DNS does not work, as that can happen during operation.
>>>
>>> So, I’d really like to rework that ordering change.
>>
>>
>> Reworking that change will break certain public cloud providers
>> unfortunately because of public clouds metadata providers being odd.
>>
>> Note, we cannot use dbus activation in this case as dbus-daemon is not
>> up yet, and systemd-resolve command line client also does not work at
>> this point.
>>
>> If you want to make it an optional dependency that early, maybe it
>> will be possible to convert systemd-resolved to be socket activated on
>> tcp/udp?
>>
>> Alternatively, as a system integrator, you may want to change these
>> dependencies in your distro, especially if you do not configure
>> resolved _stub resolver_ as the default provider of /etc/resolv.conf
>> or for example to do not use the recommended default stub-provider
>> over 127.0.0.53 and instead use the nss module over dbus.
>>
>> The above dependencies are correct and recommend, for the default
>> setup of /etc/resolv.conf pointing at the stub-resolv.conf as
>> generated by resolved at runtime.
>>
>> Specifically, the dependencies as is are "too-early" if one uses the
>> last two modes of the /etc/resolv.conf handling as described in the
>> man page -
>> https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf
>
>
> First, I think, the terminology of *early* leads to misunderstandings. For
> you it includes ordering with `Before=`, for me it’s just about `After=`
> statements.
>

It's actually both. Cloud-init is a cross-distribution tool, and it
injects itself at multiple points during boot. It pre-empts networking
target, is between networking & network-online, and after
network-online target.

Without this upstream change, cloud-init was not able to pre-empt
network.target, was resulting in a dependency cycle, and s

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 13 April 2018 at 16:40, Paul Menzel
 wrote:
> Dear Dimitri, dear systemd folks,
>
>
> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
> ordering of systemd-resolved.service was changed. (How do I find the merge
> request to find possible discussion? Also the commit message description is
> too specific in my opinion, as it doesn’t give a clue that more is changed.)
>

https://github.com/systemd/systemd/pull/7609

>
> I like starting systemd-resolved earlier, but unfortunately ordering it
> before `network.target` adds a delay on systems wanting to start as fast as
> possible. But why did you change it from `network-online.target` to
> `network.target`? I’d say `network-online.target` is more correct.
>
> For my use case of a fast system start-up, this change delays it by at least
> 100 ms, as now it takes longer to reach the end of the network target.
>

cloud-init initializes networking configuration by fetching,
potentionally, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete netwokring.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.

There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.

>
> If your systems have problems with it, they have wrong dependencies, don’t
> they? Also, they should probably be able to deal with the situation, that
> DNS does not work, as that can happen during operation.
>
> So, I’d really like to rework that ordering change.
>

Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page - 
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf

-- 
Regards,

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

[systemd-devel] systemd-networkd-wait-online should know if there is anything to wait for

[Dimitri John Ledkov]

Hello,

When systemd-networkd-wait-online was originally introduced, it was
the only tool that correctly waited and blocked the boot, until after
networking is configured.

These days, however, all/most network configurations tools ship
appropriate wait-online integration. E.g. there is network-manager
wait online service and ifupdown wait online, on Debian/Ubuntu.

These other helpers, seem to be slightly smarter than
systemd-networkd-wait-online. Specifically, all other helpers exit
straight away, if they have no devices configured / managed. Whilst
systemd-networkd-wait-online, doesn't appear to know if it expects any
devices / can manage any devices. Ideally, if no devices are
configured / no devices match .network files, maybe it should exit
straight away? Or for example, do so if no devices are found in
"configuring/pending/not yet processed by udev".

(code wise, it is to change one_ready to true by default, and only
continue blocking the, if there is anything pending configuration).

I'm considering doing this by default, or for-example, doing it if
there are no /run/systemd/network/*.network
/etc/systemd/network/*.network files.

The use cases when it matters:

- installer ISO booted without any NICs attached
(or NICs require special drivers / firmware loaded etc)

- cloud-image booted and cloud-init failed to find network-config and
generate networkd stanzas

-- 
Regards,

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

[systemd-devel] networkd dhcp client - serialize / run stand alone / inject or restart dhcp client

[Dimitri John Ledkov]

I have a request to start/stop/restart the dhcp lease client, and/or
run networkd dhcp client stand alone, or somehow serialize dhcpclient
lease and inject that for networkd-dhcp to pick that up and restart.

For example, Ubuntu initramfs currently does not have networkd in it,
but it can bring interfaces up with dhcp.

And i'm not sure if there is a way to pass/inject the dhcp lease to
networkd as a runtime state to pick up from there. Ideally without
re-acquiring the lease once again.

I'm currently pondering if I should be trying to get networkd running
in the initramfs (without systemd in the initramfs), or like generate
a runtime networkd config for post-pivot to root.

Ideally, it would be nice to ship a "one-shot" dhcp lease acquire
helper binary, that could be shipped in the initramfs, which does
everything using the internal networkd dhcp lease and serializes the
state in /run/. Such that post-pivot, the full networkd can notice
that lease file and start running the longterm dhcp client.

Think, something like $ ipconfig -c dhcp eth0 -> as shipped by klibc-utils

Would such a util, be in-scope, for systemd-networkd?

-- 
Regards,

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

Re: [systemd-devel] Keeping track of usage time

[Dimitri John Ledkov]

On 3 November 2015 at 06:27, Umut Tezduyar Lindskog  wrote:
> journalctl --list-boots seems great actually but wouldn't work for us.
> We cannot keep lots of logs in our products.
>

You shouldn't need to keep lots of logs, just a timer unit that would
query and store/transmit the bootids/deltas (possibly in a round-robin
fashion)

Regards,

Dimitri.


> Ultimately we are trying to answer the question of how long one of our
> product has been in use.
>
> We will implement it with a .timer/.service which periodically adds
> /proc/uptime to a file and the file gets preserved over reboot.
>
> Umut
>
> On Mon, Nov 2, 2015 at 7:00 PM, Lennart Poettering
>  wrote:
>> On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>>
>>> Hi,
>>>
>>> We would like to implement a feature to keep track of accumulated
>>> values of uptimes in our products. Tracked time will give us the total
>>> usage time of our product not just since last reboot (/proc/uptime).
>>>
>>> Is upstream interested in having such implementation?
>>
>> As Dimitri suggested: wouldn't a journalctl --list-boots invocation
>> suffice for this?
>>
>> Or do you need this per-service? (where the journal should be able to
>> provide you with the answer too, of course, but with a different line)
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.
53 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Dimitri John Ledkov]

On 2 November 2015 at 14:46, Umut Tezduyar Lindskog  wrote:
> Hi,
>
> We would like to implement a feature to keep track of accumulated
> values of uptimes in our products. Tracked time will give us the total
> usage time of our product not just since last reboot (/proc/uptime).
>
> Is upstream interested in having such implementation?
>

Isn't that just the duration of each bootid from journal then?

Checkout output of:

$ journalctl --list-boots

-- 
Regards,

Dimitri.
63 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kernel and systemd boot sequence

[Dimitri John Ledkov]

Systemd is the init.

/etc/fstab is optional.

initramfs could be running systemd (e.g. dracut supports it), thus
systemd would be beofre switch_root.

However initramfs & switch_root are optional as well.

Hence the bootflow on a modern linux distribution like Clear Linux is:

kernel -> systemd -> user login.

On 29 October 2015 at 02:26, kennedy  wrote:
> the boot sequence is it right ?
> kernel --> initramfs --> switch_root --> systemd --> init & mount /etc/fstab
> --> user login
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Regards,

Dimitri.
63 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] startxfce4 vs logind

[Dimitri John Ledkov]

On 19 September 2015 at 23:05, Dimitri John Ledkov
<dimitri.j.led...@intel.com> wrote:
> Heya,
>
> I boot to tty1, and login as my normal user account.
>
> Session c1, is active and has type tty. And I can access devices which
> are marked as uaccess.
>
> Then I do $ startxfce4 -> which starts graphical interface. However,
> at that time I "loose" the logind session. No new sessions are
> started, session c1 is "Active=no" & "State=online" and i cannot
> access uaccess devices any more.
>
> Both startxfce4 and systemd are compiled without policykit support (no
> idea if this matters).
>
> What I am doing wrong? Should I go talk to xfce4 people?
>
> My expectation was for a new session c2 to be started and switched to,
> type graphical, online and active. Whilst keeping c1 tty session
> online and in-active.
>
> Is there something startxfce4 missing to act like a "mini-display-manager"?
> and/or how should it be telling logind that session became graphical
> and/or for c1 session to remain active?
>

With a bit of help on IRC, I got things going slightly further. Specifically:
- fixed xinitrc to do `exec startxfce4`
- this enabled me to use startx

When using startx, which eventually execs startxfce4, keeps the
existing session active \o/

I've now also noticed that my X is compiled without systemd daemon
support. I'll look into fixing that.

-- 
Regards,

Dimitri.
97 sleeps till Christmas

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] startxfce4 vs logind

[Dimitri John Ledkov]

Heya,

I boot to tty1, and login as my normal user account.

Session c1, is active and has type tty. And I can access devices which
are marked as uaccess.

Then I do $ startxfce4 -> which starts graphical interface. However,
at that time I "loose" the logind session. No new sessions are
started, session c1 is "Active=no" & "State=online" and i cannot
access uaccess devices any more.

Both startxfce4 and systemd are compiled without policykit support (no
idea if this matters).

What I am doing wrong? Should I go talk to xfce4 people?

My expectation was for a new session c2 to be started and switched to,
type graphical, online and active. Whilst keeping c1 tty session
online and in-active.

Is there something startxfce4 missing to act like a "mini-display-manager"?
and/or how should it be telling logind that session became graphical
and/or for c1 session to remain active?

-- 
Regards,

Dimitri.
97 sleeps till Christmas

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What I think is really wrong with systemd

[Dimitri John Ledkov]

On 16 September 2015 at 16:52, Kok, Auke-jan H  wrote:
> On Wed, Sep 16, 2015 at 8:38 AM, Reindl Harald  wrote:
>> Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish:
>>>
>>> Not to mention that the same rolling-release model was adopted by
>>> the kernel long time ago for similar reasons and much more ;-)
>>
>> that is *not* true and won't become true by repeat it
>>
>> https://www.kernel.org/
>>
>> mainline:   4.2 2015-08-30
>> stable: 4.1.7   2015-09-13
>> longterm:   3.18.21 2015-08-31
>>
>> only systemd upstream has from the core component a "that is the new version
>> with no major/minor" attitude and the kernel is the very last project to
>> compare given "longterm: 2.6.32.67 2015-06-03"
>
> nonsense. Only one of those three mentioned is actually "the linux
> kernel". The other two are independently running forks that "the linux
> kernel" maintainer does not maintain.
>
> So, he's actually entirely correct to paraphrase that the linux kernel
> community is using a rolling release model. The fact that individuals
> make "respins" that follow a non-rolling release model does not
> diminish the truth of that in any way possible.
>

To further resonate that. Just like with kernel, every vendor make
their own longterm maintenance thing of systemd.
Look at Centos vs Debian kernel, they are widely different, even if
released from same series or at the same time.
Ditto systemd, integration done in Debian, Ubuntu, openSUSE, Fedora
are all different as well.

To me this all looks like comparing kettle and pots. With calling
systemd black in comparison to the kernel.

-- 
Regards,

Dimitri.
100 sleeps till Christmas

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] optional kdbus enablement

[Dimitri John Ledkov]

oh, it is. Excellent. Not sure how I missed that last time I was
testing, never mind me.

On 10 September 2015 at 16:53, Dimitri John Ledkov
<dimitri.j.led...@intel.com> wrote:
> Shouldn't the dbus1-generator disable the dbus.service & dbus.socket
> by symlinking them to /dev/null ?
>
> Or for example, should the dbus.server|socket units to have condition
> whether or not kdbus is available at runtime?
>
> Or how does one resolve the conflict between the bus-proxy and dbus?
>
> --
> Regards,
>
> Dimitri.
> Pura Vida!
>
> https://clearlinux.org
> Open Source Technology Center
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bootctl: default mount point for the ESP partition.

[Dimitri John Ledkov]

On 1 September 2015 at 17:47, Simon McVittie
 wrote:
> On 01/09/15 17:21, Goffredo Baroncelli wrote:
>> I discovered that bootctl assume as default mount point for the ESP
>> partition the /boot directory. Instead it seems to me that the most part
>> of distributions prefers /boot/efi.
>
> For some context, the reasoning for /boot/efi is:
>
> In principle, it should be possible for the ESP to never be mounted at
> all, copying files in with mtools (or equivalent) when required.
>

In clearlinux we mount ESP at /boot.

However, we disabled the /boot automount, but keep the boot.mount
auto-generated unit.

The reason being, we really don't need /boot in userspace at all,
unless updater is running or one manually wants to mock with things.

What updater does is essentially `systemctl start boot.mount` updates
the kernel images/entries there using files from /usr (sdboot
bootloader, kernel images, initramfs, etc.) And then unmounts /boot.
If one has custom kernels to install one would do the same.

The distinction between "traditional" /boot and /boot/efi is imho
pointless, if one keeps kernel images to be booted on the ESP.

In clearlinux kernel images are EFI apps, packaged with stubs (either
using kernel config, or by means of packing .efi megablob which sdboot
supports to boot everything from).

Doing "traditional" flow of: Firmware -> ESP -> [ grub bootloader ->
find/mount "/boot" ] -> load kernel/initrmafs -> "mount/boot rootfs"
seems more than minimally necessary, when the steps in [] can be
skipped from the bootflow.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for experiences formalizing an API for journal messages

[Dimitri John Ledkov]

On 29 July 2015 at 20:02, Anne Mulhern amulh...@redhat.com wrote:




 - Original Message -
 From: Lennart Poettering lenn...@poettering.net
 To: Anne Mulhern amulh...@redhat.com
 Cc: systemd-devel@lists.freedesktop.org
 Sent: Thursday, July 23, 2015 9:21:44 AM
 Subject: Re: [systemd-devel] Looking for experiences formalizing an API for 
 journal messages

 On Thu, 23.07.15 09:17, Anne Mulhern (amulh...@redhat.com) wrote:

  Hi!
 
  We all know that using the journald native API it is possible to enrich the
  log
  entry data w/ key/value pairs, although this facility is Linux only.
  The set of key/value pairs which a message may log to the journal can
  constitute an API with which a logging entity can communicate alerts to
  consumers
  of this information. Clearly this requires an agreement on an API between
  the logging
  entity and the consumer of the journal entries.
 
  Are there existing projects that have used this facility in a principled,
  coordinated way with some success or have there been any interesting
  failures
  along those same lines?

 systemd of courses uses its on its own, and we tried to document
 the fields we use in systemd.journal-fields(7), though it might be
 slightly incomplete.

 But yes, this is indeed API, and deserves complete documentation, like
 any C API, any D-Bus API or a any REST API would need too.

 Lennart

 --
 Lennart Poettering, Red Hat


 What I'm wondering about is the existence of some processes (not systemd), 
 that have an
 agreement on a set of key-value pairs that they communicate with through the 
 journal.

 It seems like, even though there is a mechanism for adding additional 
 key/value pairs,
 regular expression matching is still kind of the norm.

 I was hoping for an inspiring counter example that uses mostly or exclusively 
 key/value
 pairs instead of expression matching, and maybe some hints as to best 
 practices.

I've heard of https://github.com/rsyslog/liblogging/tree/master/stdlog
but didn't look to deep into it. It supposed to do generic structured
logging for multiple destinations, one of them being journal. Maybe
it's of any help. I don't think that project is stable, nor widely
used at the moment.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] socket activated services and correct dependency mapping

[Dimitri John Ledkov]

On 24 July 2015 at 10:38, James Hogarth james.hoga...@gmail.com wrote:
 I want a user to be able to systemctl start sslh and use listening
 addresses in /etc/sslh.cfg as always (so I'm reluctant to put a
 straight Sockets= in the service unit file) but as it stands the lazy

You can write a generator which will parse /etc/sshlh.cfg and drop e.g.
$1/sslh.socket.d/sshlh-cfg.conf

with contents
[Socket]
ListenStream=...

That way e.g. you can enforce that config file is still fully honoured
as canonical place to set ports.

Checkout generators at
http://www.freedesktop.org/wiki/Software/systemd/Generators/

Or e.g. look at /run/systemd for things that got generated by various
stuff (e.g. like the fstab generator).

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to properly write an umbrella unit

[Dimitri John Ledkov]

Heya,

On 21 July 2015 at 12:43, Marc Haber mh+systemd-de...@zugschlus.de wrote:

 Hi,

 I am trying to systemd'ize a daemon which is useful to be run in two
 instances. It is usually the case that both instances need to be
 started and stopped simultaneously, and the local admin would want a
 _single_ command to start and stop both instances. Therefore, an
 umbrella is needed.

 As a beginner, I have written:


Imho targets are ugly =)

I'd do a nifty@.service
with:
ExecStart= -%I -cf /etc/nifty/niftyd%I.conf

And then people can do e.g.:
systemctl enable nifty@4.service nifty@6.service
systemctl start nifty@*.service
systemctl stop nifty@*.service

And the install section would have e.g. default instance name 4, and
wanted by multi-user target.

And such service should be trivial to integrate into any maintainer scripts.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-tmpfiles for the user instance of systemd

[Dimitri John Ledkov]

Heya,


On 1 July 2015 at 11:35, Daniel Tihelka dtihe...@gmail.com wrote:

 Hello,
 does anyone have an experience with the use of systemd-tmpfiles for the user
 instance of systemd.


My question would be - what sort of files are you creating with tmpfiles?

system stuff is known to use dynamic directories in /var /run and
similar and it all used to be created ad-hoc in either packaging or
the init scripts.

User stuff on the other hand, generally works with untouched home
directories as they typically are not allowed to be modified by
typical packaging systems. Hence most of the user things handle
creation of the dirs they need themself and do it gracefully enough.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] no tar balls at release time

[Dimitri John Ledkov]

On 23 June 2015 at 00:21, Kay Sievers k...@vrfy.org wrote:

 We currently considering to stop creating release tar balls.

 For build systems which still require them, they can be created
 locally from the upstream git repository with:
   git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \
 xz  systemd-$(VERSION).tar.xz


Or simply download the github generated tarball from tag, which is
called releases

Fine by me. We ended up patching configury for us, hence have to
autoreconf the lot anyway.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd bridge masquerading

[Dimitri John Ledkov]

I'm trying to setup networking for containers/vms similar to e.g. docker0
bridge, or lxcbr0. But purely with networkd. That is a bridge that is NATed
to provide internet access, and then attaching tap/veth devices to the
bridge.

I did this at first:

br0.netdev:
[NetDev]
Name=br0
Kind=bridge

br0.network:
[Match]
Name=br0

[Network]
Address=0.0.0.0/28
IPMasquerade=yes

Without adding any veth / tap interfaces to the bridge. My expectation is
for such a bridge to come up correctly. However in journalctl I get:

br0  : Could not enable IP masquerading: Operation not supported
br0  : Could not enable IP masquerading: Operation not supported
br0  : link configured

What's wrong, or I am doing something crazy?

Secondly, is there an API to manipulate networkd? Ideally i would like to
add/remove tap interfaces that would be part of this bridge. The only way I
found to do this is by e.g. dropping files to /run/systemd/network and
restarting networkd service. That works fine, however this results in the
bridge accumulating ip addresses, which is not nice.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] Add support for transient presets, applied on every boot.

[Dimitri John Ledkov]

On 22 April 2015 at 19:30, Lennart Poettering lenn...@poettering.net wrote:
 On Sat, 21.02.15 02:38, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 Sorry for the late review!


Hello, blast from the past =)

 Can you please add a commit description to this, explaining the
 precise rationale for this?


Right, will work on that. But let me comment on below to close up
discussion here, before moving next edition of the patchset into
github.


 ---
  src/core/main.c  | 27 +++
  src/core/unit.c  |  2 +-
  src/shared/install.c | 25 -
  src/shared/install.h |  2 +-
  4 files changed, 49 insertions(+), 7 deletions(-)

 diff --git a/src/core/main.c b/src/core/main.c
 index 08f46f5..2656779 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1207,6 +1207,23 @@ static int write_container_id(void) {
  return write_string_file(/run/systemd/container, c);
  }

 +static int transient_presets(void) {
 +struct stat st;
 +
 +if (lstat(/usr/lib/systemd/system-preset-transient, st) == 0)
 +return !!S_ISDIR(st.st_mode);

 Please use is_dir() for this, it's slightly nicer to read.


ok.

 +#ifdef HAVE_SPLIT_USR
 +if (lstat(/lib/systemd/system-preset-transient, st) == 0)
 +return !!S_ISDIR(st.st_mode);
 +#endif
 +
 +if (lstat(/etc/systemd/system-preset-transient, st) == 0)
 +return !!S_ISDIR(st.st_mode);
 +
 +return 0;
 +}

 Also, the function should probably return a proper bool instead of
 an int. We use C99 bool heavily.

 That said, maybe we shouldn't have this function at all, see below.


Well, I think we need this. Either here, or in unit_file_preset_all.

 +
  int main(int argc, char *argv[]) {
  Manager *m = NULL;
  int r, retval = EXIT_FAILURE;
 @@ -1619,6 +1636,16 @@ int main(int argc, char *argv[]) {
  if (arg_running_as == SYSTEMD_SYSTEM) {
  bump_rlimit_nofile(saved_rlimit_nofile);

 +// NB! transient presets must be applied before
 normal

 We try to stick to /* comments */ instead of // comments


Ok. I grew up with // comments =)

 +if (transient_presets()) {
 +r = unit_file_preset_all(UNIT_FILE_SYSTEM, true, 
 NULL, UNIT_FILE_PRESET_ENABLE_ONLY, false, NULL, 0);
 +if (r  0)
 +log_warning_errno(r, Failed to populate 
 transient preset unit settings, ignoring: %m);
 +else
 +log_info(Populated transient preset unit 
 settings.);
 +}

 Hmm, do we actually need the explicit check with transient_presets()
 at all? I mean, it replicates the search path logic, and
 unit_file_preset_all() should notice on its own that there are no
 preset files in those dirs...


Well. it does notice there are no presets, and hence defaults to
enabling all units. At the moment the chain of calls is like so:

main.c decides to call unit_file_preset_all at an appropriate time:

1) list of all unit paths is constructed, and iterated
2) for each valid unit in a unit path presets are queried
3) a list of preset paths is constructed
4) for each valid preset file, it is iterated to check if it has
anything about the unit in question
5) ... and if nothing found in preset files default to enable.

Thus the currently logic does a lot of iterations and without any
.preset files or folders, defaults to enable *.

Now, remember we discussed ways to optimise the preset application
logic. (parse and cache the policy first, and then for each unit do
lookups in the parsed policy). Reopening that discussion, would the
behaviour be acceptable to change slitghly:

1) if there are no .preset policy files defined at all. Bail out,
nothing is enabled.
2) if there are /usr/lib/systemd/preset/*.preset. Parse and create
policy cache, with the fall-through to enable * as before.
3) do similar for the transient-presets.

In general one would not use both types. And imho, it would be useful
to skip enable * if no policies exist at all. Mostly, because
without any policies installed (even the default one that systemd
ships) it is harmful to enable *. E.g. clearlinux, debian, ubuntu do
not use persistent presets and end up plugging the preset application
on first boot with hacks (e.g. making sure machine-id is always
available pre-first boot, shipping disable * persistent policy, or
in clearlinux case even patching out persistent policy application
since it takes time to iterate pointlessly all preset dirs, for each
unit file).

The changes above would optimise policy application, and would be no
change to behaviour of existing users, who have at least one .preset
file on disk.

(if .preset file presence not enough, could do journald style
presence check of any /preset/ folders instead).



 diff --git a/src/shared/install.c b/src/shared/install.c
 index 65f1c24

Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?

[Dimitri John Ledkov]

On 3 June 2015 at 06:40, Daurnimator q...@daurnimator.com wrote:

 I was playing around with nss, and found that my loopback interface ip
 doesn't appear from nss-myhostname.
 Rather, my other ones do.
 Furthermore, unless I request IPv4, link-local IPv6 addresses are
 returned. Is this expected?


So in my case, I don't have /etc/hosts file at all and use
nss-myhostname et.al. modules. Specifically I have nsswitch.conf like
so:
hosts:  files myhostname resolve dns mymachines

My naive expection for the following call:
# getent hosts `hostname`

To return something like, e.g.:
127.0.1.1   $hostname $hostname.$domain

But instead I get:
fe80::5054:ff:fe12:3456 $hostname

Whist it is perfectly valid, it's atypical from usual setups
elsewhere. And subtle things seem to rely on the usual setup, e.g.
Erlang Port Mapper Daemon / zerromq fail to start, as hostname -
127.0.*.* - localhost mappings are kind of expected. (there were
other things as well, that were fixed up by other people)

Sure, I could fix the world to connect/resolve localhost, instead of
`hostname`, but for the time being this situation became defacto
expected =( I would like to see an option to myhostname module to
return 127.0.1.1 when asking for current machine `hostname`.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] FR: different gcrypt options for joornald and importd

[Dimitri John Ledkov]

On 8 June 2015 at 16:12, Lennart Poettering lenn...@poettering.net wrote:

 On Mon, 08.06.15 16:12, Alexey Shabalin (a.shaba...@gmail.com) wrote:

  Hi!
  I want build journald without gcrypt support. But --disable-gcrypt disabled
  build importd.
  Can you add diiferent options for journald and importd?

 You can build systemd twice to do this. On Fedora we build it twice
 for example to get python2 as well as python3 modules.

 But: what's the reason for this? THis sounds like a weird choice?

For clearlinux we want this as well. We want to build and have fully
functional/standalone importd.
But we don't want/need ssl/remote support in journal.
And we don't want to do a separate configure  build to e.g. build
the right importd or the right journal discarding the rest of the
second build.

Ditto e.g. xz support. It's needed for importd, but we don't want it
in journal for performance reasons.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Dimitri John Ledkov]

On 1 June 2015 at 19:12, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 As of today we've disabled git-push to fd.o. The official development
 git repository is now at github [1]. The old repository will still be
 back-synced, but we had to disable push-access to avoid getting
 out-of-sync with github.

 [1] https://github.com/systemd-devs/systemd

And where will be the stable repository / branches?

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Dimitri John Ledkov]

On 2 June 2015 at 12:34, Jóhann B. Guðmundsson johan...@gmail.com wrote:


 On 06/02/2015 11:06 AM, David Herrmann wrote:

 Regarding the final github address: David Strauss kindly offered the
 'systemd' user to us. Hence, we hope to move the repository to
 github.com/systemd/systemd this week. Sorry for the confusion, I hope
 we can settle all this this week.


 Given that you are moving into the direction that I had anticipated we
 needed to do ( pull-requests ) but was hesitated to ask about ( when I have
 been working on my infrastructure proposal for the systemd community ) since
 I though it would not fly by since it limits somewhats Lennart's drive by
 patches concept, I have to ask is moving this to a 3rd party hosting site
 the best thing to do?


yes. There are more drive-by people on github, than there are those
that know where freedesktop.org cgit is, where systemd wiki is, where
systemd mailing list is, and how to setup MTA to not mangle patches,
and send them through. And even if there are drive-by people who shoot
an email to the mailing list, we have enough reviewers / comiters who
will be able to apply that.

 In my proposal which touches quite few other things ( including replacing
 both bugzilla and freedesktop wiki ) which is necessary to make things work
 smoothly for future growth/expansion in the community and systemd adoption,
 is it not better we would host this ourselves under our own domain ( I have
 already secured systemd.community domain for that purpose ) on our own
 instances?


maintaining /own/ infrastructure does not improve systemd code base.

 Do people prefer these things being hosted at sites which one does not have
 full control over?

adequate infrastructure is sufficient here. there is no paranoia about
hypothetical full control, or lack of it. if everything fails, most of
us have systemd git clones to move things elsewhere again. Or when we
find something better to use.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Dimitri John Ledkov]

On 2 June 2015 at 15:34, Martin Pitt martin.p...@ubuntu.com wrote:
 David Herrmann [2015-06-02 13:06 +0200]:
 Our preferred way to send future patches is the github way. This
 means sending pull-requests to the github repo. Furthermore, all
 feature patches should go through pull-requests and should get
 reviewed pre-commit. This applies to everyone. Exceptions are
 non-controversial patches like typos and obvious bug-fixes.

 Makes sense. On the operational level, should we use the
 automatically merge feature of git hub once approving? On the plus
 side it's very convenient, but you'll get one Merge commit for every
 PR (which is often just one commit), so we'd almost double the entries
 in git log. Or can github be told to not do that?

 Merging manually is quite a bit of work, as you have to add a new
 remote every time, fetch that, and pull from it. But it does keep a
 cleaner git log history.

One doesn't need to add a named remote

If you have write access, at the bottom of the pull request there is a
link to command line instructions, excluding make sure you are on the
right target branch and you know where to push it boils down to:

git pull https://github.com/somebody/systemd.git branch-name-that-was-proposed

one step.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Dimitri John Ledkov]

On 2 June 2015 at 15:56, Daniel P. Berrange berra...@redhat.com wrote:
 On Tue, Jun 02, 2015 at 04:34:03PM +0200, Martin Pitt wrote:
 David Herrmann [2015-06-02 13:06 +0200]:
  Our preferred way to send future patches is the github way. This
  means sending pull-requests to the github repo. Furthermore, all
  feature patches should go through pull-requests and should get
  reviewed pre-commit. This applies to everyone. Exceptions are
  non-controversial patches like typos and obvious bug-fixes.

 Makes sense. On the operational level, should we use the
 automatically merge feature of git hub once approving? On the plus
 side it's very convenient, but you'll get one Merge commit for every
 PR (which is often just one commit), so we'd almost double the entries
 in git log. Or can github be told to not do that?

 Merging manually is quite a bit of work, as you have to add a new
 remote every time, fetch that, and pull from it. But it does keep a
 cleaner git log history.

 FWIW,  'git log --no-merges' displays the clean history when
 merges are present.

I also like --first-parent a lot, that squishes the pull request
into the single commit in the log / graph (aka bzr style default log
output).

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Dimitri John Ledkov]

On 2 June 2015 at 15:49, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote:
 On Tue, Jun 02, 2015 at 04:34:03PM +0200, Martin Pitt wrote:
 David Herrmann [2015-06-02 13:06 +0200]:
  Our preferred way to send future patches is the github way. This
  means sending pull-requests to the github repo. Furthermore, all
  feature patches should go through pull-requests and should get
  reviewed pre-commit. This applies to everyone. Exceptions are
  non-controversial patches like typos and obvious bug-fixes.

 Makes sense. On the operational level, should we use the
 automatically merge feature of git hub once approving? On the plus
 side it's very convenient, but you'll get one Merge commit for every
 PR (which is often just one commit), so we'd almost double the entries
 in git log. Or can github be told to not do that?

 Merging manually is quite a bit of work, as you have to add a new
 remote every time, fetch that, and pull from it. But it does keep a
 cleaner git log history.
 I'd very much prefer to keep current look of the git tree, without
 gratuitous merge commits. For bigger changes, which are composed of
 a larger number of commits, merges are fine. But most patchsets to systmed
 are either a single commit or two or three.

I disagree. Largely single patches apply fine, but because they are
merged using $ git am, they are not actually merged, but rebased on
to tip.

With actually pulling the pull requests, and merging properly, we will
get a merge commit most of the time for most submissions, since the
tree moves that quickly.

And I think this is _good_, because the submitter's commit ids will be
preserved (together with the signed gpg commits) and the maintainers
are discouraged to fix-up and/or adjust commits upon rebase /
git-am. Instead fix-ups from reviewer should go as separate commits or
as part of the merge commit.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] shared: Drop 'name=' prefix from SYSTEMD_CGROUP_CONTROLLER define.

[Dimitri John Ledkov]

In cgtop,mount-setup,nspawn the name= prefix is hard-coded in the
mount options, and the define is not used.

Everywhere else, we explicitly white-list allow 'name=' prefix to be
used with all controllers, and strip it out to 'normalise' the
controller name. That work is mostly inflicted on us due to 'name='
prefix in the define. Dropping this prefix makes everything more sane
overall.
---
 src/shared/cgroup-util.c| 24 ++--
 src/shared/cgroup-util.h|  2 +-
 src/shared/def.h|  2 +-
 src/test/test-cgroup-util.c | 20 ++--
 4 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 9988e5c..d83cdf7 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -441,9 +441,7 @@ static const char *normalize_controller(const char 
*controller) {
 
 assert(controller);
 
-if (streq(controller, SYSTEMD_CGROUP_CONTROLLER))
-return systemd;
-else if (startswith(controller, name=))
+if (startswith(controller, name=))
 return controller + 5;
 else
 return controller;
@@ -483,7 +481,7 @@ int cg_get_path(const char *controller, const char *path, 
const char *suffix, ch
 
 assert(fs);
 
-if (controller  !cg_controller_is_valid(controller, true))
+if (controller  !cg_controller_is_valid(controller))
 return -EINVAL;
 
 if (_unlikely_(!good)) {
@@ -526,7 +524,7 @@ int cg_get_path_and_check(const char *controller, const 
char *path, const char *
 
 assert(fs);
 
-if (!cg_controller_is_valid(controller, true))
+if (!cg_controller_is_valid(controller))
 return -EINVAL;
 
 /* Normalize the controller syntax */
@@ -742,7 +740,7 @@ int cg_pid_get_path(const char *controller, pid_t pid, char 
**path) {
 assert(pid = 0);
 
 if (controller) {
-if (!cg_controller_is_valid(controller, true))
+if (!cg_controller_is_valid(controller))
 return -EINVAL;
 
 controller = normalize_controller(controller);
@@ -971,7 +969,7 @@ int cg_split_spec(const char *spec, char **controller, char 
**path) {
 
 e = strchr(spec, ':');
 if (!e) {
-if (!cg_controller_is_valid(spec, true))
+if (!cg_controller_is_valid(spec))
 return -EINVAL;
 
 if (controller) {
@@ -994,7 +992,7 @@ int cg_split_spec(const char *spec, char **controller, char 
**path) {
 t = strdup(normalize_controller(v));
 if (!t)
 return -ENOMEM;
-if (!cg_controller_is_valid(t, true)) {
+if (!cg_controller_is_valid(t)) {
 free(t);
 return -EINVAL;
 }
@@ -1610,17 +1608,15 @@ char *cg_unescape(const char *p) {
 DIGITS LETTERS  \
 _
 
-bool cg_controller_is_valid(const char *p, bool allow_named) {
+bool cg_controller_is_valid(const char *p) {
 const char *t, *s;
 
 if (!p)
 return false;
 
-if (allow_named) {
-s = startswith(p, name=);
-if (s)
-p = s;
-}
+s = startswith(p, name=);
+if (s)
+p = s;
 
 if (*p == 0 || *p == '_')
 return false;
diff --git a/src/shared/cgroup-util.h b/src/shared/cgroup-util.h
index cbf7201..fd72e9e 100644
--- a/src/shared/cgroup-util.h
+++ b/src/shared/cgroup-util.h
@@ -122,7 +122,7 @@ int cg_path_decode_unit(const char *cgroup, char **unit);
 char *cg_escape(const char *p);
 char *cg_unescape(const char *p) _pure_;
 
-bool cg_controller_is_valid(const char *p, bool allow_named);
+bool cg_controller_is_valid(const char *p);
 
 int cg_slice_to_path(const char *unit, char **ret);
 
diff --git a/src/shared/def.h b/src/shared/def.h
index a3d9fcf..011c7c6 100644
--- a/src/shared/def.h
+++ b/src/shared/def.h
@@ -35,7 +35,7 @@
  * the watchdog pings will keep the loop busy. */
 #define DEFAULT_EXIT_USEC (30*USEC_PER_SEC)
 
-#define SYSTEMD_CGROUP_CONTROLLER name=systemd
+#define SYSTEMD_CGROUP_CONTROLLER systemd
 
 #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 #define SIGNALS_IGNORE SIGPIPE
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..ecc9d70 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -244,16 +244,16 @@ static void test_escape(void) {
 }
 
 static void test_controller_is_valid(void) {
-assert_se(cg_controller_is_valid(foobar, false));
-assert_se(cg_controller_is_valid(foo_bar, false));
-assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
-assert_se(!cg_controller_is_valid(name=, true));
-

Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

On 1 June 2015 at 09:03, Umut Tezduyar Lindskog u...@tezduyar.com wrote:
 On Fri, May 29, 2015 at 12:25 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote:
  On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
  wrote:
 
  It appears in /proc/self/cgroup as `0::/'
 
  What precisely does this fix?
 
  I mean, we need to do some major rework of things before the unified
  hierarchy is really supported in systemd, and this one thing won't
  really get us too much in this regard, does it?
 

 I'm starting to explore possibilities to start work towards supporting
 unified cgroups hierarchy, or at least be able to boot with it. I'll
 send a larger patch series in one go later than with all the bits that
 offer something more tangible, albeit disabled by default behind
 configure options (like kdbus) given that unified hierarchy is still
 marked experimental in the kernel.

 Ah, it's actually my big thing to work on for the next weeks too...

 What is the advantage of having a unified hierarchy, could you guys explain?

There are a few. Read more in the linux documentation:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/cgroups/unified-hierarchy.txt

For me, I'm spending a lot of time during boot forking cgroups release
agent user-space binary, which establishes IPC connection to systemd
to notify that a cgroup was released. And essentially oneshot services
during boot pay sequential price of executing two processes rather
than just one. Hence exposure of cgroups.populated field is very
desirable for me. Currently only available on the unified hierarchy,
but I'm not sure why it couldn't be enabled on the old one, given that
it is forward compatible.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl as non-root

[Dimitri John Ledkov]

On 29 May 2015 at 01:21,  aaron_wri...@selinc.com wrote:
 Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM:
 Access to the system dbus is controlled by dbus policies. You will
 need to write a policy for giving this user access to the systemd1 object.


 I compiled systemd without dbus support (--disable-dbus), and there is no
 dbus daemon or dbus lib on the system. Is that a requirement to get the
 functionality I want? I didn't see much need for dbus as the system works
 quite well without it. Well, except for this of course.


the term dbus is used loosely and it's a few distinct things. On the
most basic level, it's used as a marshalling/demarshling format of
messages passed to/from systemd, on the protocol level this is exposed
via private socket or systemd may join the system bus which is
operated by something, e.g. kdbus or the dbus1 daemon. When there is a
dbus daemon available policy can be checked and enforced and e.g.
unprivilledged users can be granted to execute certain actions on per
dbus api level. Further more policykit can be used in conjunction with
that to seamlessly ask to elevate / allow more privileged api calls.
However just on the private systemd socket these complex measures are
not available and one really needs to be root...

... if not done carefully, it is easy to introduce vulnerabilities
into the system e.g. if one allows unprivileged things start/stop
privileged jobs.


 On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote:
 I'm working on an embedded system, and I ran into a situation where
 a non-root user needs to runs systemctl, but when I try I get:
 ~ $ systemctl status
 Failed to get D-Bus connection: No such file or directory

 So, I try with the suid bit on systemctl set, but then I get:

 ~ $ systemctl status
 Failed to read server status: Operation not permitted

 My question is, is something broken, or is this expected behavior?

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




-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

On 29 May 2015 at 11:25, Lennart Poettering lenn...@poettering.net wrote:
 On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote:
  On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
  wrote:
 
  It appears in /proc/self/cgroup as `0::/'
 
  What precisely does this fix?
 
  I mean, we need to do some major rework of things before the unified
  hierarchy is really supported in systemd, and this one thing won't
  really get us too much in this regard, does it?
 

 I'm starting to explore possibilities to start work towards supporting
 unified cgroups hierarchy, or at least be able to boot with it. I'll
 send a larger patch series in one go later than with all the bits that
 offer something more tangible, albeit disabled by default behind
 configure options (like kdbus) given that unified hierarchy is still
 marked experimental in the kernel.

 Ah, it's actually my big thing to work on for the next weeks too...

My current priority is to port at least enough bits to get usable
/sys/fs/cgroup/systemd on top of unified cgroups, with immediate
benefit of dropping systemd-cgroups-agent and getting release
notifications in containers.

Not sure about transition / re-exec plan, at the moment I am assuming
either/or situation but I guess we'd need to support a dual case,
where upon re-exec we might still be in name=systemd rather than in
the unified structure.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

On 29 May 2015 at 14:41, Lennart Poettering lenn...@poettering.net wrote:
 On Fri, 29.05.15 12:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 On 29 May 2015 at 11:25, Lennart Poettering lenn...@poettering.net wrote:
  On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
  wrote:
 
  On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net 
  wrote:
   On Thu, 28.05.15 16:42, Dimitri John Ledkov 
   (dimitri.j.led...@intel.com) wrote:
  
   It appears in /proc/self/cgroup as `0::/'
  
   What precisely does this fix?
  
   I mean, we need to do some major rework of things before the unified
   hierarchy is really supported in systemd, and this one thing won't
   really get us too much in this regard, does it?
  
 
  I'm starting to explore possibilities to start work towards supporting
  unified cgroups hierarchy, or at least be able to boot with it. I'll
  send a larger patch series in one go later than with all the bits that
  offer something more tangible, albeit disabled by default behind
  configure options (like kdbus) given that unified hierarchy is still
  marked experimental in the kernel.
 
  Ah, it's actually my big thing to work on for the next weeks too...

 My current priority is to port at least enough bits to get usable
 /sys/fs/cgroup/systemd on top of unified cgroups, with immediate
 benefit of dropping systemd-cgroups-agent and getting release
 notifications in containers.

 Not sure about transition / re-exec plan, at the moment I am assuming
 either/or situation but I guess we'd need to support a dual case,
 where upon re-exec we might still be in name=systemd rather than in
 the unified structure.

 My intention is to make this all work so that we can support both
 modes for a while, but you have to pick at boot-time which mode you
 want: the unified hierarchy or the classic one. And if we pick the
 former you won't get the latter, and if you pick the latter you won't
 get the former.

 And yeah, getting proper notifications especially for the container
 case is the most important thing for me too.

Right. I have it as compile option at the moment, and i'm booting
fresh VMs with it. I do something rather crazy at the moment - mount
/sys/fs/cgroup/systemd as unified hiearchy whilst keeping the old
controller mounts where they are. Will add the bits for the inotify
watches and then publish an RFC patch set. This way systemd gains the
notification benefit straight away, whilst keeping the rest as it was
essentially. I take it the unitfied structure is expected to be
mounted in /sys/fs/cgroup/ direct, once stable.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device

[Dimitri John Ledkov]

On 29 May 2015 at 11:17,  har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com

 If cryptsetup is called with a source device as argv[3], then craft the
 ID for the password agent with a unique device path.


I'm not sure why this is needed... if the device path is not good
enough, there is also luks UUID header. In Ubuntu we display the full
cryptsetup UUID in plymouth, but that's fairly cosmetic.
If the path is not good enough, maj/min are a bit pointless and you
really probably want the luks UUID then.

Regards,

Dimitri.

 If possible /dev/block/maj:min is used, otherwise the original
 argv[3] is used.

 This enables password agents like petera [1] to provide a password
 according to the source device. The original ID did not carry enough
 information and was more targeted for a human readable string, which
 is specified in the Message field anyway.

 With this patch the ID of the ask.XXX ini file looks like this:
 ID=cryptsetup:/dev/block/maj:min

 [1] https://github.com/npmccallum/petera
 ---
  src/cryptsetup/cryptsetup.c | 97 
 ++---
  1 file changed, 66 insertions(+), 31 deletions(-)

 diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
 index a5018f1..130c36e 100644
 --- a/src/cryptsetup/cryptsetup.c
 +++ b/src/cryptsetup/cryptsetup.c
 @@ -238,6 +238,33 @@ static void log_glue(int level, const char *msg, void 
 *usrptr) {
  log_debug(%s, msg);
  }

 +static char* disk_maj_min(const char *path) {
 +struct stat st, st2;
 +char *i = NULL;
 +int r;
 +
 +assert(path);
 +
 +if (stat(path, st)  0)
 +return NULL;
 +
 +if (!S_ISBLK(st.st_mode))
 +return NULL;
 +
 +asprintf(i, /dev/block/%d:%d, major(st.st_rdev), 
 minor(st.st_rdev));
 +
 +if (!i)
 +return strdup(path);
 +
 +r = stat(i, st2);
 +if ((r  0) || (st.st_rdev != st2.st_rdev)) {
 +free(i);
 +return strdup(path);
 +}
 +
 +return i;
 +}
 +
  static char* disk_description(const char *path) {

  static const char name_fields[] =
 @@ -295,20 +322,54 @@ static char *disk_mount_point(const char *label) {
  return NULL;
  }

 -static int get_password(const char *name, usec_t until, bool accept_cached, 
 char ***passwords) {
 -int r;
 +static int get_password(const char *vol, const char *src, usec_t until, bool 
 accept_cached, char ***passwords) {
 +int r = 0;
  char **p;
  _cleanup_free_ char *text = NULL;
  _cleanup_free_ char *escaped_name = NULL;
  char *id;
 +const char *name = NULL;
 +_cleanup_free_ char *description = NULL, *name_buffer = NULL,
 +*mount_point = NULL, *maj_min = NULL;

  assert(name);
  assert(passwords);

 +description = disk_description(src);
 +mount_point = disk_mount_point(vol);
 +
 +if (description  streq(vol, description)) {
 +/* If the description string is simply the
 + * volume name, then let's not show this
 + * twice */
 +free(description);
 +description = NULL;
 +}
 +
 +if (mount_point  description)
 +r = asprintf(name_buffer, %s (%s) on %s, description, 
 vol, mount_point);
 +else if (mount_point)
 +r = asprintf(name_buffer, %s on %s, vol, mount_point);
 +else if (description)
 +r = asprintf(name_buffer, %s (%s), description, vol);
 +
 +if (r  0) {
 +log_oom();
 +return r;
 +}
 +name = name_buffer ? name_buffer : vol;
 +
  if (asprintf(text, Please enter passphrase for disk %s!, name)  
 0)
  return log_oom();

 -escaped_name = cescape(name);
 +if (src)
 +maj_min = disk_maj_min(src);
 +
 +if (maj_min)
 +escaped_name = maj_min;
 +else
 +escaped_name = cescape(name);
 +
  if (!escaped_name)
  return log_oom();

 @@ -552,8 +613,7 @@ int main(int argc, char *argv[]) {
  unsigned tries;
  usec_t until;
  crypt_status_info status;
 -const char *key_file = NULL, *name = NULL;
 -_cleanup_free_ char *description = NULL, *name_buffer = 
 NULL, *mount_point = NULL;
 +const char *key_file;

  /* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE 
 [PASSWORD] [OPTIONS] */

 @@ -581,31 +641,6 @@ int main(int argc, char *argv[]) {
  /* A delicious drop of snake oil */
  mlockall(MCL_FUTURE);

 -description = disk_description(argv[3]);
 -mount_point = disk_mount_point(argv[2]);
 -
 -if (description  streq(argv[2], 

[systemd-devel] [PATCH v2 5/5] core/cgroup: Add cgroup.populated inotify watches, when available.

[Dimitri John Ledkov]

---
 src/core/cgroup.c| 81 ++--
 src/core/manager.c   |  7 -
 src/core/manager.h   |  3 ++
 src/core/service.c   |  2 +-
 src/shared/cgroup-util.c | 28 +
 src/shared/cgroup-util.h |  6 ++--
 src/test/test-cgroup.c   | 12 +++
 7 files changed, 120 insertions(+), 19 deletions(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6474e08..a1d7d93 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -30,6 +30,8 @@
 
 #define CGROUP_CPU_QUOTA_PERIOD_USEC ((usec_t) 100 * USEC_PER_MSEC)
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata);
+
 void cgroup_context_init(CGroupContext *c) {
 assert(c);
 
@@ -629,6 +631,7 @@ static const char *migrate_callback(CGroupControllerMask 
mask, void *userdata) {
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 CGroupContext *c;
 int r;
+int wd = -1;
 
 assert(u);
 
@@ -655,10 +658,13 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 }
 
 /* First, create our own group */
-r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path);
+r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path, u-manager-cgroup_populated_inotify_fd, wd);
 if (r  0)
 return log_error_errno(r, Failed to create cgroup %s: %m, 
u-cgroup_path);
 
+if (wd  0  hashmap_put(u-manager-cgroup_populated_by_wd, 
INT_TO_PTR(wd), u-cgroup_path)  0)
+inotify_rm_watch(u-manager-cgroup_populated_inotify_fd, wd);
+
 /* Keep track that this is now realized */
 u-cgroup_realized = true;
 u-cgroup_realized_mask = mask;
@@ -893,6 +899,7 @@ pid_t unit_search_main_pid(Unit *u) {
 
 int manager_setup_cgroup(Manager *m) {
 _cleanup_free_ char *path = NULL;
+_cleanup_free_ char *sane_behavior = NULL;
 int r;
 
 assert(m);
@@ -944,7 +951,7 @@ int manager_setup_cgroup(Manager *m) {
 }
 
 /* 4. Make sure we are in the root cgroup */
-r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0);
+r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0, -1, NULL);
 if (r  0)
 return log_error_errno(r, Failed to create root 
cgroup hierarchy: %m);
 
@@ -957,6 +964,23 @@ int manager_setup_cgroup(Manager *m) {
 
 /* 6.  Always enable hierarchical support if it exists... */
 cg_set_attribute(memory, /, memory.use_hierarchy, 1);
+
+/* 7. Create inotify fd for cgroup.populated files, if
+ * supported on unified cgroups. Insane ones have
+ * cgroup.sane_behavior set to 0.*/
+r = cg_get_attribute(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, cgroup.sane_behavior, sane_behavior);
+if (r == -ENOENT) {
+m-cgroup_populated_inotify_fd = 
inotify_init1(IN_NONBLOCK|IN_CLOEXEC);
+if (m-cgroup_populated_inotify_fd  0)
+return log_error_errno(errno, inotify_init1() 
failed: %m);
+
+r = sd_event_add_io(m-event, 
m-cgroup_populated_event_source, m-cgroup_populated_inotify_fd, EPOLLIN, 
cgroup_populated_dispatch_io, m);
+if (r  0)
+return log_error_errno(errno, Failed to 
create inotify event source: %m);
+/* TODO what priority to set? */
+(void) 
sd_event_source_set_description(m-cgroup_populated_event_source, 
cgroup-populated);
+}
+
 }
 
 /* 7. Figure out which controllers are supported */
@@ -975,10 +999,63 @@ void manager_shutdown_cgroup(Manager *m, bool delete) {
 
 m-pin_cgroupfs_fd = safe_close(m-pin_cgroupfs_fd);
 
+m-cgroup_populated_inotify_fd = 
safe_close(m-cgroup_populated_inotify_fd);
+hashmap_free(m-cgroup_populated_by_wd);
+
 free(m-cgroup_root);
 m-cgroup_root = NULL;
 }
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata) {
+char *path;
+_cleanup_free_ char *v = NULL;
+Manager *m = userdata;
+int r;
+int populated = -1;
+
+assert(m);
+assert(revents  (EPOLLPRI | EPOLLIN));
+
+if (fd != m-cgroup_populated_inotify_fd)
+return 0;
+
+for (;;) {
+union inotify_event_buffer buffer;
+struct inotify_event *e;
+ssize_t l;
+
+l = read(fd, buffer, sizeof(buffer));
+if (l  0) {
+if (errno == EAGAIN || errno == EINTR)
+break;
+
+

[systemd-devel] [PATCH v2 4/5] unified-cgroup: fix cg_pid_get_path() and cg_get_path().

[Dimitri John Ledkov]

---
 src/shared/cgroup-util.c|  8 
 src/test/test-cgroup-util.c | 18 ++
 2 files changed, 26 insertions(+)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 2bca32a..eae9f5d 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -749,6 +749,11 @@ int cg_pid_get_path(const char *controller, pid_t pid, 
char **path) {
 } else
 controller = SYSTEMD_CGROUP_CONTROLLER;
 
+#ifdef HAVE_UNIFIED_CGROUP
+if (!strcmp(systemd, controller))
+controller = ;
+#endif
+
 fs = procfs_file_alloca(pid, cgroup);
 
 f = fopen(fs, re);
@@ -774,6 +779,9 @@ int cg_pid_get_path(const char *controller, pid_t pid, char 
**path) {
 if (!e)
 continue;
 
+if (cs == 0  e == l)
+found = true;
+
 *e = 0;
 
 FOREACH_WORD_SEPARATOR(word, k, l, ,, state) {
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 015d3d7..59e2c7f 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -219,6 +219,22 @@ static void test_proc(void) {
 }
 }
 
+static void test_cg_pid_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_pid_get_path(SYSTEMD_CGROUP_CONTROLLER, 0, path) == 0);
+
+assert_se(cg_pid_get_path(, 0, path) == 0);
+
+assert_se(cg_pid_get_path(NULL, 0, path) == 0);
+}
+
+static void test_cg_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_get_path(SYSTEMD_CGROUP_CONTROLLER, , , path) == 0);
+}
+
 static void test_escape_one(const char *s, const char *r) {
 _cleanup_free_ char *b;
 
@@ -306,6 +322,8 @@ int main(void) {
 test_path_get_user_slice();
 TEST_REQ_RUNNING_SYSTEMD(test_get_paths());
 test_proc();
+test_cg_pid_get_path();
+test_cg_get_path();
 TEST_REQ_RUNNING_SYSTEMD(test_escape());
 test_controller_is_valid();
 test_slice_to_path();
-- 
2.1.4

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

[systemd-devel] [PATCH v2 1/5] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

It appears in /proc/self/cgroup as `0::/'
---
 src/shared/cgroup-util.c| 4 
 src/test/test-cgroup-util.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 9988e5c..2bca32a 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool 
allow_named) {
 if (!p)
 return false;
 
+/* Unified cgroup */
+if (*p == 0)
+return true;
+
 if (allow_named) {
 s = startswith(p, name=);
 if (s)
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..015d3d7 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,8 @@ static void test_controller_is_valid(void) {
 assert_se(cg_controller_is_valid(foobar, false));
 assert_se(cg_controller_is_valid(foo_bar, false));
 assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
+assert_se(cg_controller_is_valid(, true));
+assert_se(cg_controller_is_valid(, false));
 assert_se(!cg_controller_is_valid(name=, true));
 assert_se(!cg_controller_is_valid(=, false));
 assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
-- 
2.1.4

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

[systemd-devel] [PATCH v2 2/5] configure.ac: add option for experimental unified cgroup handling.

[Dimitri John Ledkov]

---
 configure.ac | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/configure.ac b/configure.ac
index 92654a6..232d419 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1325,6 +1325,16 @@ AC_ARG_ENABLE(ldconfig,
 AM_CONDITIONAL(ENABLE_LDCONFIG, [test x$enable_ldconfig = xyes])
 
 # 
--
+have_unified_cgroup=no
+AC_ARG_ENABLE([unified-cgroup], AS_HELP_STRING([--enable-unified-cgroup], 
[enable experimental support for unified cgroup hierchy handling]),
+AS_CASE(x${enableval},
+[xyes], [have_unified_cgroup=yes],
+[xno],  [have_unified_cgroup=no],
+AC_MSG_ERROR(bad value ${enableval} for 
--enable-unified-cgroup)))
+AS_IF([test x$have_unified_cgroup = xyes], [AC_DEFINE(HAVE_UNIFIED_CGROUP, 
1, [Define if unified cgroup hierchy handling is desired])])
+AM_CONDITIONAL([HAVE_UNIFIED_CGROUP], [test x$have_unified_cgroup = xyes])
+
+# 
--
 # Location of the init scripts as mandated by LSB
 SYSTEM_SYSVINIT_PATH=/etc/init.d
 SYSTEM_SYSVRCND_PATH=/etc/rc.d
@@ -1571,6 +1581,7 @@ AC_MSG_RESULT([
 gintrospection:  ${enable_introspection}
 terminal:${have_terminal}
 kdbus:   ${have_kdbus}
+unified-cgroup:  ${have_unified_cgroup}
 Python:  ${have_python}
 Python Headers:  ${have_python_devel}
 man pages:   ${have_manpages}
-- 
2.1.4

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

[systemd-devel] [PATCH v2 0/5] resent

[Dimitri John Ledkov]

... sigh looks like I had duplicate patches generated in my tree.
this is a clean resent.

Dimitri John Ledkov (5):
  cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
  configure.ac: add option for experimental unified cgroup handling.
  core/mount-setup: Mount unified hierchy, instead of name=systemd, when
compiled to do so.
  unified-cgroup: fix cg_pid_get_path() and cg_get_path().
  core/cgroup: Add cgroup.populated inotify watches, when available.

 configure.ac| 11 ++
 src/core/cgroup.c   | 81 +++--
 src/core/manager.c  |  7 +++-
 src/core/manager.h  |  3 ++
 src/core/mount-setup.c  |  5 +++
 src/core/service.c  |  2 +-
 src/shared/cgroup-util.c| 40 ++
 src/shared/cgroup-util.h|  6 ++--
 src/shared/def.h|  4 +++
 src/test/test-cgroup-util.c | 21 +++-
 src/test/test-cgroup.c  | 12 +++
 11 files changed, 172 insertions(+), 20 deletions(-)

-- 
2.1.4

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

[systemd-devel] [PATCH v2 3/5] core/mount-setup: Mount unified hierchy, instead of name=systemd, when compiled to do so.

[Dimitri John Ledkov]

---
 src/core/mount-setup.c | 5 +
 src/shared/def.h   | 4 
 2 files changed, 9 insertions(+)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index c35248e..3112e00 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -94,10 +94,15 @@ static const MountPoint mount_table[] = {
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
 { tmpfs,   /sys/fs/cgroup,tmpfs,  
mode=755,MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#ifdef HAVE_UNIFIED_CGROUP
+{ cgroup,  /sys/fs/cgroup/systemd,cgroup, 
__DEVEL__sane_behavior,  MS_NOSUID|MS_NOEXEC|MS_NODEV,
+  NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#else
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_IN_CONTAINER   },
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,   MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#endif
 { pstore,  /sys/fs/pstore,pstore, NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_NONE   },
 #ifdef ENABLE_EFI
diff --git a/src/shared/def.h b/src/shared/def.h
index a3d9fcf..5790f4b 100644
--- a/src/shared/def.h
+++ b/src/shared/def.h
@@ -35,7 +35,11 @@
  * the watchdog pings will keep the loop busy. */
 #define DEFAULT_EXIT_USEC (30*USEC_PER_SEC)
 
+#ifdef HAVE_UNIFIED_CGROUP
+#define SYSTEMD_CGROUP_CONTROLLER 
+#else
 #define SYSTEMD_CGROUP_CONTROLLER name=systemd
+#endif
 
 #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 #define SIGNALS_IGNORE SIGPIPE
-- 
2.1.4

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

[systemd-devel] [PATCH 3/5] core/mount-setup: Mount unified hierchy, instead of name=systemd, when compiled to do so.

[Dimitri John Ledkov]

---
 src/core/mount-setup.c | 5 +
 src/shared/def.h   | 4 
 2 files changed, 9 insertions(+)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index c35248e..3112e00 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -94,10 +94,15 @@ static const MountPoint mount_table[] = {
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
 { tmpfs,   /sys/fs/cgroup,tmpfs,  
mode=755,MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#ifdef HAVE_UNIFIED_CGROUP
+{ cgroup,  /sys/fs/cgroup/systemd,cgroup, 
__DEVEL__sane_behavior,  MS_NOSUID|MS_NOEXEC|MS_NODEV,
+  NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#else
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_IN_CONTAINER   },
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,   MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#endif
 { pstore,  /sys/fs/pstore,pstore, NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_NONE   },
 #ifdef ENABLE_EFI
diff --git a/src/shared/def.h b/src/shared/def.h
index a3d9fcf..5790f4b 100644
--- a/src/shared/def.h
+++ b/src/shared/def.h
@@ -35,7 +35,11 @@
  * the watchdog pings will keep the loop busy. */
 #define DEFAULT_EXIT_USEC (30*USEC_PER_SEC)
 
+#ifdef HAVE_UNIFIED_CGROUP
+#define SYSTEMD_CGROUP_CONTROLLER 
+#else
 #define SYSTEMD_CGROUP_CONTROLLER name=systemd
+#endif
 
 #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 #define SIGNALS_IGNORE SIGPIPE
-- 
2.1.4

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

[systemd-devel] [PATCH 5/5] Add cgroup.populated inotify watches.

[Dimitri John Ledkov]

---
 src/core/cgroup.c| 81 ++--
 src/core/manager.c   |  7 -
 src/core/manager.h   |  3 ++
 src/core/service.c   |  2 +-
 src/shared/cgroup-util.c | 28 +
 src/shared/cgroup-util.h |  6 ++--
 src/test/test-cgroup.c   | 12 +++
 7 files changed, 120 insertions(+), 19 deletions(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6474e08..a1d7d93 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -30,6 +30,8 @@
 
 #define CGROUP_CPU_QUOTA_PERIOD_USEC ((usec_t) 100 * USEC_PER_MSEC)
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata);
+
 void cgroup_context_init(CGroupContext *c) {
 assert(c);
 
@@ -629,6 +631,7 @@ static const char *migrate_callback(CGroupControllerMask 
mask, void *userdata) {
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 CGroupContext *c;
 int r;
+int wd = -1;
 
 assert(u);
 
@@ -655,10 +658,13 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 }
 
 /* First, create our own group */
-r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path);
+r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path, u-manager-cgroup_populated_inotify_fd, wd);
 if (r  0)
 return log_error_errno(r, Failed to create cgroup %s: %m, 
u-cgroup_path);
 
+if (wd  0  hashmap_put(u-manager-cgroup_populated_by_wd, 
INT_TO_PTR(wd), u-cgroup_path)  0)
+inotify_rm_watch(u-manager-cgroup_populated_inotify_fd, wd);
+
 /* Keep track that this is now realized */
 u-cgroup_realized = true;
 u-cgroup_realized_mask = mask;
@@ -893,6 +899,7 @@ pid_t unit_search_main_pid(Unit *u) {
 
 int manager_setup_cgroup(Manager *m) {
 _cleanup_free_ char *path = NULL;
+_cleanup_free_ char *sane_behavior = NULL;
 int r;
 
 assert(m);
@@ -944,7 +951,7 @@ int manager_setup_cgroup(Manager *m) {
 }
 
 /* 4. Make sure we are in the root cgroup */
-r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0);
+r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0, -1, NULL);
 if (r  0)
 return log_error_errno(r, Failed to create root 
cgroup hierarchy: %m);
 
@@ -957,6 +964,23 @@ int manager_setup_cgroup(Manager *m) {
 
 /* 6.  Always enable hierarchical support if it exists... */
 cg_set_attribute(memory, /, memory.use_hierarchy, 1);
+
+/* 7. Create inotify fd for cgroup.populated files, if
+ * supported on unified cgroups. Insane ones have
+ * cgroup.sane_behavior set to 0.*/
+r = cg_get_attribute(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, cgroup.sane_behavior, sane_behavior);
+if (r == -ENOENT) {
+m-cgroup_populated_inotify_fd = 
inotify_init1(IN_NONBLOCK|IN_CLOEXEC);
+if (m-cgroup_populated_inotify_fd  0)
+return log_error_errno(errno, inotify_init1() 
failed: %m);
+
+r = sd_event_add_io(m-event, 
m-cgroup_populated_event_source, m-cgroup_populated_inotify_fd, EPOLLIN, 
cgroup_populated_dispatch_io, m);
+if (r  0)
+return log_error_errno(errno, Failed to 
create inotify event source: %m);
+/* TODO what priority to set? */
+(void) 
sd_event_source_set_description(m-cgroup_populated_event_source, 
cgroup-populated);
+}
+
 }
 
 /* 7. Figure out which controllers are supported */
@@ -975,10 +999,63 @@ void manager_shutdown_cgroup(Manager *m, bool delete) {
 
 m-pin_cgroupfs_fd = safe_close(m-pin_cgroupfs_fd);
 
+m-cgroup_populated_inotify_fd = 
safe_close(m-cgroup_populated_inotify_fd);
+hashmap_free(m-cgroup_populated_by_wd);
+
 free(m-cgroup_root);
 m-cgroup_root = NULL;
 }
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata) {
+char *path;
+_cleanup_free_ char *v = NULL;
+Manager *m = userdata;
+int r;
+int populated = -1;
+
+assert(m);
+assert(revents  (EPOLLPRI | EPOLLIN));
+
+if (fd != m-cgroup_populated_inotify_fd)
+return 0;
+
+for (;;) {
+union inotify_event_buffer buffer;
+struct inotify_event *e;
+ssize_t l;
+
+l = read(fd, buffer, sizeof(buffer));
+if (l  0) {
+if (errno == EAGAIN || errno == EINTR)
+break;
+
+

[systemd-devel] [PATCH 5/5] core/cgroup: Add cgroup.populated inotify watches, when available.

[Dimitri John Ledkov]

---
 src/core/cgroup.c| 81 ++--
 src/core/manager.c   |  7 -
 src/core/manager.h   |  3 ++
 src/core/service.c   |  2 +-
 src/shared/cgroup-util.c | 28 +
 src/shared/cgroup-util.h |  6 ++--
 src/test/test-cgroup.c   | 12 +++
 7 files changed, 120 insertions(+), 19 deletions(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6474e08..a1d7d93 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -30,6 +30,8 @@
 
 #define CGROUP_CPU_QUOTA_PERIOD_USEC ((usec_t) 100 * USEC_PER_MSEC)
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata);
+
 void cgroup_context_init(CGroupContext *c) {
 assert(c);
 
@@ -629,6 +631,7 @@ static const char *migrate_callback(CGroupControllerMask 
mask, void *userdata) {
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 CGroupContext *c;
 int r;
+int wd = -1;
 
 assert(u);
 
@@ -655,10 +658,13 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 }
 
 /* First, create our own group */
-r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path);
+r = cg_create_everywhere(u-manager-cgroup_supported, mask, 
u-cgroup_path, u-manager-cgroup_populated_inotify_fd, wd);
 if (r  0)
 return log_error_errno(r, Failed to create cgroup %s: %m, 
u-cgroup_path);
 
+if (wd  0  hashmap_put(u-manager-cgroup_populated_by_wd, 
INT_TO_PTR(wd), u-cgroup_path)  0)
+inotify_rm_watch(u-manager-cgroup_populated_inotify_fd, wd);
+
 /* Keep track that this is now realized */
 u-cgroup_realized = true;
 u-cgroup_realized_mask = mask;
@@ -893,6 +899,7 @@ pid_t unit_search_main_pid(Unit *u) {
 
 int manager_setup_cgroup(Manager *m) {
 _cleanup_free_ char *path = NULL;
+_cleanup_free_ char *sane_behavior = NULL;
 int r;
 
 assert(m);
@@ -944,7 +951,7 @@ int manager_setup_cgroup(Manager *m) {
 }
 
 /* 4. Make sure we are in the root cgroup */
-r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0);
+r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, 0, -1, NULL);
 if (r  0)
 return log_error_errno(r, Failed to create root 
cgroup hierarchy: %m);
 
@@ -957,6 +964,23 @@ int manager_setup_cgroup(Manager *m) {
 
 /* 6.  Always enable hierarchical support if it exists... */
 cg_set_attribute(memory, /, memory.use_hierarchy, 1);
+
+/* 7. Create inotify fd for cgroup.populated files, if
+ * supported on unified cgroups. Insane ones have
+ * cgroup.sane_behavior set to 0.*/
+r = cg_get_attribute(SYSTEMD_CGROUP_CONTROLLER, 
m-cgroup_root, cgroup.sane_behavior, sane_behavior);
+if (r == -ENOENT) {
+m-cgroup_populated_inotify_fd = 
inotify_init1(IN_NONBLOCK|IN_CLOEXEC);
+if (m-cgroup_populated_inotify_fd  0)
+return log_error_errno(errno, inotify_init1() 
failed: %m);
+
+r = sd_event_add_io(m-event, 
m-cgroup_populated_event_source, m-cgroup_populated_inotify_fd, EPOLLIN, 
cgroup_populated_dispatch_io, m);
+if (r  0)
+return log_error_errno(errno, Failed to 
create inotify event source: %m);
+/* TODO what priority to set? */
+(void) 
sd_event_source_set_description(m-cgroup_populated_event_source, 
cgroup-populated);
+}
+
 }
 
 /* 7. Figure out which controllers are supported */
@@ -975,10 +999,63 @@ void manager_shutdown_cgroup(Manager *m, bool delete) {
 
 m-pin_cgroupfs_fd = safe_close(m-pin_cgroupfs_fd);
 
+m-cgroup_populated_inotify_fd = 
safe_close(m-cgroup_populated_inotify_fd);
+hashmap_free(m-cgroup_populated_by_wd);
+
 free(m-cgroup_root);
 m-cgroup_root = NULL;
 }
 
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd, 
uint32_t revents, void *userdata) {
+char *path;
+_cleanup_free_ char *v = NULL;
+Manager *m = userdata;
+int r;
+int populated = -1;
+
+assert(m);
+assert(revents  (EPOLLPRI | EPOLLIN));
+
+if (fd != m-cgroup_populated_inotify_fd)
+return 0;
+
+for (;;) {
+union inotify_event_buffer buffer;
+struct inotify_event *e;
+ssize_t l;
+
+l = read(fd, buffer, sizeof(buffer));
+if (l  0) {
+if (errno == EAGAIN || errno == EINTR)
+break;
+
+

[systemd-devel] [PATCH 2/5] configure.ac: add option for experimental unified cgroup handling.

[Dimitri John Ledkov]

---
 configure.ac | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/configure.ac b/configure.ac
index 92654a6..232d419 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1325,6 +1325,16 @@ AC_ARG_ENABLE(ldconfig,
 AM_CONDITIONAL(ENABLE_LDCONFIG, [test x$enable_ldconfig = xyes])
 
 # 
--
+have_unified_cgroup=no
+AC_ARG_ENABLE([unified-cgroup], AS_HELP_STRING([--enable-unified-cgroup], 
[enable experimental support for unified cgroup hierchy handling]),
+AS_CASE(x${enableval},
+[xyes], [have_unified_cgroup=yes],
+[xno],  [have_unified_cgroup=no],
+AC_MSG_ERROR(bad value ${enableval} for 
--enable-unified-cgroup)))
+AS_IF([test x$have_unified_cgroup = xyes], [AC_DEFINE(HAVE_UNIFIED_CGROUP, 
1, [Define if unified cgroup hierchy handling is desired])])
+AM_CONDITIONAL([HAVE_UNIFIED_CGROUP], [test x$have_unified_cgroup = xyes])
+
+# 
--
 # Location of the init scripts as mandated by LSB
 SYSTEM_SYSVINIT_PATH=/etc/init.d
 SYSTEM_SYSVRCND_PATH=/etc/rc.d
@@ -1571,6 +1581,7 @@ AC_MSG_RESULT([
 gintrospection:  ${enable_introspection}
 terminal:${have_terminal}
 kdbus:   ${have_kdbus}
+unified-cgroup:  ${have_unified_cgroup}
 Python:  ${have_python}
 Python Headers:  ${have_python_devel}
 man pages:   ${have_manpages}
-- 
2.1.4

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

[systemd-devel] [PATCH 4/5] unified-cgroup: fix cg_pid_get_path() and cg_get_path().

[Dimitri John Ledkov]

---
 src/shared/cgroup-util.c|  8 
 src/test/test-cgroup-util.c | 18 ++
 2 files changed, 26 insertions(+)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 2bca32a..eae9f5d 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -749,6 +749,11 @@ int cg_pid_get_path(const char *controller, pid_t pid, 
char **path) {
 } else
 controller = SYSTEMD_CGROUP_CONTROLLER;
 
+#ifdef HAVE_UNIFIED_CGROUP
+if (!strcmp(systemd, controller))
+controller = ;
+#endif
+
 fs = procfs_file_alloca(pid, cgroup);
 
 f = fopen(fs, re);
@@ -774,6 +779,9 @@ int cg_pid_get_path(const char *controller, pid_t pid, char 
**path) {
 if (!e)
 continue;
 
+if (cs == 0  e == l)
+found = true;
+
 *e = 0;
 
 FOREACH_WORD_SEPARATOR(word, k, l, ,, state) {
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 015d3d7..59e2c7f 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -219,6 +219,22 @@ static void test_proc(void) {
 }
 }
 
+static void test_cg_pid_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_pid_get_path(SYSTEMD_CGROUP_CONTROLLER, 0, path) == 0);
+
+assert_se(cg_pid_get_path(, 0, path) == 0);
+
+assert_se(cg_pid_get_path(NULL, 0, path) == 0);
+}
+
+static void test_cg_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_get_path(SYSTEMD_CGROUP_CONTROLLER, , , path) == 0);
+}
+
 static void test_escape_one(const char *s, const char *r) {
 _cleanup_free_ char *b;
 
@@ -306,6 +322,8 @@ int main(void) {
 test_path_get_user_slice();
 TEST_REQ_RUNNING_SYSTEMD(test_get_paths());
 test_proc();
+test_cg_pid_get_path();
+test_cg_get_path();
 TEST_REQ_RUNNING_SYSTEMD(test_escape());
 test_controller_is_valid();
 test_slice_to_path();
-- 
2.1.4

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

[systemd-devel] [PATCH 0/5] experimental basic unified cgroups work

[Dimitri John Ledkov]

This is initial basic experimental integration of unified cgroups
work. I've started this by adding compile time option to switch the
behaviour a little bit.

At the moment this does the following for the /sys/fs/cgroup/systemd
mountpoint:
 - instead of mounting name=systemd legacy cgroup
 - it mounts unified cgroup without any controller

And then it uses the cgroup.populated flag file for efficient inotify
based cgroup release notification.

The real great bit about this is that one can start hacking further on
this, without breaking one's system as the rest of the controller are
where they usually are.

There are a few minor tweaks that I'm spotting in this integration,
that I will follow up on, but for now enjoy, try out, and let me know
what you think.

Dimitri John Ledkov (5):
  cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
  configure.ac: add option for experimental unified cgroup handling.
  core/mount-setup: Mount unified hierchy, instead of name=systemd, when
compiled to do so.
  unified-cgroup: fix cg_pid_get_path() and cg_get_path().
  core/cgroup: Add cgroup.populated inotify watches, when available.

 configure.ac| 11 ++
 src/core/cgroup.c   | 81 +++--
 src/core/manager.c  |  7 +++-
 src/core/manager.h  |  3 ++
 src/core/mount-setup.c  |  5 +++
 src/core/service.c  |  2 +-
 src/shared/cgroup-util.c| 40 ++
 src/shared/cgroup-util.h|  6 ++--
 src/shared/def.h|  4 +++
 src/test/test-cgroup-util.c | 21 +++-
 src/test/test-cgroup.c  | 12 +++
 11 files changed, 172 insertions(+), 20 deletions(-)

-- 
2.1.4

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

[systemd-devel] [PATCH 1/5] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

It appears in /proc/self/cgroup as `0::/'
---
 src/shared/cgroup-util.c| 4 
 src/test/test-cgroup-util.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 9988e5c..2bca32a 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool 
allow_named) {
 if (!p)
 return false;
 
+/* Unified cgroup */
+if (*p == 0)
+return true;
+
 if (allow_named) {
 s = startswith(p, name=);
 if (s)
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..015d3d7 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,8 @@ static void test_controller_is_valid(void) {
 assert_se(cg_controller_is_valid(foobar, false));
 assert_se(cg_controller_is_valid(foo_bar, false));
 assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
+assert_se(cg_controller_is_valid(, true));
+assert_se(cg_controller_is_valid(, false));
 assert_se(!cg_controller_is_valid(name=, true));
 assert_se(!cg_controller_is_valid(=, false));
 assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
-- 
2.1.4

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

[systemd-devel] [PATCH 3/5] Mount unified hierchy, instead of name=systemd.

[Dimitri John Ledkov]

---
 src/core/mount-setup.c | 5 +
 src/shared/def.h   | 4 
 2 files changed, 9 insertions(+)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index ba96741..1cf7099 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -94,10 +94,15 @@ static const MountPoint mount_table[] = {
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
 { tmpfs,   /sys/fs/cgroup,tmpfs,  
mode=755,MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#ifdef HAVE_UNIFIED_CGROUP
+{ cgroup,  /sys/fs/cgroup/systemd,cgroup, 
__DEVEL__sane_behavior,  MS_NOSUID|MS_NOEXEC|MS_NODEV,
+  NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#else
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_IN_CONTAINER   },
 { cgroup,  /sys/fs/cgroup/systemd,cgroup, 
none,name=systemd,   MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_FATAL|MNT_IN_CONTAINER },
+#endif
 { pstore,  /sys/fs/pstore,pstore, NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_NONE   },
 #ifdef ENABLE_EFI
diff --git a/src/shared/def.h b/src/shared/def.h
index a3d9fcf..5790f4b 100644
--- a/src/shared/def.h
+++ b/src/shared/def.h
@@ -35,7 +35,11 @@
  * the watchdog pings will keep the loop busy. */
 #define DEFAULT_EXIT_USEC (30*USEC_PER_SEC)
 
+#ifdef HAVE_UNIFIED_CGROUP
+#define SYSTEMD_CGROUP_CONTROLLER 
+#else
 #define SYSTEMD_CGROUP_CONTROLLER name=systemd
+#endif
 
 #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 #define SIGNALS_IGNORE SIGPIPE
-- 
2.1.4

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

Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote:
 On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 It appears in /proc/self/cgroup as `0::/'

 What precisely does this fix?

 I mean, we need to do some major rework of things before the unified
 hierarchy is really supported in systemd, and this one thing won't
 really get us too much in this regard, does it?


I'm starting to explore possibilities to start work towards supporting
unified cgroups hierarchy, or at least be able to boot with it. I'll
send a larger patch series in one go later than with all the bits that
offer something more tangible, albeit disabled by default behind
configure options (like kdbus) given that unified hierarchy is still
marked experimental in the kernel.

Regards,

Dimitri.


 ---

  v2 change: Test for unified cgroup should pass irrespective of
  whether allow_named is set.

  src/shared/cgroup-util.c| 4 
  src/test/test-cgroup-util.c | 3 ++-
  2 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
 index c0b0ca4..eda7523 100644
 --- a/src/shared/cgroup-util.c
 +++ b/src/shared/cgroup-util.c
 @@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool 
 allow_named) {
  if (!p)
  return false;

 +/* Unified cgroup */
 +if (*p == 0)
 +return true;
 +
  if (allow_named) {
  s = startswith(p, name=);
  if (s)
 diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
 index 4a89f64..015d3d7 100644
 --- a/src/test/test-cgroup-util.c
 +++ b/src/test/test-cgroup-util.c
 @@ -247,7 +247,8 @@ static void test_controller_is_valid(void) {
  assert_se(cg_controller_is_valid(foobar, false));
  assert_se(cg_controller_is_valid(foo_bar, false));
  assert_se(cg_controller_is_valid(name=foo, true));
 -assert_se(!cg_controller_is_valid(, false));
 +assert_se(cg_controller_is_valid(, true));
 +assert_se(cg_controller_is_valid(, false));
  assert_se(!cg_controller_is_valid(name=, true));
  assert_se(!cg_controller_is_valid(=, false));
  assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
 --
 2.1.4

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


 Lennart

 --
 Lennart Poettering, Red Hat



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts

[Dimitri John Ledkov]

On 28 May 2015 at 12:31, Lennart Poettering lenn...@poettering.net wrote:
 On Wed, 27.05.15 15:13, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello,

 if you have both a systemd unit and a SysV init script with the same
 name, systemctl {en,dis}able currently diverts to chkconfig and
 friends *only*, without actually enabling/disabling the native unit.
 This is a non-issue for Fedora packages which eliminated init.d
 scripts, but still an issue for e. g. Debian or third-party packages
 which want to support multiple init systems.

 Hmm? THis sounds the wrong way round. What currently happens should be
 this: if both are available systemd ignores the sysv script, and only
 considers the native unit. Is that what you are trying to say?

 And you now want everything to be applied to both the sysv script and
 the native unit?

 What happens if we query the state of things with is-enabled, then?

Debian supports rebooting with either sysv-init or systemd hence
the key point here multiple init systems, simultaneously within single
install.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

It appears in /proc/self/cgroup as `0::/'
---
 src/shared/cgroup-util.c| 4 
 src/test/test-cgroup-util.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index c0b0ca4..eda7523 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool 
allow_named) {
 if (!p)
 return false;
 
+/* Unified cgroup */
+if (*p == 0)
+return true;
+
 if (allow_named) {
 s = startswith(p, name=);
 if (s)
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..e4c3432 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,7 @@ static void test_controller_is_valid(void) {
 assert_se(cg_controller_is_valid(foobar, false));
 assert_se(cg_controller_is_valid(foo_bar, false));
 assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
+assert_se(cg_controller_is_valid(, true));
 assert_se(!cg_controller_is_valid(name=, true));
 assert_se(!cg_controller_is_valid(=, false));
 assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
-- 
2.1.4

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

[systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Dimitri John Ledkov]

It appears in /proc/self/cgroup as `0::/'
---

 v2 change: Test for unified cgroup should pass irrespective of
 whether allow_named is set.

 src/shared/cgroup-util.c| 4 
 src/test/test-cgroup-util.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index c0b0ca4..eda7523 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool 
allow_named) {
 if (!p)
 return false;
 
+/* Unified cgroup */
+if (*p == 0)
+return true;
+
 if (allow_named) {
 s = startswith(p, name=);
 if (s)
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..015d3d7 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,8 @@ static void test_controller_is_valid(void) {
 assert_se(cg_controller_is_valid(foobar, false));
 assert_se(cg_controller_is_valid(foo_bar, false));
 assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
+assert_se(cg_controller_is_valid(, true));
+assert_se(cg_controller_is_valid(, false));
 assert_se(!cg_controller_is_valid(name=, true));
 assert_se(!cg_controller_is_valid(=, false));
 assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
-- 
2.1.4

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

Re: [systemd-devel] [PATCH 2/2] man: use configured path for mount and umount binaries in manpages

[Dimitri John Ledkov]

On 27 May 2015 at 10:38, Filipe Brandenburger filbran...@google.com wrote:
 Export the MOUNT_PATH and UMOUNT_PATH variables as XML entities and use them 
 in
 the systemctl.1 manpage instead of hardcoding the path in /usr/bin.

 Tested:
 - Ran ./configure ac_cv_path_MOUNT_PATH=/bin/mount (same for umount) and
   rebuilt the manpages, confirmed that the correct path was in man/systemctl.1
 - Rebuilt man/systemd.directives.xml and the man pages derived from it,
   confirmed that the correct paths were there as well.

+1 from me. Sorry for the change =)))

 ---
  Makefile.am   | 2 ++
  man/systemctl.xml | 4 ++--
  2 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index d6010c5..98ceb77 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -6505,6 +6505,8 @@ substitutions = \
 '|DEBUGTTY=$(DEBUGTTY)|' \
 '|KILL=$(KILL)|' \
 '|KMOD=$(KMOD)|' \
 +   '|MOUNT_PATH=$(MOUNT_PATH)|' \
 +   '|UMOUNT_PATH=$(UMOUNT_PATH)|' \
 '|MKDIR_P=$(MKDIR_P)|' \
 '|QUOTAON=$(QUOTAON)|' \
 '|QUOTACHECK=$(QUOTACHECK)|' \
 diff --git a/man/systemctl.xml b/man/systemctl.xml
 index a2c8a73..35f47de 100644
 --- a/man/systemctl.xml
 +++ b/man/systemctl.xml
 @@ -413,8 +413,8 @@
processes. Not all unit types manage processes of these
types however. For example, for mount units, control processes
are defined (which are the invocations of
 -  filename/usr/bin/mount/filename and
 -  filename/usr/bin/umount/filename), but no main process
 +  filenameMOUNT_PATH;/filename and
 +  filenameUMOUNT_PATH;/filename), but no main process
is defined. If omitted, defaults to
optionall/option./para
  /listitem
 --
 2.4.1

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



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Dimitri John Ledkov]

On 27 May 2015 at 10:52, Martin Pitt martin.p...@ubuntu.com wrote:
 Lennart Poettering [2015-05-27 11:42 +0200]:
 Well, but let's not forget that a major part of the issues popping up
 actually were committed weeks ago.

 Actually, no. As I said, on May 11 most everything was working just
 fine, the udev regressions landed very late. The path_is_mount_point()
 regression landed much earlier, but is much less visible (and now
 there are tests cases with the patch I sent).

 Things like the broken gperf generated bits or the missing EFI dirs
 were in git since a lng time.

 It would be great if downstream could help us with testing many of the
 build combinations, at any time of the cycle, not just when it comes
 to a release.

 Agreed. The broken tarball issues are not visible when building from
 git (which is what I'm doing all the time). We didn't have that kind
 of issues with 219 or 218 (or at least only negligible ones), but 220
 taught us all that we need to test make dist builds more often.

 So we have two indepenent things to fix:

  * Regularly test make dist, as nobody does that  during regular
development.

Alternative: Stop shipping make dist tarballs altogether and just
tar the tagged git snapshot. Given the amount of patching that most
distros do, we pretty much all run autoreconf anyway (including
Fedora), so not having the pre-generated autoconfiscation and
pre-built manpages etc. in the tarball isn't actually that much of
a deal.


+1 for dropping make dist support... git archive is really ought to be
the release tarball.


  * Impose a release freeze period with announcing an impending
release, distros do a deep testing (this is a day's work for me, so
can't happen that often). During that time (which really shouldn't
be more than a few days) we really should avoid any commit which
isn't an important bug fix, especially not large refactorings or
new features.

 Thanks,

 Martin

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



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Dimitri John Ledkov]

On 26 May 2015 at 15:10, Martin Pitt martin.p...@ubuntu.com wrote:
 Lennart Poettering [2015-05-26 16:06 +0200]:
 I think this has been fixed now with Tom's commit
 ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

 Confirmed this morning. Sorry, I should have followed up to the ML
 immediately. Thanks Tom!

Can stable-v220 branch be started with these please?

Or will there be a v220.1 release shortly with releasy fix-ups?
-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] preset activation on first boot takes too long

[Dimitri John Ledkov]

On 14 May 2015 at 18:00, Lennart Poettering lenn...@poettering.net wrote:
 On Thu, 14.05.15 17:13, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 Heya,

 I'm looking at bootcharts and it seems like first boot preset
 activation takes too much time...

 So at the moment, we iterate all units, then iterate through presets
 until we find a match and act upon it.

 However, most distros have disable * as their last setting, or don't
 use presets at all.

 Furthermore looking at a fully featured system (e.g. my ubuntu laptop):
 * 158 files do not have install section
 * 89 have an install secion

 Also it seems odd to have all of this in the pid one critical path -
 e.g. these things are being parsed before anything happens.

 Thus I wonder if the presets should be moved into e.g. a generator
 that will do the following on first boot only:

 Hmm, generators so far were strictly something that would generate
 output in the generator unit paths we pass to them, and nowhere
 else. These directories would then be lifecycled by the daemon
 runtime, and flushed on daemon reload. The generators would then be
 invoked with new, empty generator unit directories on daemon reload.

 The preset logic otoh creates persistent changes in /etc, that will
 only and exlcusively be run if /etc is unpopulated. They logic is not
 rerun on daemon reload, and nothing is ever flushed.

 I am pretty sure this should stay that way. We shouldn't turn
 generators into more than what they are right now. They should not
 have persistent effect.

 However, I am all open for optimizing the codepaths here. Maybe we can
 cache the preset files in memory or so. And/or we could move the
 preset code into its own binary, which we fork off explicitly before
 running the generators, and then wait for after the generators (so
 that the binary runs in parallel to the generators). Alternatively we
 could even run it as thread from PID 1 in parallel to waiting for the
 generators, as long as it shares zero state with the rest of PID
 1. (That said, I am usually not too fond of threads, and especially
 not in PID 1.)

 * parse .preset files
 * construct list of things to enable
 * enable all the units in that list

 OK, so this would mean caching the preset file, and then doing pretty
 much the same as before? I am fine with that. (But not as a generator,
 as mentioned above)

 This should cut I/O and processing time at first boot by a bit, since
 only the units to be activated will be parsed.

 Hmm? not following here. are you suggesting to use the preset file
 list as base list of units to enable and then search for them in the
 file system without ever enumerating unit files in the fs? This will
 not really work, as the list contains glob expressions, and more
 complicated ones than just disable *. For examples things like
 enable avahi-daemon.* which enables both the socket and the service
 in one step. But it could also be enable foo-*.service, for a
 project foo, that has many different services it wants to enable
 with a single line... And crazy people could even use more complex
 matches...

 Hence, I am pretty sure the list of unit files enumerated from disk
 needs to be used as basis, and then checked against the preset file,
 not the other way round.

 One thing you could use for optimizing: a TODO list item has been for
 a while to change the first-boot preset logic to operate in a purely
 additive way: don't bother with disabling any services then (in most
 cases there will be nothing enabled at that time anyway), but only
 operate on the enable cases. Doing this would allow you to avoid
 loading the unit files for the disable lines, as you you don't care
 for their [Install] section then.

Right. I used the term generator too flamboyant here indeed, as this
optimised preset parsing cannot ever be a generator-spec compliant.

I think optimisations above will work, especially given that we don't
honour aliases ahead of time
(that is bar.service unit with Alias=foo.service is not enabled, with
enable foo.service preset)
This is really good, as I think pre-parsing presets will help a lot here.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core: Execute first boot presets in an enable-only preset-mode.

[Dimitri John Ledkov]

This means any existing enabled units well be preserved and no
pre-created symlinks will be removed. This is done on first boot, when
the assumption is that /etc is not populated at all (no machine-id
setup). For minimal containers that gives a significant first boot
speed up, approximately ~20ms / ~16% in my trials.
---
 TODO| 4 
 src/core/main.c | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/TODO b/TODO
index 932fef6..dd85f57 100644
--- a/TODO
+++ b/TODO
@@ -149,10 +149,6 @@ Features:
   that are not supported...
   http://lists.freedesktop.org/archives/systemd-devel/2015-February/028076.html
 
-* PID 1: when invoking systemctl preset-all on first boots, operate in
-  an exclusively additive way, i.e. never remove any pre-existing
-  symlinks, only add new ones.
-
 * Introduce $LISTEN_NAMES to complement $LISTEN_FDS, containing a
   colon separated list of identifiers for the fds passed.
 
diff --git a/src/core/main.c b/src/core/main.c
index 08e84d8..c39815b 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1618,7 +1618,7 @@ int main(int argc, char *argv[]) {
 bump_rlimit_nofile(saved_rlimit_nofile);
 
 if (empty_etc) {
-r = unit_file_preset_all(UNIT_FILE_SYSTEM, false, 
NULL, UNIT_FILE_PRESET_FULL, false, NULL, 0);
+r = unit_file_preset_all(UNIT_FILE_SYSTEM, false, 
NULL, UNIT_FILE_PRESET_ENABLE_ONLY, false, NULL, 0);
 if (r  0)
 log_warning_errno(r, Failed to populate /etc 
with preset unit settings, ignoring: %m);
 else
-- 
2.1.4

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

Re: [systemd-devel] [PATCH] .gitignore: add GNU GLOBAL files

[Dimitri John Ledkov]

Heya,

On 15 May 2015 at 16:12, Łukasz Stelmach l.stelm...@samsung.com wrote:
 ---
  .gitignore | 4 
  1 file changed, 4 insertions(+)

 diff --git a/.gitignore b/.gitignore
 index f550950..d2f1a1f 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -22,6 +22,10 @@
  /*.tar.xz
  /Makefile
  /TAGS
 +/GPATH
 +/GRTAGS
 +/GSYMS
 +/GTAGS
  /accelerometer
  /ata_id
  /bootctl

I'd think this falls into my personal IDE cruft files, thus I'd
recommend you to do this:

[core]
excludesfile = ~/.gitignore_global

And then there specify those files. That way GTAGS and friends will be
ignored for you, in _all_ git repositories everywhere and you don't
need to modify ignore files in all upstream projects...


-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] .gitignore: add GNU GLOBAL files

[Dimitri John Ledkov]

On 15 May 2015 at 17:19, Łukasz Stelmach l.stelm...@samsung.com wrote:
 It was 2015-05-15 pią 18:03, when Lennart Poettering wrote:
 On Fri, 15.05.15 17:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

 It was 2015-05-15 pią 17:25, when Lennart Poettering wrote:
  On Fri, 15.05.15 17:12, Łukasz Stelmach (l.stelm...@samsung.com) wrote:
 
  Hmm? What is GNU GLOBAL?

 Another cscope. A quote from http://www.gnu.org/software/global/

 --8---cut here---start-8---
 GNU GLOBAL is a source code tagging system that works the same way
 across diverse environments, such as Emacs editor, Vi editor, Less
 viewer, Bash shell, various web browsers, etc.

 You can locate various objects, such as functions, macros, structs,
 classes, in your source files and move there easily. [...]
 --8---cut here---end---8---

 The index files should not appear in git status.

 And is that tool even popular?

 Admittedly not the most popular but noticable.

 https://qa.debian.org/popcon-graph.php?packages=cscope%2Cglobal%2Cexuberant-ctagsshow_installed=onwant_percent=onwant_legend=onwant_ticks=onfrom_date=2010-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1


With my Debian Developer hat on... popcon is not a metric... We mostly
still have it as a trap - whenever popcon used as a reason it is shot
down as invalid =)

More importantly it tells nothing about what /systemd-developers/ use,
and actually it is negligible amount of submitters if one looks at
vote or recent graphs. Imho .gitignore should only be used to
clean-up  ignore by products that a given project generates, the rest
IDE cruft is to be ignored on per user cases in a global excludes file
as I've shown earlier.

Anyway, it's merged now, but in practice I don't see a need to merge
more of IDE-cruft ignore rules.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] preset activation on first boot takes too long

[Dimitri John Ledkov]

Heya,

I'm looking at bootcharts and it seems like first boot preset
activation takes too much time...

So at the moment, we iterate all units, then iterate through presets
until we find a match and act upon it.

However, most distros have disable * as their last setting, or don't
use presets at all.

Furthermore looking at a fully featured system (e.g. my ubuntu laptop):
* 158 files do not have install section
* 89 have an install secion

Also it seems odd to have all of this in the pid one critical path -
e.g. these things are being parsed before anything happens.

Thus I wonder if the presets should be moved into e.g. a generator
that will do the following on first boot only:

* parse .preset files
* construct list of things to enable
* enable all the units in that list

This should cut I/O and processing time at first boot by a bit, since
only the units to be activated will be parsed.

That also kind of means that it will only work if the last fallback
policy is disable *.

For a reference, preset enabling on first boot accounts for around
6.5% of the first boot time for me on fairly minimal containers / base
VMs.

What do you think about this?

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)

[Dimitri John Ledkov]

Hello,

On 14 May 2015 at 08:10, Per Bergqvist p...@bst.lu wrote:
 Hej,

 There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer
 which was
 sort of rejected by Kay Sievers by referring to “we should find out what to
 do for nvme before
 adding new users of scsi_id”.

 More than a year later nothing has happened and recent commits actually
 branch out early
 for nvme drives.

 I have been using similar patches to Hal's albeit a little bit different.

 +# NVMe
 +KERNEL==nvme*, ENV{ID_SCSI_SERIAL}!=?*, IMPORT{program}=scsi_id
 --export --whitelisted -d $devnode
 +KERNEL==nvme*, ENV{DEVTYPE}==disk, ENV{ID_SCSI_SERIAL}==?*,
 SYMLINK+=disk/by-id/nvme-$env{ID_SCSI_SERIAL}
 +KERNEL==nvme*, ENV{DEVTYPE}==partition, ENV{ID_SCSI_SERIAL}==?*,
 SYMLINK+=disk/by-id/nvme-$env{ID_SCSI_SERIAL}-part%n
 +


This looks odd to me, from NVMe perspective. I would have thought the
stable names would be generated based on the NVMe Namespace UIDs
rather than anything else.

Keith - could you comment on above ^ ?

 I have found that the ID_SCSI_SERIAL is the most reliable since ID_SERIAL
 varies depending on systemd/driver/kernel versions.
 (My primary use for the NVMe drives is zfs log and cache devices. I test the
 zfs pool with different OS:es so I need
 the naming to be consistent over all targets OS:es).

 One may argue as Kay that it is not a scsi bus, but I think that the NVMe is
 related close enough to use the
 scsi_id, especially if considering the “NVM Express: SCSI Translation
 Reference”
 (http://www.nvmexpress.org/wp-content/uploads/NVM_Express_-_SCSI_Translation_Reference-1_4_20150116_Gold2.pdf).

 There is definitely a need for nvme support in udev and I think
 60-persistent-storage.rules is the correct place.

 The only issue I can see is wether or not to use scsi_id or to introduce a
 new nvme_id utility.

 BR
 Per






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




-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: add x-systemd.{after, requires-mounts-for}=

[Dimitri John Ledkov]

On 13 May 2015 at 10:15, Karel Zak k...@redhat.com wrote:
 On Wed, May 13, 2015 at 06:35:58AM +0300, Andrei Borzenkov wrote:
 В Tue, 12 May 2015 20:37:15 +0200
 Karel Zak k...@redhat.com пишет:

  On Tue, May 12, 2015 at 07:29:33PM +0300, Andrei Borzenkov wrote:
   В Tue, 12 May 2015 18:04:50 +0200
   Karel Zak k...@redhat.com пишет:
  
Currently we have no way how to specify dependencies between fstab
entries (or another units) in the /etc/fstab. It means that users are
forced to bypass fstab and write .mount units manually.
   
  
   Actually we have.
  
   mkdir -p /etc/systemd/system/path-to-mount-point.mount.d
   cat  /etc/systemd/system/path-to-mount-point.mount.d/deps.conf  EOF
   [Unit]
   After=xxx
   Before=xxx
   Wants=xxx
   Requires=xxx
   EOF
 
  You miss the point -- keep all in fstab.
 

 I admit I do. Why? We want to keep in fstab bits and pieces that are
 common with other utilities. Which other tool needs to know systemd
 dependencies?

  Did you read the reference in the patch? It's not about systemd
  dependences, but about dependences between mount points. The fstab
  has been originally (by mount -a) serialized during boot. Now it's
  parallelized and in some cases it's bad thing and without extra
  configuration systemd is not able to understand the dependencies in
  fstab. It's admins' nightmare to require additional file somewhere in
  /etc/systemd to fix systemd fstab interpretation.

  BTW, we already have x-systemd stuff in fstab...

+1 from me, this is needed. Back in the upstart / mountall case,
dependencies were established between mount points, and failing that
explicit ordering was established - as in each subsequent fstab stanza
depended on the previous one. That was enough in general case, but it
was at times un-expected that reordering entries resulted in wrong
boot order.

If ftab generator creates linear dependency chain, would that be
enough without adding extra mount options or do you want
generic/explicit dependencies as per your patch?

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: add x-systemd.{after, requires-mounts-for}=

[Dimitri John Ledkov]

On 13 May 2015 at 13:33, Lennart Poettering lenn...@poettering.net wrote:
 On Tue, 12.05.15 19:29, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 All examples can be configured using drop-ins. Do we really need yet
 another syntax now?

 Well, even though units are all-powerful, I still believe that fstab
 is probably where most people will configure their stuff, simply
 because it's so much simpler to use.


... and the only place where you can define different mount options
and expect them to take effect. This is because remount-fs only
remounts things defined in fstab, and doesn't remount things that are
defined via .mount units.

 Now, of course, we shouldn't try to reimplement all possible settings
 that .mount unit files provide as fstab options. But the most obvious
 ones probably *do* make sense to add, and x-systemd.requires= is
 probably one of them. It's not only useful for stuff like overlayfs,
 but also pretty essential for things like ext3, ext4, xfs which
 support external journal logging devices, for which the mounts need to
 express dependencies:

 https://bugzilla.redhat.com/show_bug.cgi?id=1164334

 Lennart

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



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

[Dimitri John Ledkov]

Heya,

On 13 May 2015 at 12:53, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey Dimitri,

 Dimitri John Ledkov [2015-05-13 12:48 +0100]:
 Yet, dev-root.device is dead:
 # systemctl status dev-root.device
 ● dev-root.device
Loaded: loaded
Active: inactive (dead)

 This is very bad. As a harmless action like following:

 # mount --bind /opt /opt

 Results in opt.mount unit to be generated which BindsTo
 dev-root.device, which is inactive, thus systemd tries to stop that
 unit straight away, and umount fails and is retried infinitely...
 effectively DoSing init.

 For the record, I got a similar bug report a while ago:
 https://bugs.launchpad.net/systemd/+bug/102
 This is reproducible in a container with udev running, see the small
 reproducer in the bug trail.

 This is on my plate to investigate/fix, I just got interrupted by a
 couple of security issues, so not this week.


Yes, quite.

So this affects / affected rocket, dracut, ostree, rkt and any other
similar containers / VMs.

Colin, has this been addressed and fixed at all? Or was this
workaround with don't do this.

My current plug is to exclude umount har har.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] dev-root.device is not active, results in an umount spree

[Dimitri John Ledkov]

I am booting without initramfs, using a plan9 filesystem as rootfs in a kvm.

Thus my /proc/cmdline has:
root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p

# mount
/dev/root on / type 9p
(rw,relatime,sync,dirsync,rw,trans=virtio,version=9p2000.L)

Yet, dev-root.device is dead:
# systemctl status dev-root.device
● dev-root.device
   Loaded: loaded
   Active: inactive (dead)

This is very bad. As a harmless action like following:

# mount --bind /opt /opt

Results in opt.mount unit to be generated which BindsTo
dev-root.device, which is inactive, thus systemd tries to stop that
unit straight away, and umount fails and is retried infinitely...
effectively DoSing init.

What am I missing and/or how can I force make dev-root.device to be
considered active?

I am planning to locally patch mount_add_device_links to skip if what
is /dev/root, to avoid a call to unit_add_node_link... But I'm not
sure if this is the right thing to do or not.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

[Dimitri John Ledkov]

On 13 May 2015 at 13:43, Lennart Poettering lenn...@poettering.net wrote:
 On Wed, 13.05.15 12:48, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 I am booting without initramfs, using a plan9 filesystem as rootfs in a kvm.

 Thus my /proc/cmdline has:
 root=/dev/root rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p

 # mount
 /dev/root on / type 9p
 (rw,relatime,sync,dirsync,rw,trans=virtio,version=9p2000.L)

 Yet, dev-root.device is dead:
 # systemctl status dev-root.device
 ● dev-root.device
Loaded: loaded
Active: inactive (dead)

 Yeah, this /dev/root thing is really weird in the kernel. It's not an
 actual device, it's just a weird string. We probably should filter it
 out entirely, and never ever generate a unit dependency for it.

 Please check if this fixes things for you:

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=7ba2711d3fd283c389db2a1e7b9598ba9f0dac0c


Yeap. All good now, can this go into v219-stable tree as well please?

 That said, I figure you should backport
 628c89cc68ab96fce2de7ebba5933725d147aecc and friends to your tree,
 which should also make this problem go away for you.


I have these via stable tree.

 I am planning to locally patch mount_add_device_links to skip if what
 is /dev/root, to avoid a call to unit_add_node_link... But I'm not
 sure if this is the right thing to do or not.

 It is, it's the change I made now, too.


Ok, cool.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Default to /usr/bin/u?mount, configurable, rather than hard-coded /bin/u?mount.

[Dimitri John Ledkov]

On 13 May 2015 at 14:00, Lennart Poettering lenn...@poettering.net wrote:
 On Mon, 11.05.15 16:58, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 Hmm, all the other AM_PATH_PROG variables do not carry a _BIN suffix,
 should these two? I don't think so.

 (In general, I am not too big a fan of abbreviating things
 unnecessarily, unless this is commonly done elsewhere...)


There is already MOUNT define used elsewhere in the code...
DEFINE_CAST(MOUNT, Mount);

Hence the _BIN suffix.

 Otherwise looks fine,

 Lennart

 ---
  Makefile.am |  2 ++
  configure.ac|  3 +++
  src/core/mount.c|  6 +++---
  src/remount-fs/remount-fs.c | 10 +-
  4 files changed, 13 insertions(+), 8 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index e4d00a8..0ff11cc 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -208,6 +208,8 @@ AM_CPPFLAGS = \
   -DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
   -DQUOTACHECK=\$(QUOTACHECK)\ \
   -DKEXEC=\$(KEXEC)\ \
 + -DMOUNT_BIN=\$(MOUNT_BIN)\ \
 + -DUMOUNT_BIN=\$(UMOUNT_BIN)\ \
   -DLIBDIR=\$(libdir)\ \
   -DROOTLIBDIR=\$(rootlibdir)\ \
   -DROOTLIBEXECDIR=\$(rootlibexecdir)\ \
 diff --git a/configure.ac b/configure.ac
 index 600e203..61dffc6 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -100,6 +100,9 @@ AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], 
 [$PATH:/usr/sbin:/sbin])

  AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
 [$PATH:/usr/sbin:/sbin])

 +AC_PATH_PROG([MOUNT_BIN], [mount], [/usr/bin/mount], 
 [$PATH:/usr/sbin:/sbin])
 +AC_PATH_PROG([UMOUNT_BIN], [umount], [/usr/bin/umount], 
 [$PATH:/usr/sbin:/sbin])
 +
  AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln 
 doesn't support --relative ***])])

  M4_DEFINES=
 diff --git a/src/core/mount.c b/src/core/mount.c
 index 65a66b4..a370c74 100644
 --- a/src/core/mount.c
 +++ b/src/core/mount.c
 @@ -871,7 +871,7 @@ static void mount_enter_unmounting(Mount *m) {
  m-control_command_id = MOUNT_EXEC_UNMOUNT;
  m-control_command = m-exec_command + MOUNT_EXEC_UNMOUNT;

 -r = exec_command_set(m-control_command, /bin/umount, m-where, 
 NULL);
 +r = exec_command_set(m-control_command, UMOUNT_BIN, m-where, 
 NULL);
  if (r = 0  UNIT(m)-manager-running_as == SYSTEMD_SYSTEM)
  r = exec_command_append(m-control_command, -n, NULL);
  if (r  0)
 @@ -924,7 +924,7 @@ static void mount_enter_mounting(Mount *m) {
  if (r  0)
  goto fail;

 -r = exec_command_set(m-control_command, /bin/mount,
 +r = exec_command_set(m-control_command, MOUNT_BIN,
   m-parameters_fragment.what, m-where, 
 NULL);
  if (r = 0  UNIT(m)-manager-running_as == 
 SYSTEMD_SYSTEM)
  r = exec_command_append(m-control_command, -n, 
 NULL);
 @@ -973,7 +973,7 @@ static void mount_enter_remounting(Mount *m) {
  else
  o = remount;

 -r = exec_command_set(m-control_command, /bin/mount,
 +r = exec_command_set(m-control_command, MOUNT_BIN,
   m-parameters_fragment.what, m-where,
   -o, o, NULL);
  if (r = 0  UNIT(m)-manager-running_as == 
 SYSTEMD_SYSTEM)
 diff --git a/src/remount-fs/remount-fs.c b/src/remount-fs/remount-fs.c
 index 70dacfa..ff7de2c 100644
 --- a/src/remount-fs/remount-fs.c
 +++ b/src/remount-fs/remount-fs.c
 @@ -94,15 +94,15 @@ int main(int argc, char *argv[]) {
  const char *arguments[5];
  /* Child */

 -arguments[0] = /bin/mount;
 +arguments[0] = MOUNT_BIN;
  arguments[1] = me-mnt_dir;
  arguments[2] = -o;
  arguments[3] = remount;
  arguments[4] = NULL;

 -execv(/bin/mount, (char **) arguments);
 +execv(MOUNT_BIN, (char **) arguments);

 -log_error_errno(errno, Failed to execute 
 /bin/mount: %m);
 +log_error_errno(errno, Failed to execute  
 MOUNT_BIN : %m);
  _exit(EXIT_FAILURE);
  }

 @@ -142,9 +142,9 @@ int main(int argc, char *argv[]) {
  if (s) {
  if (!is_clean_exit(si.si_code, si.si_status, NULL)) 
 {
  if (si.si_code == CLD_EXITED)
 -log_error(/bin/mount for %s exited 
 with exit status %i., s, si.si_status);
 +log_error(MOUNT_BIN  for %s exited 
 with exit status %i., s, si.si_status);
  else
 -log_error(/bin/mount

[systemd-devel] [PATCH v2] Default to /usr/bin/u?mount, configurable, rather than hard-coded /bin/u?mount.

[Dimitri John Ledkov]

---
 Makefile.am |  2 ++
 configure.ac|  3 +++
 src/core/execute.h  |  2 +-
 src/core/mount.c| 12 ++--
 src/core/mount.h|  4 ++--
 src/remount-fs/remount-fs.c | 10 +-
 6 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e4d00a8..e8a329f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -208,6 +208,8 @@ AM_CPPFLAGS = \
-DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
-DQUOTACHECK=\$(QUOTACHECK)\ \
-DKEXEC=\$(KEXEC)\ \
+   -DMOUNT_PATH=\$(MOUNT_PATH)\ \
+   -DUMOUNT_PATH=\$(UMOUNT_PATH)\ \
-DLIBDIR=\$(libdir)\ \
-DROOTLIBDIR=\$(rootlibdir)\ \
-DROOTLIBEXECDIR=\$(rootlibexecdir)\ \
diff --git a/configure.ac b/configure.ac
index 600e203..70e594d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,6 +100,9 @@ AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], 
[$PATH:/usr/sbin:/sbin])
 
 AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
[$PATH:/usr/sbin:/sbin])
 
+AC_PATH_PROG([MOUNT_PATH], [mount], [/usr/bin/mount], [$PATH:/usr/sbin:/sbin])
+AC_PATH_PROG([UMOUNT_PATH], [umount], [/usr/bin/umount], 
[$PATH:/usr/sbin:/sbin])
+
 AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln doesn't 
support --relative ***])])
 
 M4_DEFINES=
diff --git a/src/core/execute.h b/src/core/execute.h
index a0908e0..f5d5c1d 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -165,7 +165,7 @@ struct ExecContext {
 
 /* This is not exposed to the user but available
  * internally. We need it to make sure that whenever we spawn
- * /bin/mount it is run in the same process group as us so
+ * /usr/bin/mount it is run in the same process group as us so
  * that the autofs logic detects that it belongs to us and we
  * don't enter a trigger loop. */
 bool same_pgrp;
diff --git a/src/core/mount.c b/src/core/mount.c
index 8853311..8ef3d17 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -135,8 +135,8 @@ static void mount_init(Unit *u) {
 m-exec_context.std_error = u-manager-default_std_error;
 }
 
-/* We need to make sure that /bin/mount is always called in
- * the same process group as us, so that the autofs kernel
+/* We need to make sure that /usr/bin/mount is always called
+ * in the same process group as us, so that the autofs kernel
  * side doesn't send us another mount request while we are
  * already trying to comply its last one. */
 m-exec_context.same_pgrp = true;
@@ -833,7 +833,7 @@ static void mount_enter_unmounting(Mount *m) {
 m-control_command_id = MOUNT_EXEC_UNMOUNT;
 m-control_command = m-exec_command + MOUNT_EXEC_UNMOUNT;
 
-r = exec_command_set(m-control_command, /bin/umount, m-where, 
NULL);
+r = exec_command_set(m-control_command, UMOUNT_PATH, m-where, NULL);
 if (r = 0  UNIT(m)-manager-running_as == MANAGER_SYSTEM)
 r = exec_command_append(m-control_command, -n, NULL);
 if (r  0)
@@ -884,7 +884,7 @@ static void mount_enter_mounting(Mount *m) {
 if (r  0)
 goto fail;
 
-r = exec_command_set(m-control_command, /bin/mount,
+r = exec_command_set(m-control_command, MOUNT_PATH,
  m-parameters_fragment.what, m-where, 
NULL);
 if (r = 0  UNIT(m)-manager-running_as == MANAGER_SYSTEM)
 r = exec_command_append(m-control_command, -n, 
NULL);
@@ -931,7 +931,7 @@ static void mount_enter_remounting(Mount *m) {
 else
 o = remount;
 
-r = exec_command_set(m-control_command, /bin/mount,
+r = exec_command_set(m-control_command, MOUNT_PATH,
  m-parameters_fragment.what, m-where,
  -o, o, NULL);
 if (r = 0  UNIT(m)-manager-running_as == MANAGER_SYSTEM)
@@ -1582,7 +1582,7 @@ static int mount_enumerate(Manager *m) {
 
 /* Dispatch this before we dispatch SIGCHLD, so that
  * we always get the events from /proc/self/mountinfo
- * before the SIGCHLD of /bin/mount. */
+ * before the SIGCHLD of /usr/bin/mount. */
 r = sd_event_source_set_priority(m-mount_event_source, -10);
 if (r  0)
 goto fail;
diff --git a/src/core/mount.h b/src/core/mount.h
index a01e6da..280ea0d 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -28,8 +28,8 @@ typedef struct Mount Mount;
 
 typedef enum MountState {
 MOUNT_DEAD,
-MOUNT_MOUNTING,   /* /bin/mount is running, but the mount 
is not done yet. */
-MOUNT_MOUNTING_DONE,  /* /bin/mount is running, and the mount 
is done. */
+

[systemd-devel] [PATCH] Default to /usr/bin/u?mount, configurable, rather than hard-coded /bin/u?mount.

[Dimitri John Ledkov]

---
 Makefile.am |  2 ++
 configure.ac|  3 +++
 src/core/mount.c|  6 +++---
 src/remount-fs/remount-fs.c | 10 +-
 4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e4d00a8..0ff11cc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -208,6 +208,8 @@ AM_CPPFLAGS = \
-DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
-DQUOTACHECK=\$(QUOTACHECK)\ \
-DKEXEC=\$(KEXEC)\ \
+   -DMOUNT_BIN=\$(MOUNT_BIN)\ \
+   -DUMOUNT_BIN=\$(UMOUNT_BIN)\ \
-DLIBDIR=\$(libdir)\ \
-DROOTLIBDIR=\$(rootlibdir)\ \
-DROOTLIBEXECDIR=\$(rootlibexecdir)\ \
diff --git a/configure.ac b/configure.ac
index 600e203..61dffc6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,6 +100,9 @@ AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], 
[$PATH:/usr/sbin:/sbin])
 
 AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
[$PATH:/usr/sbin:/sbin])
 
+AC_PATH_PROG([MOUNT_BIN], [mount], [/usr/bin/mount], [$PATH:/usr/sbin:/sbin])
+AC_PATH_PROG([UMOUNT_BIN], [umount], [/usr/bin/umount], 
[$PATH:/usr/sbin:/sbin])
+
 AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln doesn't 
support --relative ***])])
 
 M4_DEFINES=
diff --git a/src/core/mount.c b/src/core/mount.c
index 65a66b4..a370c74 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -871,7 +871,7 @@ static void mount_enter_unmounting(Mount *m) {
 m-control_command_id = MOUNT_EXEC_UNMOUNT;
 m-control_command = m-exec_command + MOUNT_EXEC_UNMOUNT;
 
-r = exec_command_set(m-control_command, /bin/umount, m-where, 
NULL);
+r = exec_command_set(m-control_command, UMOUNT_BIN, m-where, NULL);
 if (r = 0  UNIT(m)-manager-running_as == SYSTEMD_SYSTEM)
 r = exec_command_append(m-control_command, -n, NULL);
 if (r  0)
@@ -924,7 +924,7 @@ static void mount_enter_mounting(Mount *m) {
 if (r  0)
 goto fail;
 
-r = exec_command_set(m-control_command, /bin/mount,
+r = exec_command_set(m-control_command, MOUNT_BIN,
  m-parameters_fragment.what, m-where, 
NULL);
 if (r = 0  UNIT(m)-manager-running_as == SYSTEMD_SYSTEM)
 r = exec_command_append(m-control_command, -n, 
NULL);
@@ -973,7 +973,7 @@ static void mount_enter_remounting(Mount *m) {
 else
 o = remount;
 
-r = exec_command_set(m-control_command, /bin/mount,
+r = exec_command_set(m-control_command, MOUNT_BIN,
  m-parameters_fragment.what, m-where,
  -o, o, NULL);
 if (r = 0  UNIT(m)-manager-running_as == SYSTEMD_SYSTEM)
diff --git a/src/remount-fs/remount-fs.c b/src/remount-fs/remount-fs.c
index 70dacfa..ff7de2c 100644
--- a/src/remount-fs/remount-fs.c
+++ b/src/remount-fs/remount-fs.c
@@ -94,15 +94,15 @@ int main(int argc, char *argv[]) {
 const char *arguments[5];
 /* Child */
 
-arguments[0] = /bin/mount;
+arguments[0] = MOUNT_BIN;
 arguments[1] = me-mnt_dir;
 arguments[2] = -o;
 arguments[3] = remount;
 arguments[4] = NULL;
 
-execv(/bin/mount, (char **) arguments);
+execv(MOUNT_BIN, (char **) arguments);
 
-log_error_errno(errno, Failed to execute /bin/mount: 
%m);
+log_error_errno(errno, Failed to execute  MOUNT_BIN 
: %m);
 _exit(EXIT_FAILURE);
 }
 
@@ -142,9 +142,9 @@ int main(int argc, char *argv[]) {
 if (s) {
 if (!is_clean_exit(si.si_code, si.si_status, NULL)) {
 if (si.si_code == CLD_EXITED)
-log_error(/bin/mount for %s exited 
with exit status %i., s, si.si_status);
+log_error(MOUNT_BIN  for %s exited 
with exit status %i., s, si.si_status);
 else
-log_error(/bin/mount for %s 
terminated by signal %s., s, signal_to_string(si.si_status));
+log_error(MOUNT_BIN  for %s 
terminated by signal %s., s, signal_to_string(si.si_status));
 
 ret = EXIT_FAILURE;
 }
-- 
2.1.4

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

Re: [systemd-devel] systemd-nspawn and IPv6

[Dimitri John Ledkov]

On 27 April 2015 at 15:01, Lennart Poettering lenn...@poettering.net wrote:
 On Sun, 26.04.15 16:50, Kai Krakow (hurikha...@gmail.com) wrote:

 Hello!

 I've successfully created a Gentoo container on top of a Gentoo host. I can
 start the container with machinectl. I can also login using SSH. So mission
 almost accomblished (it should become a template for easy vserver cloning).

 But from within the IPv6-capable container I cannot access the IPv6 outside
 world. Name resolution via IPv6 fails, as does pinging to IPv6. It looks
 like systemd-nspawn does only setup IPv4 routes to access outside my gateway
 boundary. IPv6 does not work.

 Well, networkd on the host automatically sets up IPv4 masquerading for
 each container. We simply don't do anything equivalent for IPv6
 currently.

 Ideally we wouldn't have to do NAT for IPv6 to make this work, and
 instead would pass on some ipv6 subnet we acquired from uplink without
 NAT to each container, but we currently don't have infrastructure for
 that in networkd, and I am not even sure how this could really work,
 my ipv6-fu is a bit too limited...

 or maybe we should do ipv6 nat after all, under the logic that
 containers are just an implementation detail of the local host rather
 than something to be made visible to the outside world. however code
 for this exists neither.

 Or in other words: ipv6 setup needs some manual networking setup on
 the host.

One should roll the dice and generate unique local address /48 prefix
and use that to setup local addressing, ideally with
autoconfigurations (e.g. derive a fake mac from container uuid and
using the hosts's ULA prefix auto-assign ipv6 address)

For giggles see http://unique-local-ipv6.com/

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn and IPv6

[Dimitri John Ledkov]

On 27 April 2015 at 15:56, Lennart Poettering lenn...@poettering.net wrote:
 On Mon, 27.04.15 15:44, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

  Well, networkd on the host automatically sets up IPv4 masquerading for
  each container. We simply don't do anything equivalent for IPv6
  currently.
 
  Ideally we wouldn't have to do NAT for IPv6 to make this work, and
  instead would pass on some ipv6 subnet we acquired from uplink without
  NAT to each container, but we currently don't have infrastructure for
  that in networkd, and I am not even sure how this could really work,
  my ipv6-fu is a bit too limited...
 
  or maybe we should do ipv6 nat after all, under the logic that
  containers are just an implementation detail of the local host rather
  than something to be made visible to the outside world. however code
  for this exists neither.
 
  Or in other words: ipv6 setup needs some manual networking setup on
  the host.

 One should roll the dice and generate unique local address /48 prefix
 and use that to setup local addressing, ideally with
 autoconfigurations (e.g. derive a fake mac from container uuid and
 using the hosts's ULA prefix auto-assign ipv6 address)

 Well, would that enable automatic, correcting routing between the
 container and the host's external network? That's kinda what this all
 is about...

yes... that is host needs to be assigned a subnet and ip from /48, and
containers routed via that host ip.

Or simply (aka expensively) run radvd on the host for the
containers to do all of that (route  ULA prefix advertisement and
complete auto-configuration therefore)

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device

[Dimitri John Ledkov]

On 24 April 2015 at 10:06, Lennart Poettering lenn...@poettering.net wrote:
 On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:

 On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote:
  On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
 What does this actually do? Is the specified key file read from the
 specified device?
   
It reads keyfile from filesystem on device identifed by 
keyfile_device.
   
  The order of keyfile:device sounds weird, no?
 Shouldn't it be the other way round?

   
keyfile is mandatory, keyfile_device is optional and can be omitted. I
believe dracut looked at all existing devices then. This order makes
it easier to omit optional parameter(s).
  
   Well, whether it is [device:]file or file[:device] is hardly any
   difference for the parser...
 
  Does it really matter?
 
  Well, we might as well implement this in the most obvious way if it is
  not a completely standard feature yet. To me it appears that only one
  initrd supported it, and it lost it a while back without too much
  complaining...
 
  But anyway, I don't mind too much. The
 

 debian's initramfs-tools, but not ubuntu's, support keyfile on
 usb-disk for unlocking luks volumes.

 the exact name of the option and semantics to specify it to
 initramfs-tools is different from dracut's (but that's typical) but
 said equivalent feature does exist in the major other initramfs
 implementation.

 What's the syntax of Debian's initrd for this?

 I mean, if their syntax makes more sense, we might standardise on theirs...


So in debian this is done via keyscript argument in /etc/crypttab, and
there is passdev keyscript provided by the package that is typically
used.
initramfs-tools hooks copy all of those into initramfs.

The passdev is a C binary that takes a single argument -
device:filepath[:timeout]
The binary waits for the device to appear (infinity or up to
optionally specified time-out parameter), mounts it read-only, and
read the filepath to attempt luks unlock for the device specified in
the crypttab.

See docs and sources at:

https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/README.Debian/#L139

https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/passdev.c/

I am indifferent about configuration done via keyscript= parameter in
crypttab, the quality of the passdev implementation. But the
device:filepath[:timeout] argument format is imho a simple 
sensible one for this.

There are a bunch of other keyscript= binaries provided for remote
unlocking over ssh, smartcards, yubikeys and so on, because debian
supports arbitrary things there. A lot of the times people write their
own keyscript by hand for their usecases. =) as usual debian prefers
arbitrary code execution instead of something rigidly declarative ;-)

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Another attempt: Making dependencies properly overridable

[Dimitri John Ledkov]

On 23 April 2015 at 14:58, Christian Seiler christ...@iwakd.de wrote:
 On 04/23/2015 08:36 PM, Lennart Poettering wrote:
 I mean, so far the deps we set are combined from:

   unit file  (1)
 + dropins(2)
 + .wants/ + .requires/ symlinks  (3)
 + automatic deps (4)
 + deps configured in other units (5)

 I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd
 allow unsetting deps configured in (2) from (2) and (3). I'd allow
 unsetting deps made in (3) from (3).

 I would not allow unsetting deps made in (1,2,3) with (4) or (5), or
 vice versa.

 That makes sense, I'll incorporate that.

I like this as well.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device

[Dimitri John Ledkov]

On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote:
 On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote:

What does this actually do? Is the specified key file read from the
specified device?
  
   It reads keyfile from filesystem on device identifed by keyfile_device.
  
 The order of keyfile:device sounds weird, no?
Shouldn't it be the other way round?
   
  
   keyfile is mandatory, keyfile_device is optional and can be omitted. I
   believe dracut looked at all existing devices then. This order makes
   it easier to omit optional parameter(s).
 
  Well, whether it is [device:]file or file[:device] is hardly any
  difference for the parser...

 Does it really matter?

 Well, we might as well implement this in the most obvious way if it is
 not a completely standard feature yet. To me it appears that only one
 initrd supported it, and it lost it a while back without too much
 complaining...

 But anyway, I don't mind too much. The


debian's initramfs-tools, but not ubuntu's, support keyfile on
usb-disk for unlocking luks volumes.

the exact name of the option and semantics to specify it to
initramfs-tools is different from dracut's (but that's typical) but
said equivalent feature does exist in the major other initramfs
implementation.

Is this specific to Dracut so far? Is this widely used, and something
that we really want.
  
   I can say about dracut only but yes, it is used and it is serious
   regression when it is used comparing with pre-systemd version.
 
  Can you point me to documentation about the previous features in this
  regard? Which initrd implementations are you referring to?

 Sure, in dracut manual page:

   crypto LUKS - key on removable device support
rd.luks.key=keypath:keydev:luksdev
keypath is a path to key file to look for. It’s REQUIRED. When
keypath ends with .gpg it’s considered to be key encrypted
symmetrically with GPG. You will be prompted for password on boot.
GPG support comes with crypt-gpg module which needs to be added
explicitly.

 To make this clear: the gpg support is crazy. I don't want to see that
 in systemd at all.

 Also, so far we don't allow luksdev to be specified for any of the
 other options, such as luks.options or so. I am not convinced we
 should support that here.

 I'd be willing to merge a patch that supports basic
 rd.luks.key=keypath:keydev, even though I think it's usecase is
 more security theater than really useful.

 But please put the temporary mount into /run, keep it minimal, define
 a clear trigger to unmount it, no gpg, no luksdev support.

 Lennart

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



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problem with intermediate target

[Dimitri John Ledkov]

On 18 April 2015 at 09:39, Christoph Pleger
christoph.ple...@cs.tu-dortmund.de wrote:
 Hello,

 Why does systemd start this service before /var is mounted, though the
 service should be executed after remote-fs.target, and remote-fs.target
 comes after local-fs.target?


 Because remote-fs.target is not part of initial transaction.

 And why is this different in my intermediate.target than in
 multi-user.target, though intermediate.target defines exactly the same
 requirements, orders and conflicts as multi-user.target?


 Because systemd allows to declare extra dependencies that are not
 directly part of unit definition. E.g. remote-fs.target has
 WantedBy=multi-user.target. It is *not* dependencies listed in unit
 configuration of multi-user.target that make it start remote-fs.target.

 When initial target is multi-user.target all those reverse
 dependencies (for lack of better word) are pulled in and are part of
 initial transaction. With another unit as initial target they are
 skipped.

 Ah, I understand, that makes it clear. The auto-generated pident.service
 file only defines that the service should be executed after
 remote-fs.target, but it does not require it, and because no other service
 or target wants or requires remote-fs.target before pidentd.service
 starts, the filesystems are not yet mounted at that point.

 But then, I think that the way how systemd translates LSB init scripts
 should be changed. This is the LSB part of /etc/init.d/pidentd:

  ### BEGIN INIT INFO
 # Provides:  pidentd-run-dir
 # Required-Start:$remote_fs
 # Required-Stop: $remote_fs
 # Default-Start: S
 # Default-Stop:
 # Short-Description: setup for pidentd
 # Description:   create /var/run/ident for pidentd
 ### END INIT INFO

 As you can see, it defines remote-fs in Required-Start, not in
 Should-Start. In my opinion, this should result in an additional
 Requires=remote-fs.target in pidentd.service.

Early boot sysv scripts are also gone in Ubuntu. That is - they are
masked by native upstart jobs or systemd units.

For this case, why can't you specify RuntimeDirectory=ident to the
whichever unit pidentd is? Either directly in the unit, or as a
/lib/systemd/system/ident.service.d/rundir.conf or some such. And
ditch the sysv init script?

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd and process migration

[Dimitri John Ledkov]

Heya,

On 20 April 2015 at 06:59, Adrian Reber adr...@lisas.de wrote:
 Using CRIU I have been migrating processes from one system to another
 for the last few months (even years). I am now interested in migrating
 processes under systemd's control. Before starting to look how to make
 it work I wanted to know if there has been any discussion if and how
 systemd and CRIU can work together?

 Dumping a process under systemd's control should be no problem.
 After criu has dumped the process (and killed it) systemd should know
 that it does not need to restart the process, but even if the process is
 restarted by systemd it does not hurt the process migration.

 The interesting part happens on the system where the process wants to be
 migrated to. After the process has been dumped and transfered from the
 source system to the destination system it needs to be restarted. So far
 this works with different tested processes (postgresql is my current
 test process). If I want to restore the process as a systemd child
 process I have the problem that the process would have to be re-parented
 to systemd after restarting which is not possible in Linux. Therefore I
 need the help of systemd.

 My plan now would be to transfer the process to the destination
 system and tell systemd I want to restore a process which should be
 under systemd's control after the restore has completed. Therefore
 systemd needs to run criu with the option to restore the new process as
 a criu sibling. Thus systemd would be the correct parent process.

 Is this something which would be useful to integrate into systemd?
 I have some ideas how this could be implemented and how the user
 interfaces could look like. Before going in too much detail I want to
 find out if this is a direction which makes sense.

So systemd has re-exec support. I would go down the route of trying to
serialise the systemd state of the process as well on the orginal
host, and then deserialise it on the target. I haven't done anything
with re-exec serialisation on systemd yet, so no idea how sufficient
that would be to side-load a process like that. It will be fragile.

Going down the route of machinectl api / containers sounds more
interesting. As there is more support for importing those. E.g.
instead of importing a tarball and execing, it, one unfreezes it.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

[Dimitri John Ledkov]

On 11 April 2015 at 13:41, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Fri, Apr 10, 2015 at 03:17:37PM +0300, Tomasz Bursztyka wrote:
 Hi,

 As it has been discussed in the systemd hackfest during the Linux Conference
 Europe, one daemon could centralize the management of all network proxy
 configurations. Idea is something user can do per-application (like in
 firefox for instance) or broader (per-DM like in Gnome), user could do it
 once and for all through such daemon and applications would then request it
 to know whether or not a proxy has to be used and which one.

 As a notice, this is nothing new. Such standalone daemon has been already
 done by the past, pacrunner. systemd-proxy-discoveryd will more or less
 implement the same ideas with improvements. It will get rid of big JS
 engines like spidermonkey or v8 which are overkill for the tiny PAC files
 to be executed on, for instance. From pacrunner experience, APIs will be
 also improved.
 Hi,

 the idea of having centralized proxy config is certainly nice. But the
 PAC files make me shiver. So the first question: is it really necessary
 to support PAC files? Are they widely used in corporate setting or something?
 Is there no saner standard?


Yes.
Yes.
No.

I only wish for system-wide WPAD support and PAC auto-parsing.

The standard started by netscape or some such, hence interpreted
javascript, and nobody came up with something more declarative /
deterministic that catched on.

 If the PAC files must be interpreted, I think this is the hardest
 part.  FindProxyForURL is started for every request, potentially
 hundreds of times per second and more. This means that starting a
 process per invocation is out of the question, and even starting a
 thread per invocation seems to be too much. But each call fall into an
 infinite loop and hang. So the run time of FindProxyForURL should be
 bounded. FindProxyForURL can also resolve names over the network,
 which would best be done asynchronously.


Well pac file is generally cached, and is static it its contents
(possibly many complex clauses if this / if that) but it's ideal to
keep it around for subsequent queries.

 Things in systemd are usually implemented through poll loops, which
 makes it easy to support thousands of concurrent jobs. I'd think
 that this would be the best option here too, with a number of workers
 executing FindProxyForURL()s and stopping when name resolution is
 requested and continuing when the name is resolved.

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



-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about relationship between systemd v219 and kernel version.

[Dimitri John Ledkov]

On 6 April 2015 at 01:12, Lennart Poettering lenn...@poettering.net wrote:
 On Mon, 06.04.15 06:17, 임창근 (ck21...@samsung.com) wrote:

 Hello EveryOne.

 I wonder that If I use kernel v3.4 with systemd v219, systemd-run function 
 is work or not.
 Because My target have kernel v3.4 and systemd v216.

 Please check the README shipped in the tarball, it always lists the
 minimal kernel version systemd requires. For 219 the minimal kernel
 version is 3.7.


I was meant to ask a while back, would it be possible to have degraded
systemd for lower kernels? Quite a few current Android-like phones
will be stuck on 3.4 forever, e.g. those that are shipping SailfishOS
/ Ubuntu for Phones / etc. Thus support for 3.4 is desirable to be
maintained, because of the Android phones.

At the moment this essentially blocks converting all Ubuntu flavours to systemd.

-- 
Regards,

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

Re: [systemd-devel] recent udev dependency change delays plymouth and udev

[Dimitri John Ledkov]

On 2 April 2015 at 00:39, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello all,

 The recent commit
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=d99ce933 (which
 also made it into v219-stable at
 http://cgit.freedesktop.org/systemd/systemd-stable/commit/?h=v219-stableid=b238b0eaf71)
 fixed a typo in udevd's dependencies, which now results in udev
 waiting for systemd-hwdb-update.service.

 While this is certainly correct especially for stateless systems, it
 is quite a bit inconvenient as it now causes a long dependency chain:

 plymouth-start.service → systemd-udevd.service → systemd-hwdb-update.service →
 systemd-remount-fs.service → systemd-fsck-root.service → systemd-fsckd.socket


I dislike building hwdb on boot, thus locally I make sure that update
mechanisms have up to date @udevlibexecdir@/hwdb.bin and thus
systemd-hwdb-update.service is not run.

If triggers rebuild the database, shouldn't the update-process /
conditions be modified such that the database is not rebuild on boot?

-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] fsckd needs to go

[Dimitri John Ledkov]

On 3 April 2015 at 05:58, Lennart Poettering lenn...@poettering.net wrote:
 Heya,

 so we discussed the whole fsckd situation a bit more here in Berlin,
 and we came to the conclusion that fsckd really should not exist the
 way it does in systemd.

 To start with, the code is really wrong, it should never have been
 merged in its current state, the read/write logic for the sockets is
 completely borked (I cannot even boot my own machine reliably with
 it!). And to my knowledge there has been no attempt to fix all of
 that, even though I asked for it. It also doesn't do at all what I
 suggested initially, as the flow of data is now fsck → systemd-fsck →
 systemd-fsckd → plymouth, and that's just crazy, that's two steps too
 many. systemd is supposed to be a few components playing well
 together, but certainly not a baroque network of components where data
 is passed though four hoops before it reaches the destination...

 Then, there's my general reservation with fsckd at all: file systems
 that still require offline fsck are certainly not the future, but we
 develop stuff for the future, and the idea to kill an fsck process
 while it is running is also very very questionnable. There's a reason

Is this about progress  control data or all things fsck?

IMHO we do need to continue support ext4, and running fsck.ext4 when
enforced, at least from initramfs, with progress output to the user
and ability to cancel. Or is even fsck.ext4 obsolete these days and
shouldn't be run automatically any more?

How this is implemented - e.g. inside systemd project or not, is not
relevant, but systemd seems to be a better place for this.

In upstart world, this completely was offloaded to mountall which
directly passed special update messages to plymouthd, which themes
could choose to parse and dispaly / act upon. This however was
ubuntu-specific patch I believe.

The current implementation/integration for systemd-fsck is also
heading to plymouth upstream for generic support there in themes, I
believe.

-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: list-units -r should not fail with older systemd in container

[Dimitri John Ledkov]

On 1 April 2015 at 13:44, Lukáš Nykrýn lnyk...@redhat.com wrote:
 Lennart Poettering píše v Út 31. 03. 2015 v 19:28 +0200:
 On Tue, 31.03.15 16:10, Lukas Nykryn (lnyk...@redhat.com) wrote:

  Older version of systemd does not have d-bus method ListUnitsFiltered,
  so systemctl -r will fail just with:

 I think I'd really prefer if we'd simply fall back to ListUnits() in
 this case, and do the filtering client side only. In fact that's
 probably what we should have done in the first place anyway.

 I figure the patch to make this happen shouldn't be too complex,
 especially given that the original code did just that?

 Lennart

 I am not sure if I understand your suggestion correctly, fall back in
 the case that the machine does not haveListUnitsFiltered or basically
 revert the original patch, which changed that (but leave the new dbus
 method)?

Keep current code path as default, if ListUnitsFiltered is available.

Revert old code path, but make it a fallback code path when
ListUnitsFiltered is not available.

-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Drop systemd-ui

[Dimitri John Ledkov]

On 31 March 2015 at 15:08, Shawn Landden shawnland...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 12:31 AM, Jóhann B. Guðmundsson
 johan...@gmail.com wrote:


 On 03/31/2015 02:30 AM, Shawn Landden wrote:

 On Mon, Mar 30, 2015 at 4:02 PM, Jóhann B. Guðmundsson
 johan...@gmail.com  wrote:

 
 
 On 03/30/2015 10:32 PM, Shawn Landden wrote:

 
 On Mon, Mar 30, 2015 at 1:35 PM, Jóhann B. Guðmundsson
 johan...@gmail.com  wrote:

 
 Heyja
 
 Should this not be dropped and *DE write,integrate/implement an
  graphical
 frontend to systemd for themselves?
 
 It's not like this is receiving the love it needs, hence I'm pretty
  sure
 nobody is using this.

 
 Parts of systemd arn't getting the love they need either, such as
 systemctl show.

 
 
 For systemd ui the *DE communities are better suited to implement,
  integrate
 and maintain an ui on top of systemd for their *DE.

 https://wiki.gnome.org/Apps/Logs

 I see the dbus type problems you are probably getting. Isn't this
 actually a bug in systemd as we are still exporting as systemd1? If we
 are incompatible shouldn't we be systemd2?


 I'm not following, I'm not getting any bugs.


 (systemadm:167530): GLib-GIO-WARNING **: Dropping signal JobNew of
 type (uos) since the type from the expected interface is (uo)

 (systemadm:167530): GLib-GIO-WARNING **: Dropping signal JobRemoved of
 type (uoss) since the type from the expected interface is (uos)


Are the systemd-ui  systemd out of sync on this machine?

Sure the DBus signature of that method was changed in 2012... but
reverting that commit _now_ will induce yet another API break.

Note that imho the current JobNew/JobRemoved signals are imho incomplete -

See:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/026928.html

But it is again too late to break the DBus api again. See comments on
that thread.



 commit 06dab8e18aebf822392c7ca66c5bf3c1200fdec8
 Author: Lennart Poettering lenn...@poettering.net
 Date:   Thu May 3 22:53:25 2012 +0200

 dbus: include unit name in JobNew/JobRemoved signals

 This breaks D-Bus interface slightly, but since the D-Bus API isn't
 covered by the interface stability promise this should be OK.

 diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
 index 6655f29..b5b5113 100644
 --- a/src/core/dbus-manager.c
 +++ b/src/core/dbus-manager.c
 @@ -198,10 +198,12 @@
signal name=\JobNew\\n  \
 arg name=\id\ type=\u\/\n\
 arg name=\job\ type=\o\/\n   \
 +   arg name=\unit\ type=\s\/\n  \
/signal\n \
signal name=\JobRemoved\\n  \
 arg name=\id\ type=\u\/\n\
 arg name=\job\ type=\o\/\n   \
 +   arg name=\unit\ type=\s\/\n  \
 arg name=\result\ type=\s\/\n\
/signal   \
signal name=\StartupFinished\\n \



 As far as I know Kay and Lennart wrote that ui as an proof of concept 4
 years ago, to get people started on writing their own ui not as something
 that should be carried or maintained in longterm in systemd.

 Since then cockpit has emerged as an frontend to systemd as well as
 kcmsystemd for KDE and atleast a journal log parser in Gnome.

 What I'm proposing is that we dropped that proof of concept since it's not
 being maintained, there exist better alternatives thus it's intended purpose
 has been fulfilled already.

 JBG



 --
 Liberty equality fraternity or death,

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



-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel