Re: [systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

Way to go Luca! Thank you for informing. We still have great interest in 
portable services. 

On 2022-01-23, 4:45 PM, "Luca Boccassi"  wrote:

FYI, support for using directories with --extension has just been
merged in main and will be available in v251.

On Wed, 20 Oct 2021 at 16:15, Luca Boccassi  wrote:
>
> No, it's only supported for images at the moment, as the documentation
> says:
>
>--extension=PATH
>Add an additional image PATH as an overlay on top of IMAGE
> when attaching/detaching. This argument can
>be specified multiple times, in which case the order in
> which images are laid down follows the rules
>specified in systemd.exec(5) for the ExtensionImages=
> directive. The image(s) must contain an
>extension-release file with metadata that matches what is
> defined in the os-release of IMAGE. See: os-
>release(5).
>
> The internal implementation of extensions is ExtensionImage= which as
> the name says, it's for binary images. There's no ExtensionDirectory=
> yet - no reason it can't there be one, just someone needs to implement
> it. PRs welcome!
    >
> On Wed, 2021-10-20 at 17:04 +0200, Umut Tezduyar Lindskog wrote:
> > It indeed worked as squashfs image. Thanks for that.
> >
> > It is not working as a folder though (portablectl --runtime attach --
> > extension=./stackupper ./base stackupper) This stuff should work on
> > folders too right? Should I open a ticket?
> >
> > Also, when it works, the upper stack shows as detached. Isn't that
> > wrong too? Should I open a ticket?
> >
> > root@osboxes:/home/osboxes/Development# portablectl attach --runtime
> > --extension $PWD/stackupper.raw $PWD/base.raw stackupper
> > (Matching unit files with prefixes 'stackupper'.)
> > Created directory /run/systemd/system.attached.
> > Created directory /run/systemd/system.attached/stackupper.service.d.
> > Written /run/systemd/system.attached/stackupper.service.d/20-
> > portable.conf.
> > Created symlink /run/systemd/system.attached/stackupper.service.d/10-
> > profile.conf →
> > /usr/lib/systemd/portable/profile/default/service.conf.
> > Copied /run/systemd/system.attached/stackupper.service.
> > Created symlink /run/portables/stackupper.raw →
> > /home/osboxes/Development/stackupper.raw.
> > Created symlink /run/portables/base.raw →
> > /home/osboxes/Development/base.raw.
> > root@osboxes:/home/osboxes/Development# portablectl list
> > NAME   TYPE RO CRTIME  MTIME
> >   USAGE  STATE
> > base   raw  no Wed 2021-10-20 10:54:41 EDT Wed 2021-10-20
> > 10:54:41 EDT 920.0K attached-runtime
> > stackupper raw  no Wed 2021-10-20 10:54:57 EDT Wed 2021-10-20
> > 10:54:57 EDT 36.0K  detached
> >
> >
> > Thanks again
> > Umut
> >
> > On Wed, Oct 20, 2021 at 12:01 AM Luca Boccassi 
> > wrote:
> > > On Tue, 2021-10-19 at 16:09 +0200, Umut Tezduyar Lindskog wrote:
> > > > Hi Luca, have you had time to help me out or do you think you
> > > could
> > > > help me
> > > > out? Thanks in advance.
> > >
> > > Works fine for me with systemd 249.5:
> > >
> > > $ tar xf ~/Downloads/portable.tar
> > > $ mksquashfs base/ base.raw
> > > Parallel mksquashfs: Using 4 processors
> > > Creating 4.0 filesystem on base.raw, block size 131072.
> > > [==
> > > =|] 23/23 100%
> > >
> > > Exportable Squashfs 4.0 filesystem, gzip compressed, data block
> > > size 131072
> > > compressed data, compressed metadata, compressed fragments,
> > > compressed xattrs, compressed ids
> > > duplicates are removed
> > > Filesystem size 918.80 Kbytes (0.90 Mbytes)
> > > 39.83% of uncompressed filesystem size (2306.95 Kbytes)
> > > Inode table size 359 bytes (0.35 Kbytes)
> > > 35.69% of uncompressed inode table size (1006 bytes)
> > > Directory table size 319 bytes (0.31 Kbytes)
> > > 62.80% of uncompressed directory table size (508 bytes)
> > > Number of duplicate files found 3
> > > Number of inodes 

Re: [systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

It indeed worked as squashfs image. Thanks for that.

It is not working as a folder though (portablectl --runtime attach
--extension=./stackupper ./base stackupper) This stuff should work on
folders too right? Should I open a ticket?

Also, when it works, the upper stack shows as detached. Isn't that wrong
too? Should I open a ticket?

root@osboxes:/home/osboxes/Development# portablectl attach --runtime
--extension $PWD/stackupper.raw $PWD/base.raw stackupper
(Matching unit files with prefixes 'stackupper'.)
Created directory /run/systemd/system.attached.
Created directory /run/systemd/system.attached/stackupper.service.d.
Written /run/systemd/system.attached/stackupper.service.d/20-portable.conf.
Created symlink
/run/systemd/system.attached/stackupper.service.d/10-profile.conf →
/usr/lib/systemd/portable/profile/default/service.conf.
Copied /run/systemd/system.attached/stackupper.service.
Created symlink /run/portables/stackupper.raw →
/home/osboxes/Development/stackupper.raw.
Created symlink /run/portables/base.raw →
/home/osboxes/Development/base.raw.
root@osboxes:/home/osboxes/Development# portablectl list
NAME   TYPE RO CRTIME  MTIME
USAGE  STATE
base   raw  no Wed 2021-10-20 10:54:41 EDT Wed 2021-10-20 10:54:41 EDT
920.0K attached-runtime
stackupper raw  no Wed 2021-10-20 10:54:57 EDT Wed 2021-10-20 10:54:57 EDT
36.0K  detached


Thanks again
Umut

On Wed, Oct 20, 2021 at 12:01 AM Luca Boccassi  wrote:

> On Tue, 2021-10-19 at 16:09 +0200, Umut Tezduyar Lindskog wrote:
> > Hi Luca, have you had time to help me out or do you think you could
> > help me
> > out? Thanks in advance.
>
> Works fine for me with systemd 249.5:
>
> $ tar xf ~/Downloads/portable.tar
> $ mksquashfs base/ base.raw
> Parallel mksquashfs: Using 4 processors
> Creating 4.0 filesystem on base.raw, block size 131072.
> [===|]
> 23/23 100%
>
> Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
> compressed data, compressed metadata, compressed fragments,
> compressed xattrs, compressed ids
> duplicates are removed
> Filesystem size 918.80 Kbytes (0.90 Mbytes)
> 39.83% of uncompressed filesystem size (2306.95 Kbytes)
> Inode table size 359 bytes (0.35 Kbytes)
> 35.69% of uncompressed inode table size (1006 bytes)
> Directory table size 319 bytes (0.31 Kbytes)
> 62.80% of uncompressed directory table size (508 bytes)
> Number of duplicate files found 3
> Number of inodes 29
> Number of files 9
> Number of fragments 2
> Number of symbolic links 0
> Number of device nodes 0
> Number of fifo nodes 0
> Number of socket nodes 0
> Number of directories 20
> Number of ids (unique uids + gids) 1
> Number of uids 1
> luca (1000)
> Number of gids 1
> luca (1000)
> $ mksquashfs stackupper/ stackupper.raw
> Parallel mksquashfs: Using 4 processors
> Creating 4.0 filesystem on stackupper.raw, block size 131072.
> [=|]
> 3/3 100%
>
> Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
> compressed data, compressed metadata, compressed fragments,
> compressed xattrs, compressed ids
> duplicates are removed
> Filesystem size 33.94 Kbytes (0.03 Mbytes)
> 41.81% of uncompressed filesystem size (81.18 Kbytes)
> Inode table size 269 bytes (0.26 Kbytes)
> 34.98% of uncompressed inode table size (769 bytes)
> Directory table size 261 bytes (0.25 Kbytes)
> 58.78% of uncompressed directory table size (444 bytes)
> Number of duplicate files found 2
> Number of inodes 24
> Number of files 5
> Number of fragments 1
> Number of symbolic links 1
> Number of device nodes 0
> Number of fifo nodes 0
> Number of socket nodes 0
> Number of directories 18
> Number of ids (unique uids + gids) 1
> Number of uids 1
> luca (1000)
> Number of gids 1
> luca (1000)
> $ sudo portablectl attach --runtime --extension $PWD/stackupper.raw
> $PWD/base.raw stackupper
> (Matching unit files with prefixes 'stackupper'.)
> Created directory /run/systemd/system.attached.
> Created directory /run/systemd/system.attached/stackupper.service.d.
> Written /run/systemd/system.attached/stackupper.service.d/20-portable.conf.
> Created symlink
> /run/systemd/system.attached/stackupper.service.d/10-profile.conf →
> /usr/lib/systemd/portable/profile/default/service.conf.
> Copied /run/systemd/system.attached/stackupper.service.
> Created symlink /run/portables/stackupper.raw →
> /tmp/portable/stackupper.raw.
> Created symlink /run/portables

Re: [systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

Hi Luca, have you had time to help me out or do you think you could help me
out? Thanks in advance.

On Mon, Oct 18, 2021 at 12:56 PM Umut Tezduyar Lindskog 
wrote:

> Hi again. I tried renaming (
> https://www.freedesktop.org/software/systemd/man/os-release.html) it but
> that didn't work. I am not getting any errors during the attachment phase
> so I am not sure if the failure is due to extension file in any way.
>
> A wish list is to be more verbose regarding what is going on during
> extension file check/comparison and during overlaying /usr and /opt. I
> think portablectl is quite verbose when it comes to preparing files, symb
> links and what I wish fits well.
>
> Could you please try it yourself? I put them in
> https://drive.google.com/file/d/1LoN_swR7jgvo5yxajWjYK5ck_e8kJs1W/view?usp=sharing
> there should be a download button on the top right. Appreciate your help.
>
> Thanks,
> Umut
>
>
> On Fri, Oct 15, 2021 at 3:46 PM Luca Boccassi  wrote:
>
>> On Fri, 2021-10-15 at 14:59 +0200, Umut Tezduyar Lindskog wrote:
>> > Thanks and I would have never figured it out without your help.
>> > However, moving the binary to /opt didn't work either (I made sure
>> > there is empty /opt in the base too). Anything else I am missing?
>> >
>> > root@osboxes:/home/osboxes/Development# tree stackupper/
>> > stackupper/
>> > ├── bin
>> > │   └── umut
>> > ├── dev
>> > ├── etc
>> > │   ├── machine-id
>> > │   ├── resolv.conf
>> > │   └── runtime
>> > ├── lib -> usr/lib
>> > ├── opt
>> > │   └── tree
>> > ├── proc
>> > ├── root
>> > ├── run
>> > ├── sys
>> > ├── tmp
>> > ├── usr
>> > │   ├── bin
>> > │   └── lib
>> > │   ├── extension-release.d
>> > │   │   └── extension-release.base
>> > │   └── systemd
>> > │   └── system
>> > │   └── stackupper.service
>> > └── var
>> > └── tmp
>> >
>> > 18 directories, 7 files
>> > root@osboxes:/home/osboxes/Development# cat
>> > stackupper/usr/lib/systemd/system/stackupper.service
>> > [Service]
>> > Type=oneshot
>> > ExecStart=/opt/tree /
>>
>> The extension-release file in the extension must be named exactly after
>> the extension (eg: foo.raw must contain /usr/lib/extension-
>> release.d/extension-release.foo), but in your case it's called ".base"
>> which doesn't seem right, so double check that. This too is documented
>> in the man page.
>>
>> > On Fri, Oct 15, 2021 at 2:23 PM Luca Boccassi 
>> > wrote:
>> > > On Fri, 2021-10-15 at 12:18 +, Umut Tezduyar Lindskog wrote:
>> > > > Hi, following works for us (for reference, configuration is
>> > > printed
>> > > > at the end)
>> > > >
>> > > > portablectl --now attach --extension=./stackupper ./base
>> > > stackupper
>> > > >
>> > > > However, if we move the cat from base/usr/bin/cat to
>> > > > stackupper/bin/cat it is not working. Seems like we cannot
>> > > include
>> > > > any library/executable in the extension.
>> > > >
>> > > > Are we missing something?
>> > > >
>> > > >
>> > > > root@osboxes:/home/osboxes/Development# tree base/
>> > > > base/
>> > > > ├──bin
>> > > > ├──dev
>> > > > ├──etc
>> > > > │   ├── machine-id
>> > > > │   ├── os-release
>> > > > │   └── resolv.conf
>> > > > ├──lib
>> > > > │   └── x86_64-linux-gnu
>> > > > │   └── libc.so.6
>> > > > ├──lib64
>> > > > │   ├──ld-2.32.so
>> > > > │   └── ld-linux-x86-64.so.2
>> > > > ├──proc
>> > > > ├──root
>> > > > ├──run
>> > > > ├──sys
>> > > > ├──tmp
>> > > > ├──usr
>> > > > │   ├──bin
>> > > > │   │   ├──cat
>> > > > │   │   ├──echo
>> > > > │   │   └── tree
>> > > > │   └── lib
>> > > > │   └── systemd
>> > > > │   └── system
>> > > > └── var
>> > > > └── tmp
>> > > >
>> > > > 18 directories, 9 files
>> > > >
>> > > > root@osboxes:/home/osboxes/Development# tree stackupper/
>> > > > stackuppe

Re: [systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

Thanks and I would have never figured it out without your help. However,
moving the binary to /opt didn't work either (I made sure there is empty
/opt in the base too). Anything else I am missing?

root@osboxes:/home/osboxes/Development# tree stackupper/
stackupper/
├── bin
│   └── umut
├── dev
├── etc
│   ├── machine-id
│   ├── resolv.conf
│   └── runtime
├── lib -> usr/lib
├── opt
│   └── tree
├── proc
├── root
├── run
├── sys
├── tmp
├── usr
│   ├── bin
│   └── lib
│   ├── extension-release.d
│   │   └── extension-release.base
│   └── systemd
│   └── system
│   └── stackupper.service
└── var
└── tmp

18 directories, 7 files
root@osboxes:/home/osboxes/Development# cat
stackupper/usr/lib/systemd/system/stackupper.service
[Service]
Type=oneshot
ExecStart=/opt/tree /

On Fri, Oct 15, 2021 at 2:23 PM Luca Boccassi  wrote:

> On Fri, 2021-10-15 at 12:18 +, Umut Tezduyar Lindskog wrote:
> > Hi, following works for us (for reference, configuration is printed
> > at the end)
> >
> > portablectl --now attach --extension=./stackupper ./base stackupper
> >
> > However, if we move the cat from base/usr/bin/cat to
> > stackupper/bin/cat it is not working. Seems like we cannot include
> > any library/executable in the extension.
> >
> > Are we missing something?
> >
> >
> > root@osboxes:/home/osboxes/Development# tree base/
> > base/
> > ├──bin
> > ├──dev
> > ├──etc
> > │   ├── machine-id
> > │   ├── os-release
> > │   └── resolv.conf
> > ├──lib
> > │   └── x86_64-linux-gnu
> > │   └── libc.so.6
> > ├──lib64
> > │   ├──ld-2.32.so
> > │   └── ld-linux-x86-64.so.2
> > ├──proc
> > ├──root
> > ├──run
> > ├──sys
> > ├──tmp
> > ├──usr
> > │   ├──bin
> > │   │   ├──cat
> > │   │   ├──echo
> > │   │   └── tree
> > │   └── lib
> > │   └── systemd
> > │   └── system
> > └── var
> > └── tmp
> >
> > 18 directories, 9 files
> >
> > root@osboxes:/home/osboxes/Development# tree stackupper/
> > stackupper/
> > ├──bin
> > │   └── umut
> > ├──dev
> > ├──etc
> > │   ├── machine-id
> > │   ├── resolv.conf
> > │   └── runtime
> > ├──lib -> usr/lib
> > ├──proc
> > ├──root
> > ├──run
> > ├──sys
> > ├──tmp
> > ├──usr
> > │   ├──bin
> > │   └── lib
> > │   ├──extension-release.d
> > │   │   └── extension-release.base
> > │   └── systemd
> > │   └── system
> > │   └── stackupper.service
> > └── var
> > └── tmp
> >
> > 17 directories, 6 files
> >
> > root@osboxes:/home/osboxes/Development# cat
> > stackupper/usr/lib/systemd/system/stackupper.service
> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/cat /etc/os-release
> > root@osboxes:/home/osboxes/Development#systemctl --version
> > systemd 249 (249.4-1)
> > +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -
> > OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD
> > +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2
> > +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-
> > hierarchy=unified
>
> Hi,
>
> You need to build your extension with the binaries under either the
> /usr or /opt hierarchies. Legacy locations like /bin and /lib are
> ignored. This is explained in the systemd-sysext.8 manpage.
>
> --
> Kind regards,
> Luca Boccassi
>

[systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

Hi, following works for us (for reference, configuration is printed at the end)

portablectl --now attach --extension=./stackupper ./base stackupper

However, if we move the cat from base/usr/bin/cat to stackupper/bin/cat it is 
not working. Seems like we cannot include any library/executable in the 
extension.

Are we missing something?


root@osboxes:/home/osboxes/Development# tree base/
base/
├── bin
├── dev
├── etc
│   ├── machine-id
│   ├── os-release
│   └── resolv.conf
├── lib
│   └── x86_64-linux-gnu
│   └── libc.so.6
├── lib64
│   ├── ld-2.32.so
│   └── ld-linux-x86-64.so.2
├── proc
├── root
├── run
├── sys
├── tmp
├── usr
│   ├── bin
│   │   ├── cat
│   │   ├── echo
│   │   └── tree
│   └── lib
│   └── systemd
│   └── system
└── var
└── tmp

18 directories, 9 files

root@osboxes:/home/osboxes/Development# tree stackupper/
stackupper/
├── bin
│   └── umut
├── dev
├── etc
│   ├── machine-id
│   ├── resolv.conf
│   └── runtime
├── lib -> usr/lib
├── proc
├── root
├── run
├── sys
├── tmp
├── usr
│   ├── bin
│   └── lib
│   ├── extension-release.d
│   │   └── extension-release.base
│   └── systemd
│   └── system
│   └── stackupper.service
└── var
└── tmp

17 directories, 6 files

root@osboxes:/home/osboxes/Development# cat 
stackupper/usr/lib/systemd/system/stackupper.service
[Service]
Type=oneshot
ExecStart=/usr/bin/cat /etc/os-release
root@osboxes:/home/osboxes/Development# systemctl --version
systemd 249 (249.4-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL 
+ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP 
-LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD 
-XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

[systemd-devel] loose thoughts around portable services

[Umut Tezduyar Lindskog]

Hi, we have been playing around more with the portable services and lots of 
loose thoughts came up. Hopefully we can initiate discussions.

The PrivateUsers and DynamicUsers are turned off for the trusted profile in 
portable services but none of the passwd/group and nss files are mapped to the 
sandbox by default essentially preventing the sandbox to do a user look up. Is 
this a use case that should be offered by the “trusted” profile or should this 
be handled by the services that would like to do a look-up?

Is there a way to have PrivateUsers=yes and map more host users to the sandbox? 
We have dynamic, uid based authorization on dbus methods. Up on receiving a 
method, the server checks the sender uid against a set of rule files.

Would it benefit others if the “profile” support was moved out of the portable 
services and be part of the unit files? For example part of the [Install] 
section.

Has there been any thought about nesting profiles? Example, one profile can 
include other profiles in it.

Systemd analyze security is great! We believe it would be easier to audit if we 
had a way to compare a service file’s sandboxing directives against a profile 
and find the delta. Then score the service file against delta.

Thank you for your comments
Umut

Re: [systemd-devel] Pre-installed portable services ?

[Umut Tezduyar Lindskog]

Hi,

On 2021-09-20, 5:19 PM, "Lennart Poettering"  wrote:

On Mo, 20.09.21 11:24, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) 
wrote:

> Hi. Is there such thing as “pre-installed” portable services? If
> not, what is the best way to achieve it. One option can be to place
> the files that “attach” command creates on the distro but I am
> worried that the files might be outdated depending on the systemd
> version the distro is shipped.

What do you mean by "pre-installed" precisely?

I mean, portable services can be dropped into /usr/lib/portables/,
i.e. a dir that typically is included in the base OS image? (As
opposed to /var/lib/portables/, where they are usually dropped, given
they should be able to be added anytime).

Or do you mean that they are also "pre-attached" and "pre-enabled"? If
you want that you could either call "portablectl attach" at boot, or
just package the symlinks/files the call creates.

This. 

Seems like 20-portable.conf is created not symbol linked. If we package the 
files ourself, then we need to make sure they are up to date as new versions of 
systemd might tweak them. I guess. 

We could also add some special dirs that may contain images we'll
automatically attach + enable during boot as we discover them. That'd
be a new feature though.

Cool! If the feature is not there by the time we put our hands on portable 
services, we would send a patch upstream. 

Thanks for your feedback. 

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] Pre-installed portable services ?

[Umut Tezduyar Lindskog]

Hi. Is there such thing as “pre-installed” portable services? If not, what is 
the best way to achieve it. One option can be to place the files that “attach” 
command creates on the distro but I am worried that the files might be outdated 
depending on the systemd version the distro is shipped.

Thanks for the answer,
Umut

Re: [systemd-devel] Portable services

[Umut Tezduyar Lindskog]

On 2021-09-14, 3:43 PM, "Lennart Poettering"  wrote:

On Di, 14.09.21 12:10, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) 
wrote:

> Hello,
>
> We, at Axis, have a monolithic operating system backed by a
> platform. There are teams behind the services making up the
> operating system and we have quite many services. We have been
> investigating sandboxing these services and of course systemd
> sandboxing directives are a way to go. Problem is that it is not
> realistic for us to expect teams to be on top of the directives and
> apply the right ones they need (and keep them updated). There shines
> the portable services for us with it’s “profiles”. We are trying to
> sandbox these services while giving them some host access. There
> shined for example how the default profile is set up by giving dbus
> access (binding dbus system socket to a portable service). We would
> like to create a base runtime and expect services to use the base
> runtime, still giving them the option of overriding the
> runtime. There shined the stackable services with latest “extension”
> support. All and all it fits our use case very well.
>
> I am aware that portable services is still enhancing but who out
> there is using it and I am curious about their use case. (Sorry,
> couldn’t wait for spring in Berlin).

The commit history to that dir might give you hint which companies use
it:

Thanks for the suggestion. 

https://github.com/systemd/systemd/commits/main/src/portable

But of course, that's only the ones which use it *and* contribute to
it. I am pretty sure there are others which use it, but don't
contribute.

> Seems like DynamicUsers is part of the default profile and
> DynamicUsers is a good thing. Seems like systemd creates a username
> as the same name as the portable service. Does it work with username
> based dbus policies? Is it that we need to be very careful regarding
> who can start a portable service in case they re-use service name to
> go around dbus rules (vs who can edit /etc/passwd).

So, providing D-Bus services from DynamicUser= services is messy. The two
D-Bus brokers out there want to resolve user names at the time they
load policy, and that of course conflicts with the DynamicUser=
concept to some level, since loading policy happens at early boot but
the whole point of DynamicUser= is that these users only appear the
moment the service starts.

The opposite, i.e. connecting as a client to D-Bus services from
DynamicUser= should be OK (it just means you need to be able to
connect to the D-Bus system socket from the service, i.e. you need to
bind mount that socket) — as long as your client is just a regular
client, i.e. doesn't need specific broker-side policy. Thankfully
clients that require installation of specific D-Bus policies is the
exception.

D-Bus progress is currently a bit stuck. Ideally D-Bus maintainers
would provide us with a way how we could marry socket activation and
D-Bus a bit (in the sense, that systemd passes a pre-connected D-Bus
socket to services, for example, and also uploads policy at that
moment). But I wouldn't hold my breath this happens anytime soon.

Sounds like a good idea. 

Note that portable services and system extensions are two different
things.

Sorry for misusing the term. I have meant "portablectl --extension" option. 

Regarding system extensions: at RH we are working on using them as a
way to build fully trusted initrds at the moment. background: it's
currently a major shortcoming of generic Linux distros that initrds
are entirely unprotected cryptographically, anyone can modify them at
will without this being detectable, making FDE pretty weak
conceptually; SecureBoot only covers the kernel, but once the initrd
is run all safety is off. I recently pushed a PR that adds embedded
offline-safe PKCS#7 signature support to the disk image logic that
system extensions and portable services build on (and nspawn, …). With
that you get really nice security properties, as we reinvent initrds
in secure, trusted way: the basic initrd is now built into the kernel
(and thus validated along with it), and exotic storage is then added
in via trusted, verifiable system extensions.

Interesting to hear. Thanks for your feedback and looking forward to hear from 
others. 

Umut

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] Portable services

[Umut Tezduyar Lindskog]

Hello,

We, at Axis, have a monolithic operating system backed by a platform. There are 
teams behind the services making up the operating system and we have quite many 
services. We have been investigating sandboxing these services and of course 
systemd sandboxing directives are a way to go. Problem is that it is not 
realistic for us to expect teams to be on top of the directives and apply the 
right ones they need (and keep them updated). There shines the portable 
services for us with it’s “profiles”. We are trying to sandbox these services 
while giving them some host access. There shined for example how the default 
profile is set up by giving dbus access (binding dbus system socket to a 
portable service). We would like to create a base runtime and expect services 
to use the base runtime, still giving them the option of overriding the 
runtime. There shined the stackable services with latest “extension” support. 
All and all it fits our use case very well.

I am aware that portable services is still enhancing but who out there is using 
it and I am curious about their use case. (Sorry, couldn’t wait for spring in 
Berlin).

Seems like DynamicUsers is part of the default profile and DynamicUsers is a 
good thing. Seems like systemd creates a username as the same name as the 
portable service. Does it work with username based dbus policies? Is it that we 
need to be very careful regarding who can start a portable service in case they 
re-use service name to go around dbus rules (vs who can edit /etc/passwd).

Thanks in advance
Umut

Re: [systemd-devel] Antw: [EXT] Re: Adding USB ID to hwdb/usb.ids

[Umut Tezduyar Lindskog]

On Fri, Jun 4, 2021 at 7:49 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Greg KH  schrieb am 02.06.2021 um 16:39 in
> Nachricht :
> > On Wed, Jun 02, 2021 at 03:48:41PM +0200, Reindl Harald wrote:
> >>
> >>
> >> Am 02.06.21 um 07:04 schrieb Greg KH:
> >> > On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:
> >> > > Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH
> >:
> >> > > > Works for me!  Make sure you are not trying to connect to 'https'.
> >> > >
> >> > > No https? Why?
> >> >
> >> > Because why would serving up text files about this topic requires
> https?
> >>
> >> sorry, but we have 2021
> >>
> >> * non‑https is a warning in most browsers
> >> * certifictes are free and automated these days
> >> * https is not only about encryption
> >>
> >> the point of https is
> >>
> >> a) you are connected to the host you think
> >> b) no manipulation on the wire
> >>
> >> the encryption is not really the point
> >
> > Then don't connect to the site if you don't want the data there.  Trying
> > to tell others what to do with their spare time in maintaining a
> > resource for all operating systems to use is a bit, well, you know...
>
> I think any website that has a form to fill in should offer https.
> In the past there were websites asking for user and password without
> offering
> https.
> I also think even a self-signed certificate is better tan no certificate at
> all, but in the times of let'S encrypt setting up https shouldn't be a big
> issue.
>
> All my opinion...
>
> Regards,
> Ulrich
>

If I am not misinterpreting, Mr. Biden's recent cyber security execute
order [1] will put a weight on how data is transferred, at least in the US,
at least for the agencies which will probably ripple itself to the ordinary
user eventually.

[1]
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
Multiple mentions of "*encryption for data at rest and in transit*".

Umut


>
> >
> > greg "i am a horrible sysadmin" k‑h
> > ___
> > systemd‑devel mailing list
> > systemd‑de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: Moving fully to OpenSSL (aka. stopping support for gnutls/gcrypt)?

[Umut Tezduyar Lindskog]

Hi. Really good initiative!

Also wanted to inform about connectedhomeip project which has an
abstraction layer for OpenSSL and Mbed TLS. Probably the layer is far from
being ready for systemd to use though.

Umut

On Wed, Dec 9, 2020 at 10:51 AM Lennart Poettering 
wrote:

> Heya!
>
> Currently, some parts of the systemd tree link against OpenSSL, others
> link against gnutls and libgcrypt, and even others support either,
> controlled by a compile time switch.
>
> This is of course less than ideal, since it means we need to maintain
> needlessly complex, redundant code to support this, it's not complete
> (as not all combinations are supported), and footprint for general
> purpose distros is effectively doubled.
>
> I think we should go OpenSSL all the way, and replace/drop support for
> gnutls and libgcrypt, unifying on a single crypto library. This was
> previously problematic since on Debian linking LGPL code against
> OpenSSL was considered legally "unclean". This has recently changed
> though:
>
> https://github.com/systemd/systemd/pull/14743#issuecomment-739001595
>
> Hence, given that the legal issues around going OpenSSL exclusively
> all the way are gone, I think it's time to do the full switch. Hence
> I'd like to propose that we start transitioning with depending only on
> OpenSSL sooner or later. This means:
>
> 1. Porting the currently remaining GnuTLS/gcrypt-only code over to openssl
>
> 2. Dropping redundant implementations for gnutls/gcrypt where we
>already have openssl support
>
> 3. Require for new code to be openssl-only.
>
> Ultimately this should provide us with a smaller codebase, smaller OS
> footprint and easier maintainance.
>
> Before we make this decision and switch over I'd like to hear opinions
> on this, though. Maybe I am missing something, and there are other
> reasons why people want to keep gnutls/gcrypt support around?
>
> Why unify on OpenSSL instead of doing it the other way and unify on
> gnutls + gcrypt, btw? We don't really have any horse in that race. All
> crypto libraries have well documented issues, like any code. It
> appears to me though that OpenSSL has the more active and larger
> community and wider industry support. It appears to me that dropping
> gntuls/gcrypt frrom the basic OS package set is easier to reach then
> dropping OpenSSL. In the interest of making the minimal set of OS
> packages required to boot a system smaller I think OpenSSL is the
> better choice.
>
> The fabled future OpenSSL 3 release is supposed to come with a changed
> license, which will attack the Debian license incompatibility from
> another angle btw. It was supposed to be released many months ago
> already, afaiu, but that unfortunately never happened. So far we were
> counting on this to resolve the licensing situation around crypto
> libraries. Due to the Debian change I figure we can speed up things
> now, though.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Grouping services in systemd..

[Umut Tezduyar Lindskog]

We had a similar problem and we solved it by using grouping for critical
services and then using startup cpu shares for services that should be
responsive within that group.

Even if you use startup cpu shares and create a target for everything you
would want to boot, some unnecessary services will get the CPU due to CFS.
Them getting CPU is by itself a problem, also they would cause a context
switch with memory caches being flushed. To avoid this, we have created a
target for our critical services and their dependencies. We had yet another
service inside this critical group which told systemd to kick off
multi-user.target when critical services were up.

We didn't use startup IO shares because we are based on ubifs which back
then didn't have IO scheduler support.

Hope it gives some inspiration.
Umut

On Thu, Apr 2, 2020 at 3:21 PM nitish nagesh 
wrote:

> Hi folks,
>
>   We are working on an embedded ARM Cortex A9 based system (aka low CPU).
> It runs on a custom linux based operating system which uses systemd.
>
>   We have a bunch of daemons (around ~50+) that come up during boot
> simultaneously which slows down the boot significantly as the CPU runs out
> of breath. We were thinking of staggering these daemons into 2 groups. The
> first group containing "critical" daemons (around 15) so that they finish
> faster and make the system usable sooner. Followed by the second group of
> daemons.
>
>Separating daemons into buckets could be done using:
> 1) systemd targets: Introduce 2 new targets and classify the
> services/daemons into them. Layer these targets during boot.
> 2) Cgroups: Create a new systemd slice and put all the "critical" services
> into it. Allocate sufficient CPUShares value to the slice so that this
> slice gets its due CPU% to finish faster boot.
>
> Can you please suggest which of the above is a better approach? Respective
> pros/cons with each.
>
> Or if there is a third approach better than the above?
>
> Thanks in advance,
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is the watchdog useful?

[Umut Tezduyar Lindskog]

I am curious Zbigniew of how you find out if the coredump was on a starved
process?

This is common for our embedded devices. I didn't think it is common for
desktop too.

It is really useful for getting coredumps on deadlocked applications. For
that reason I don't think it is good to remove this functionality
completely.

Umut

On Mon, Oct 21, 2019 at 7:51 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> In principle, the watchdog for services is nice. But in practice it seems
> be bring only grief. The Fedora bugtracker is full of automated reports of
> ABRTs,
> and of those that were fired by the watchdog, pretty much 100% are bogus,
> in
> the sense that the machine was resource starved and the watchdog fired.
>
> There a few downsides to the watchdog killing the service:
> 1. if it is something like logind, it is possible that it will cause
> user-visible
> failure of other services
> 2. restarting of the service causes additional load on the machine
> 3. coredump handling causes additional load on the machine, quite
> significant
> 4. those failures are reported in bugtrackers and waste everyone's time.
>
> I had the following ideas:
> 1. disable coredumps for watchdog abrts: systemd could set some flag
> on the unit or otherwise notify systemd-coredump about this, and it could
> just
> log the occurence but not dump the core file.
> 2. generally disable watchdogs and make them opt in. We have
> 'systemd-analyze service-watchdogs',
> and we could make the default configurable to "yes|no".
>
> What do you think?
> Zbyszek
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logging in RAM and journald configuration issue

[Umut Tezduyar Lindskog]

Back then, this is something we have tried and it works. Not with bind
mount though. We also have SD-card as primary storage. As soon as the
storage service mounted the SD-Card, we have created a symbolink link
under /var/log to the persistent and triggered journald flush. It
worked just fine!

On Wed, Mar 20, 2019 at 4:54 PM Colin Guthrie  wrote:
>
> Lennart Poettering wrote on 20/03/2019 13:37:
> > On Mi, 20.03.19 09:57, Dave Howorth (syst...@howorth.org.uk) wrote:
> >
> >>> On Di, 19.03.19 20:45, Dave Howorth (syst...@howorth.org.uk) wrote:
> >>>
>  In the case of a machine that uses an SD card as its primary backing
>  store, it is desirable to reduce the number of write operations to
>  the card in order to prolong its life. journald is quite
>  well-behaved in this regard since it offers the choice of a
>  temporary or permanent journal and limits the frequency of its
>  writes, except in emergencies.
> 
>  However, its permanent journal is written under /var/log/journal and
>  there is no way to configure the path as far as I am aware. I think
>  this is a problem.
> 
>  The reason is that on this type of machine people sometimes map
>   /var/log to RAM using tmpfs and then perhaps persist the logs
>  using a program like log2ram. When this is done, journald's
>  emergency writing capability is lost and crash analysis becomes
>  more difficult.
> 
>  Of course it is possible instead to redirect the log files of
>  programs individually to temporary memory using systemd-tmpfiles
>  wherever needed. But this involves reconfiguring each and every
>  program that uses /var/log both initially and whenever new programs
>  are installed. This is tedious not only in quantity but because
>  each program has a different detailed format of configuration file.
> 
>  So making /var/log into a tmpfs is a more attractive option. But
>  ideally the journal would be placed somewhere else in persistent
>  storage so its contents are available after a crash. This does not
>  seem to be possible through lack of a config option.
> 
>  Is my analysis correct? Are there any other ways to resolve this
>  difficulty? Otherwise, is it possible to consider a log location
>  config option for journald?
> >>>
> >>> Right now, when persistent mode is enabled journald will store its log
> >>> data in /var/log. When it is disabled it will store things in /run/log
> >>> instead.
> >>>
> >>> It has been requested that we add a hybrid mode that makes journald
> >>> log to both locations at the same time, but filter by log priority so
> >>> that log msgs higher than some priority go to one location and the
> >>> ones below it go to the other. A patch like that would probably be
> >>> relatively straight-forward and short. Would be happy to review/merge
> >>> a patch for that.
> >>>
> >>> I think if that's implemented the log location should really stay
> >>> unmodified: /var should be persistant and /run not, and there would be
> >>> no need to remount any of those paths in a different way.
> >>
> >> Many thanks for the quick reply. I'm not clear how that resolves the
> >> situation I explained, since it neither provides an alternative
> >> persistent log location nor provides an alternative means of
> >> arranging the logs of other programs. It doesn't seem to address my
> >> issue at all?
> >
> > I don't understand the problem then?
> >
> > The journal only collects logs on stdout/stderr, syslog and its native
> > protocol. Nothing else. It's not a tool that can collect arbitrary
> > per-app logs that don't go via these transport hence. And it really
> > shouldn't be.
> >
> > Also: /var is generally understood to be persistent, and /run to be
> > volatile. If you want to redefine that you are welcome to, but of
> > course you have to patch through all kinds of software then.
>
> As I understand it, you want /var/log to be tmpfs but /var/log/journal
> to be persistent (as journald's write behaviour is considerate enough
> for you not to worry about backing store fatigue etc)?
>
> Just as a less complex suggestion, you're presumably bootstrapping
> /var/log to be on tmpfs at some point in early boot (i.e. before
> journald is started or at least before it's being told to start writing
> to /var/log/journal). If this is the case, then why don't you just amend
> that bootstrapping to bind mount /var/log/journal to persistent storage
> rather than letting it be just a subdir on the tmpfs? That way you can
> get your mem-only syslog (or native logging) setup as you do now and get
> persistent journal logs with only very minor changes (this could all be
> done with appropriate systemd units and deps AFAICT).
>
> I can't remember off the top of my head what makes journald start
> writing to /var/log/journal, so you may have to change that slightly
> (e.g. it might notice is as soon as you mkdir it in the tmpfs but 

Re: [systemd-devel] what does it mean to have exit-code of 251

[Umut Tezduyar Lindskog]

You need to do some bit analysis - https://shapeshed.com/unix-exit-codes/

On Mon, Mar 4, 2019 at 12:29 PM prashantkumar dhotre
 wrote:
>
> Hi,
>
> In my journal log, I see ;
>
> 1199473 Mar 01 15:46:03 evo-qfx-01 systemd[1]: ifmand.service: Main process 
> exited, code=exited, status=251/n/a
>
>
> I want to know what does 251 means.
>
> Can you  please  let me know where can I see the exit-code to meaning mapping 
> ?
>
> Thanks
>
> Prashant
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting services enabled by filesystem overlay over /etc/

[Umut Tezduyar Lindskog]

Also checkout systemd generators
(https://www.freedesktop.org/software/systemd/man/systemd.generator.html).
A generator can overlay the /etc and generators should run before
systemd starts scanning the unit files.

Umut

On Mon, Feb 11, 2019 at 10:07 PM Matt Schuckmann
 wrote:
>
> Thank you all for the responses.
>
> It sounds like I should look into creating an initramfs to mount my writable 
> partitions and /etc overlay. I've never created an initramfs so it might take 
> me a bit to work through it.
>
>
> In the mean time I've found that masking services does work with my overlay 
> for enabling or disabling services. So my plan now is to leave the service 
> enabled in the read-only rootfs and then mask or unmask it in the /etc 
> overlay.  This seems to be a reasonable workaround until I can get an 
> initramfs in place; unless one of you helpful people tells me otherwise.
>
>
> Thanks,
>
> Matt S.
>
>
> [PS I hope this gets added to the correct thread, I'm only receiving digests 
> and I'm not sure how best to respond].
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald cves on 239

[Umut Tezduyar Lindskog]

Thanks to you all. I wasn't aware of the stable branches. Nice to see them.

On Thu, Jan 24, 2019 at 4:06 PM Mike Gilbert  wrote:
>
> On Thu, Jan 24, 2019 at 9:34 AM Umut Tezduyar Lindskog
>  wrote:
> >
> > Hello,
> >
> > We are on systemd 239 and we would like to patch following CVEs
> > without jumping to 240.
> >
> > CVE-2018-16864
> > CVE-2018-16865
> > CVE-2018-16866
> >
> > Can someone please help us out and point the commits that we need to
> > back-port since 239 was tagged?
>
> Have a look at the v239-stable branch here. You want the commits
> starting with 88947d7cae785c9aefe2083feb22b4ad93060e9e.
>
> https://github.com/systemd/systemd-stable/commits/v239-stable
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] journald cves on 239

[Umut Tezduyar Lindskog]

Hello,

We are on systemd 239 and we would like to patch following CVEs
without jumping to 240.

CVE-2018-16864
CVE-2018-16865
CVE-2018-16866

Can someone please help us out and point the commits that we need to
back-port since 239 was tagged?

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

Re: [systemd-devel] clang-format: auto-formatting the code base of systemd

[Umut Tezduyar Lindskog]

On Sun, Jan 6, 2019 at 5:52 PM Lennart Poettering
 wrote:
>
> On Fr, 04.01.19 14:23, Sebastian Jennen (sebastian.jen...@gmx.de) wrote:
>
> > Hello systemd team,
> >
> > there is a pull request currently on systemd, which adds a .clang-format
> > support, which you can find here:
> > https://github.com/systemd/systemd/pull/11308
> >
> > clang-format is an automatic formatter for C code maintained by the llvm
> > project. It works by tokenizing the source code and reassembling it under
> > consideration of a single source code style defining file (.clang-format).
> >
> > I would like to ask you to participate on a poll on this, as this topic is
> > controversial.
> > One the hand this:
> > - enables programmers to auto-format their patches to comply with the
> > systemd style
> > - fixes a couple of minor code inconsistencies
> > on the other hand this:
> > - reformats all existing code, which requires review
> > - break some systemd specific styles which would need be changed some way
> > (see especially the formatting of table blocks in pull request)
> > - may annoy some developers, as custom styling is lost
> >
> > Please also take into consideration the suggested file tools/format-file.py
> > to extend the clang-format formatting.
>
> I think the core devs mostly already commented on the github issue,
> and all agree that this a good thing, and we should try to make the
> automatic reformatting a core part of our workflow. (For example, I
> think in the long run the CI should refuse PRs which are not properly
> formatted)

It can also run as a git hook before passing the commit to a CI agent.

Umut

>
> The only sticking points are some issues with the generated output
> right now, i.e. the table corruption and things like that, but let's
> discuss that on the github issue.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Statistics collection

[Umut Tezduyar Lindskog]

Hello,

Do you know any statistics collection application for embedded
environment that has fairly working systemd and journald plugins.

There are few I can find but surprisingly none of them have deep
systemd support.

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

Re: [systemd-devel] systemd-timedated doesn't return available time zones

[Umut Tezduyar Lindskog]

Thanks. We will prepare a patch. 

Umut

On 2018-11-20, 15:51, "systemd-devel on behalf of Lennart Poettering" 
 wrote:

On Di, 20.11.18 12:50, Christopher Wong (christopher.w...@axis.com) wrote:

> ?Hi guys,
> 
> 
> We plan to place an abstraction service over systemd-timedated and
> we would like to retrieve available time zones. The timedatectl
> retrieves the list of time zones by itself, but why isn't this
> functionality available in systemd-timedated?

We could certainly make this available. So far there was no real
reason to, the client could just check /usr/share directly...

That said, if the list grows too large we might run into dbus' message
size limits. But would be happy to review a patch if it works.

Lennart

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


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

[systemd-devel] MemoryCurrent property of the root slice is off

[Umut Tezduyar Lindskog]

Hey,

How come the root slice's memory accounting is not matching (or close
to) with what I see in the /sys/fs? Do we do some other special
accounting?

systemctl 239 (default-hierarchy=hybrid)

a@b:memory$ pwd
/sys/fs/cgroup/memory

a@b:memory$ systemctl show -p MemoryCurrent -- -.slice
MemoryCurrent=6363947008
a@b:memory$ cat memory.usage_in_bytes
5459550208

a@b:memory$ systemctl show -p MemoryCurrent system.slice
MemoryCurrent=1540538368
a@b:memory$ cat system.slice/memory.usage_in_bytes
1508548608
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] PrivateDevices= together with DevicePolicy=

[Umut Tezduyar Lindskog]

Hi,

I am turning on PrivateDevices and as a result getting a minimal /dev
tree for my service. Then I would like to add some selected devices
with DevicePolicy=auto & DeviceAllow=/dev/cam0. As a result, I don't
see the device /dev/cam0 in the /dev tree and since the mount space is
RO, I cannot create the device node either. However, the device cgroup
has the right permissions.

Could you please explain if this is the expected behaviour?

systemd 239

-PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT -UTMP
-LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL -XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
+KMOD -IDN2 -IDN -PCRE2 default-hierarchy=legacy

cat a.service
[Service]
PrivateDevices=yes
DevicePolicy=auto
DeviceAllow=/dev/cam0
ExecStart=/bin/sh -c "ls -al /dev && cat
/sys/fs/cgroup/devices/system.slice/a.service/devices.list"

Aug 21 06:17:32 axis-accc systemd[1]: Started a.service.
Aug 21 06:17:32 axis-accc sh[5340]: drwxr-xr-x6 root
root   380 Aug 21 06:17 .
Aug 21 06:17:32 axis-accc sh[5340]: drwxr-xr-x   15 root
root  1520 Aug 20 14:06 ..
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root11 Aug 21 06:17 core -> /proc/kcore
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root13 Aug 21 06:17 fd -> /proc/self/fd
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root1,   7 Aug 21 06:17 full
Aug 21 06:17:32 axis-accc sh[5340]: drwxr-xr-x2 root
root40 Aug 21 06:17 hugepages
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root28 Aug 21 06:17 log -> /run/systemd/journal/dev-log
Aug 21 06:17:32 axis-accc sh[5340]: drwxr-xr-x2 root
root40 Aug 21 06:17 mqueue
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root1,   3 Aug 21 06:17 null
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root5,   2 Aug 21 06:17 ptmx
Aug 21 06:17:32 axis-accc sh[5340]: drwxr-xr-x2 root
root 0 Aug 21 06:12 pts
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root1,   8 Aug 21 06:17 random
Aug 21 06:17:32 axis-accc sh[5340]: drwxrwxrwt2 root
root   100 Aug 21 06:13 shm
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root15 Aug 21 06:17 stderr -> /proc/self/fd/2
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root15 Aug 21 06:17 stdin -> /proc/self/fd/0
Aug 21 06:17:32 axis-accc sh[5340]: lrwxrwxrwx1 root
root15 Aug 21 06:17 stdout -> /proc/self/fd/1
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root5,   0 Aug 21 06:17 tty
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root1,   9 Aug 21 06:17 urandom
Aug 21 06:17:32 axis-accc sh[5340]: crw-rw-rw-1 root
root1,   5 Aug 21 06:17 zero
Aug 21 06:17:32 axis-accc sh[5340]: c 1:3 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 1:5 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 1:7 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 1:8 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 1:9 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 5:0 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 5:2 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 0:0 rwm
Aug 21 06:17:32 axis-accc sh[5340]: b 0:0 rwm
Aug 21 06:17:32 axis-accc sh[5340]: c 136:* rw
Aug 21 06:17:32 axis-accc sh[5340]: c 61:0 rwm
Aug 21 06:17:32 axis-accc systemd[1]: a.service: Consumed 64ms CPU time

root@axis-accc:/etc/systemd/system# ls -al /dev | grep cam0
crw-rw-rw-1 root video  61,   0 Aug 20 13:52 cam0


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

Re: [systemd-devel] Async server with sd-bus

[Umut Tezduyar Lindskog]

Hello,

On Mon, May 21, 2018 at 8:37 AM, Stanislav Angelovič
 wrote:
> Hi folks,
>
> Suppose we have a server whose methods may take relatively long time and I
> would like to process them asynchronously within the server, so while a
> client is waiting for reply to his time-consuming call, other clients (which
> could be served quickly, for example) are not starved because of this.
>
> I suppose sd-bus supports such an approach, since it is message-based.

Correct but this is nothing special to sd-bus but specific to dbus
protocol itself. The magic is in reply cookie field of the replies.
Check this out -
https://dbus.freedesktop.org/doc/dbus-specification.html.

>
> Also, implementation-wise, I suppose these async replies must be sent back
> by the processing thread that handles requests upon the bus connection
> (since sd_bus and sd_bus_message seem to no be thread-safe). So I need to
> sent the reply messages from the worker thread back to the processing
> thread, to send them out.

sd-bus is not thread safe. You either need to handle synchronization
between API calls or do as you suggested for sending out the reply
messages. The same is valid for receiving side of your server. If your
receiver, under the context of receiving task, is performing CPU
intensive operation, no new dbus message is going to be fetched from
the wire until the task is ready to do something else.

Umut

>
> I am right with my assumptions and statements? Have you already solved such
> a problem somewhere in systemd?
>
> Thanks for help and cheers!
>
> Stanislav.
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Umut Tezduyar Lindskog]

Hello Zbigniew,

On Mon, Mar 5, 2018 at 11:37 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> Hi,
>
> systemd-238 has been tagged.
>
> https://github.com/systemd/systemd/archive/v238/systemd-238.tar.gz
>
> CHANGES WITH 238:
>
> * The MemoryAccounting= unit property now defaults to on. After
>   discussions with the upstream control group maintainers we learnt
>   that the negative impact of cgroup memory accounting on current
>   kernels is finally relatively minimal, so that it should be safe to
>   enable this by default without affecting system performance. Besides
>   memory accounting only task accounting is turned on by default, all
>   other forms of resource accounting (CPU, IO, IP) remain off for now,
>   because it's not clear yet that their impact is small enough to move
>   from opt-in to opt-out. We recommend downstreams to leave memory
>   accounting on by default if kernel 4.14 or higher is are primarily
>   used. On very resource constrained systems or when support for old
>   kernels is a necessity, -Dmemory-accounting-default=false can be 
> used
>   to revert this change.

Are these optimisations for v1 or v2? Do you have more resource you
can reference?

Thanks,
UMUT

>
> * rpm scriptlets to update the udev hwdb and rules (%udev_hwdb_update,
>   %udev_rules_update) and the journal catalog 
> (%journal_catalog_update)
>   from the upgrade scriptlets of individual packages now do nothing.
>   Transfiletriggers have been added which will perform those updates
>   once at the end of the transaction.
>
>   Similar transfiletriggers have been added to execute any sysctl.d
>   and binfmt.d rules. Thus, it should be unnecessary to provide any
>   scriptlets to execute this configuration from package installation
>   scripts.
>
> * systemd-sysusers gained a mode where the configuration to execute is
>   specified on the command line, but this configuration is not 
> executed
>   directly, but instead it is merged with the configuration on disk,
>   and the result is executed. This is useful for package installation
>   scripts which want to create the user before installing any files on
>   disk (in case some of those files are owned by that user), while
>   still allowing local admin overrides.
>
>   This functionality is exposed to rpm scriplets through a new
>   %sysusers_create_package macro. Old %sysusers_create and
>   %sysusers_create_inline macros are deprecated.
>
>   A transfiletrigger for sysusers.d configuration is now installed,
>   which means that it should be uncessary to call systemd-sysusers 
> from
>   package installation scripts, unless the package installs any files
>   owned by those newly-created users, in which case
>   %sysusers_create_package should be used.
>
> * Analogous change has been done for systemd-tmpfiles: it gained a 
> mode
>   where the command-line configuration is merged with the 
> configuration
>   on disk. This is exposed as the new %tmpfiles_create_package macro,
>   and %tmpfiles_create is deprecated. A transfiletrigger is installed
>   for tmpfiles.d, hence it should be unnecessary to call 
> systemd-tmpfiles
>   from package installation scripts.
>
> * sysusers.d configuration for a user may now also specify the group
>   number, in addition to the user number ("u username 123:456"), or
>   without the user number ("u username -:456").
>
> * Configution items for systemd-sysusers can now be specified as
>   positional arguments when the new --inline switch is used.
>
> * The login shell of users created through sysusers.d may now be
>   specified (previously, it was always /bin/sh for root and
>   /sbin/nologin for other users).
>
> * systemd-analyze gained a new --global switch to look at global user
>   configuration. It also gained a unit-paths verb to list the unit 
> load
>   paths that are compiled into systemd (which can be used with
>   --systemd, --user, or --global).
>
> * udevadm trigger gained a new --settle/-w option to wait for any
>   triggered events to finish (but just those, and not any other events
>   which are triggered meanwhile).
>
> * The action that systemd-logind takes when the lid is closed and the
>   machine is connected to external power can now be configured using
>   HandleLidSwitchExternalPower= in logind.conf. Previously, this 
> action
>   was determined by HandleLidSwitch=, and, for backwards 
> compatibility,
>   is still is, if HandleLidSwitchExternalPower= is not explicitly set.
>
> * 

Re: [systemd-devel] custom var in sd_notify

[Umut Tezduyar Lindskog]

On Wed, Feb 28, 2018 at 7:04 PM, Lennart Poettering
 wrote:
> On Mo, 26.02.18 08:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> > Daemons can choose to send additional variables. However, it is recommended
>> > to prefix variable names not listed above with X_.
>> > So naturally i tried
>> >
>> > sd_notify(0, "X_ANSWER=42")
>> >
>> > and apparently systemd has no problem with that, but my questions are 2
>> > now:
>> >
>> > 1) What does systemd do with this information?
>> >
>>
>> Nothing. The documentation just says in other words that "the init system
>> must not reject packets with unknown variables", but doesn't say that
>> systemd or any other init will store all of them anywhere.
>
> Currently we indeed ignore those unknown variables entirely. It has
> been requested that we expose these variables on the bus somehow. I
> think that would be an OK addition, but we need to think about the
> lifecycle of those vars then so that the vars we collect don't grow
> without bounds.

I believe this is what we do with STATUS: messages today. I was just
curious if there is a rate limit around this sd_notify interface.

UMUT

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

Re: [systemd-devel] How does hybrid cgroup setup work?

[Umut Tezduyar Lindskog]

On Fri, Nov 10, 2017 at 12:16 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Fr, 10.11.17 11:11, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>
>> On Wed, Nov 8, 2017 at 9:25 PM, Lennart Poettering
>> <lenn...@poettering.net> wrote:
>> > On Sa, 28.10.17 22:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>> >
>> >> Hello,
>> >>
>> >> I am trying to have cpu controller on v1 and memory controller on
>> >> unified but it is not working the way I am expecting. When I enable
>> >> CONFIG_MEMCG, cgroup is popping up in /proc/cgroups and
>> >> mount_cgroup_controllers() is mounting it very early. Once it is
>> >> mounted in v1, it becomes unavailable in v2.
>> >>
>> >> Did I misunderstand how hybrid works?
>> >
>> > hybrid means that v2 is used only for tracking services (which is a
>> > good thing, since it provides safe notification of when a cgroup
>> > exits), but not for any of the controllers. That means hybrid mode is
>> > mostly compatible with pure v1, except that there's yet another
>> > hierarchy (the v2 one) and systemd uses it for its own purposes.
>>
>> Is there a technical reason why we cannot have a broader hybrid like
>> some controllers from v1 and some from v2?
>>
>> We would like to keep using cpu v1 until cpu v2 is accepted but
>> meanwhile take advantage of improvements on memory v2.
>
> Well, right now, you have three types of setups:
>
> 1) legacy:
>
>/sys/fs/cgroup/ → tmpfs instance
>/sys/fs/cgroup/memory/ → memory controller hierarchy
>/sys/fs/cgroup/cpu/ → cpu controller heirarchy
>…
>/sys/fs/cgroup/systemd/ → named hierarchy, which systemd uses to
>manage its stuff (and which is mostly internal to systemd)
>
> 2) unified:
>
>/sys/fs/cgroup/ → the unified hierarchy (i.e, note that this is one
>  dir further up, in lieu of the tmpfs)
>
> 3) hybrid:
>
>/sys/fs/cgroup/ → tmpfs
>/sys/fs/cgroup/memory/ → memory controller hierarchy
>/sys/fs/cgroup/cpu/ → cpu controller heirarchy
>…
>/sys/fs/cgroup/systemd/ → named hierarchy, for compatibility
>/sys/fs/cgroup/unified/ → the unified hierarchy with no
>controllers, which systemd uses to manage its stuff (and which is
>mostly internal to systemd)
>
> Now, supporting #1 and #2 definitely makes sense, as one is the old
> setup, and one the future setup. #3 is in most ways compatible to #1,
> as the only thing that changes was the addition of one more hierarchy,
> but all the old controller hierarchies remain at the same place. Or in
> other words, systemd's private hierarchy changes, but all the other
> stuff remains at the exact same location
>
> Now, what you propose, is neither similar to 1) or 3) (as the
> controllers would be moved in part to the unified hierarchy). Nor
> similar to #2 (as the the unified dir would not be /sys/fs/cgroup,
> since then you'd have no place to mount the legacy controllers).
>
> Hence, adding what you propose would only be a temporary stop-gap,
> that at the moment of adding would already be clearly on its way out,
> and I am very conservative of adding support now for something we know
> will not survive for long...
>
> And then there's also the big issue: the cgroup code is complex enough
> given that we need to support three different setups. I'd really
> prefer if we'd not add even more to that. In fact, I am really looking
> forward for the day we can drop all cgroup support besides the unified
> one from our tree. We could delete *so much* code then! And there's
> only one thing hackers prefer over writing code: deleting code... ;-)

I guess that day will come when all the controllers move to v2. What
is your knowledge regarding plans of moving all the control groups?
Are they all going to be moved? If so, are they all going to provide
somehow similar functionality? For example I have noticed I cannot
find a similar functionality of "memory.max_usage_in_bytes" in v2
memory control group. I am not sure if everyone will be happily jump
to #2 (unified) way any time soon or if they will still want to use
some parts from v1 in an unified fashion meanwhile.

UMUT

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

Re: [systemd-devel] How does hybrid cgroup setup work?

[Umut Tezduyar Lindskog]

On Wed, Nov 8, 2017 at 9:25 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Sa, 28.10.17 22:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>
>> Hello,
>>
>> I am trying to have cpu controller on v1 and memory controller on
>> unified but it is not working the way I am expecting. When I enable
>> CONFIG_MEMCG, cgroup is popping up in /proc/cgroups and
>> mount_cgroup_controllers() is mounting it very early. Once it is
>> mounted in v1, it becomes unavailable in v2.
>>
>> Did I misunderstand how hybrid works?
>
> hybrid means that v2 is used only for tracking services (which is a
> good thing, since it provides safe notification of when a cgroup
> exits), but not for any of the controllers. That means hybrid mode is
> mostly compatible with pure v1, except that there's yet another
> hierarchy (the v2 one) and systemd uses it for its own purposes.

Is there a technical reason why we cannot have a broader hybrid like
some controllers from v1 and some from v2?

We would like to keep using cpu v1 until cpu v2 is accepted but
meanwhile take advantage of improvements on memory v2.

UMUT

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

[systemd-devel] How does hybrid cgroup setup work?

[Umut Tezduyar Lindskog]

Hello,

I am trying to have cpu controller on v1 and memory controller on
unified but it is not working the way I am expecting. When I enable
CONFIG_MEMCG, cgroup is popping up in /proc/cgroups and
mount_cgroup_controllers() is mounting it very early. Once it is
mounted in v1, it becomes unavailable in v2.

Did I misunderstand how hybrid works?
Umut
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] delayed reply to sd-bus method invocation

[Umut Tezduyar Lindskog]

Hello Jason,

Just wanted to remind you that clients set a timeout for the method reply.
Don't remember off the top of my head but different implementations have
different default timeouts. Consider this when delaying the reply.

Umut

On Mon, Jul 3, 2017 at 10:36 AM Lennart Poettering 
wrote:

> On Thu, 29.06.17 21:55, Jason Litzinger (jlitzinger...@gmail.com) wrote:
>
> > > machined has easier-to-follow uses of this, as it does some operations
> > > that might take a bit longer, such as cloning or removing images.
> > Thanks!
> >
> > Since I'll be going through this to come up with something for my
> > own use case, it wouldn't be much to write up a self-contained example.
> > Is there an examples repo/folder/etc where this kind of thing would fit?
>
> Not right now, no. We do have some terse examples in man pages though,
> and maybe we can build on that. But to be included in a man page the
> example needs to be reduced to the minimum, which isn't always easy.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Does systemd-stdio-bridge handle dbus UNIX_FD passing somehow?

[Umut Tezduyar Lindskog]

Hello,

I would like to make a method call on a remote machine with busctl
where the method returns UNIX_FD (h), type unix domain socket.

I am guessing the FD stops on stdio-bridge without any other magic
bridging the UDS to an another socket on the host. Is that the case?
Can there be any magic to accomplish this?

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

[systemd-devel] 11 MB cost of DefaultMemoryAccounting=yes

[Umut Tezduyar Lindskog]

Hello,

Even though this is not a systemd problem, I believe systemd mailing
list is a good place to discuss.

Our kernel has CONFIG_MEMCG enabled. As soon as we set
DefaultMemoryAccounting=yes, our system wide memory usage increased 11
MB. The increase is mostly on kmalloc-* slab memory with the peak on
kmalloc-32.

I initially thought the increase is due to systemd creating
system.slice under /sys/fs/cgroup/memory but I think I am wrong. I
have run "systemd-run -p MemoryLimit=10M /bin/sleep 5" command while
DefaultMemoryAccounting=no and there was no significant memory usage.

I am quite puzzled about where this extra cost is coming from. Does
anybody have any idea?

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

Re: [systemd-devel] getting systemd 232 ready

[Umut Tezduyar Lindskog]

On Fri, Oct 21, 2016 at 7:00 PM, Martin Pitt  wrote:
> Hello Zbigniew, Lennart, all,
>
> Zbigniew Jędrzejewski-Szmek [2016-10-20  4:00 +]:
>> Open bugs with v232 milestone [1]:
>> [2] 
>> https://github.com/systemd/systemd/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20milestone%3Av232%20-label%3Aresolve%20-label%3Ahas-pr
>
> None of those are a regression from 231, so we could easily move them
> to 233. Should we?

I think #4408 is quite important for few reasons:
a) I doubt it is only the journal that is broken. Maybe all the
FDSTORE services.
b) Things are not recovering if journald crashes. You will end up
having no logs from all the services that connect to journal directly.

I didn't have time to figure out when things went south.

UMUT

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

Re: [systemd-devel] why do we have aliases fro timedated, resolved, networkd, and what are they good for?

[Umut Tezduyar Lindskog]

Hi Michael,

On Sat, Sep 10, 2016 at 1:00 AM, Michael Biebl  wrote:
> Hi
>
> I wonder why we have the following aliases/symlinks
>
> dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
> dbus-org.freedesktop.import1.service -> systemd-importd.service
> dbus-org.freedesktop.locale1.service -> systemd-localed.service
> dbus-org.freedesktop.login1.service -> systemd-logind.service
> dbus-org.freedesktop.machine1.service -> systemd-machined.service
> dbus-org.freedesktop.network1.service -> systemd-networkd.service
> dbus-org.freedesktop.resolve1.service -> systemd-resolved.service
> dbus-org.freedesktop.timedate1.service -> systemd-timedated.service
>
> Those dbus-org.* aliases are used in the corresponding D-Bus system
> service files (SystemdService=dbus-org...)
> The symlinks/aliases are created statically in $libdir/systemd/system,
> so they can't be removed via systemctl disable.
>
> So, I'm asking myself what good those aliases are for?
> They actually have a downside:
> We just had a Debian bug report, where a user was masking
> systemd-resolved.service, but he was puzzled that he could still
> trigger the start of the service via systemd-resolve.
> This happened via D-Bus activation and the aliased name (which he had
> not masked).

AFAIK, that 2 step service file name is for providing a way to prevent
dbus activation. Masking resolved alias file should prevent dbus
activation. "systemctl mask dbus-org.freedesktop.resolve1.service".

UMUT

>
> So, should we add those aliases via
> [Install]
> Also=
> dynamically, so a user can actually disable the services or should we
> switch the D-Bus system service files to use the non-aliased names in
> SystemdService=?
> At which point we could stop shipping those symlinks altogether.
>
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Umut Tezduyar Lindskog]

On Mon, May 16, 2016 at 11:06 AM, Martin Pitt  wrote:
> Michael Biebl [2016-05-16  4:24 +0200]:
>> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ 
>> ?
>> Could we move more common functionality into a shared, private library
>> to counter the constant growth?
>
> Building src/shared/ into a private libsystemd-internal.so (which
> doesn't have a SONAME and shipped development headers, so that we
> continue to be able to change the API freely) should help a great deal
> there. Is that something that would be accepted upstream?
Similar discussion:
https://lists.freedesktop.org/archives/systemd-devel/2016-February/035918.html
>
> I wouldn't like to split out things like systemd-analyze just because
> of being a big binary. It's useful for all sorts of things even on a
> non-developer machine: temporarily raise log levels, check
> admin-provided units, and check why your machine takes too much time
> to boot, etc.
>
> 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
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Support for large applications

[Umut Tezduyar Lindskog]

On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity  wrote:
> We are using systemd to supervise our NoSQL database and are generally
> happy.
>
> A few things will help even more:
>
> 1. log core dumps immediately rather than after the dump completes
>
> A database will often consume all memory on the machine; dumping 120GB can
> take a lot of time, especially if compression is enabled. As the situation
> is now, there is a period of time where it is impossible to know what is
> happening.
>
> (I saw that 229 improves core dumps, but did not see this specifically)
>
> 2. parallel compression of core dumps
>
> As well as consuming all of memory, we also consume all cpus.  Once we dump
> core we may as well use those cores for compressing the huge dump.
>
> 3. watchdog during startup
>
> Sometimes we need to perform expensive operations during startup (log
> replay, rebuild from network replica) before we can start serving. Rather
> than configure a huge start timeout, I'd prefer to have the service report
> progress to systemd so that it knows that startup is still in progress.

Hi. Similar topic from the past -
https://lists.freedesktop.org/archives/systemd-devel/2015-March/028919.html.
Though, I believe this is an architectural problem than real
necessity.

Umut

>
> Hope this is useful,
>
> Avi
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bootchart speeding up boot time

[Umut Tezduyar Lindskog]

On Mon, Feb 22, 2016 at 8:51 PM, Martin Townsend
 wrote:
> Hi,
>
> Thanks for your reply.  I wouldn't really call this system stripped down, it
> has an nginx webserver, DHCP server, postgresql-server, sftp server, a few
> mono (C#) daemons running, loads quite a few kernel modules during boot,
> dbus, sshd, avahi, and a bunch of other stuff I can't quite remember.  I
> would imagine glibc will be a tiny portion of what gets loaded during boot.
> I have another arm system which has a similar boot time with systemd, it's
> only a single cortex A9 core, it's running a newer 4.1 kernel with a new
> version of systemd as it's built with the Jethro version of Yocto so
> probably a newer version of glibc and this doesn't speed up when using
> bootchart and in fact slows down slightly (which is what I would expect).
> So my current thinking is that it's either be down to the fact that it's a
> dual core and only one core is being used during boot unless a fork/execl
> occurs? Or it's down to the newer kernel/systemd/glibc or some other
> component.

Are you sure both cores have the same speed and same size of L1
data cache?
You could try to force the OS to run systemd on the first core by A)
make the second one unavailable B) play with control groups and pin
systemd to first core.

Umut

>
> Is there anyway of seeing what the CPU usage for each core is for systemd on
> boot without using bootchart then I can rule in/out the first idea.
>
> Many Thanks,
> Martin.
>
>
> On Mon, Feb 22, 2016 at 6:52 PM, Kok, Auke-jan H 
> wrote:
>>
>> On Fri, Feb 19, 2016 at 7:15 AM, Martin Townsend
>>  wrote:
>> > Hi,
>> >
>> > I'm new to systemd and have just enabled it for my Xilinx based dual
>> > core
>> > cortex A-9 platform.  The linux system is built using Yocto (Fido
>> > branch)
>> > which is using version 219 of systemd.
>> >
>> > The main reason for moving over to systemd was to see if we could
>> > improve
>> > boot times and the good news was that by just moving over to systemd we
>> > halved the boot time.  So I read that I could analyse the boot times in
>> > detail using bootchart so I set init=//bootchart in my kernel
>> > command
>> > line and was really suprised to see my boot time halved again.  Thinking
>> > some weird caching must have occurred on the first boot I reverted back
>> > to
>> > normal systemd boot and boot time jumped back to normal (around 17/18
>> > seconds), putting bootchart back in again reduced it to ~9/10 seconds.
>> >
>> > So I created my own init using bootchart as a template that just slept
>> > for
>> > 20 seconds using nanosleep and this also had the same effect of speeding
>> > up
>> > the boot time.
>> >
>> > So the only difference I can see is that the kernel is not starting
>> > /sbin/init -> /lib/systemd/systemd directly but via another program that
>> > is
>> > performing a fork and then in the parent an execl to run
>> > /lib/systemd/systemd.  What I would really like to understand is why it
>> > runs
>> > faster when started this way?
>>
>>
>> systemd-bootchart is a dynamically linked binary. In order for it to
>> run, it needs to dynamically link and load much of glibc into memory.
>>
>> If your system is really stripped down, then the portion of data
>> that's loaded from disk that is coming from glibc is relatively large,
>> as compared to the rest of the system. In an absolute minimal system,
>> I expect it to be well over 75% of the total data loaded from disk.
>>
>> It seems in your system, glibc is about 50% of the stuff that needs to
>> be paged in from disk, hence, by starting systemd-bootchart before
>> systemd, you've "removed" 50% of the total data to be loaded from the
>> vision of bootchart, since, bootchart cannot start logging data until
>> it's loaded all those glibc bits.
>>
>> Ultimately, your system isn't likely booting faster, you're just
>> forcing it to load glibc before systemd starts.
>>
>> systemd-analyze may actually be a much better way of looking at the
>> problem: it reports CLOCK_MONOTONIC timestamps for the various parts
>> involved, including, possibly, firmware, kernel time, etc.. In
>> conjunction with bootchart, this should give a full picture.
>>
>> Auke
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

[Umut Tezduyar Lindskog]

Hi,

src/shared & src/basic have very useful code that upstream have been static 
linking to most binaries. My understanding is that we haven’t been feeling 
comfortable about the API to make these paths a standalone library (or include 
them in libsystemd).

Now that we started duplicating the code outside of systemd main repo, wouldn’t 
it be wise to make it a library even if it was something like 
libsystemd_onlyandonlyinternal.so.

For people who can follow upstream’s speed and catch up with API changes we 
would gain:

A) No duplication of useful code.
B) Reduce the binary sizes.

Umut

> On Feb 17, 2016, at 5:51 PM, Daniel Mack  wrote:
> 
> Hey,
> 
> [I've put all people in Cc who have had more than one commit related to
> systemd-bootchart in the past]
> 
> As part of our spring cleaning, we've been thinking about giving
> systemd-bootchart a new home, in a new repository of its own. I've been
> working on this and put the result here:
> 
>  https://github.com/systemd/systemd-bootchart
> 
> This repository contains a stripped down set of the utility functions we
> have in src/shared and src/basic in systemd, with most of those which
> bootchart doesn't use removed. The man page and service file etc. are
> all in the new repository. A new GitHub team was created for maintainers
> of that code, and I'm willing to add more people to it, just let me
> know. Auke, you are the official maintainer of the thing, so I'd put you
> in that group anyway.
> 
> I have a local patch that removes the current sources from systemd, but
> before I put that into a pull request, I'd appreciate some feedback, so
> please let me know if the standalone version of that tool works for you.
> 
> 
> Thanks,
> Daniel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

[Umut Tezduyar Lindskog]

Hi,

On Fri, Feb 12, 2016 at 10:36 PM, Lennart Poettering
 wrote:
> On Fri, 12.02.16 23:12, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:
>
>> 12.02.2016 22:57, Lennart Poettering пишет:
>> > On Fri, 12.02.16 22:28, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:
>> >
>> >>> TimeoutStopSec= is set to 90s by default. Because it is opt-out and
>> >>> not opt-in it's set pretty much in all cases.
>> >>>
>> >>> Note that when the RuntimeMaxSec= timeout hits and systemd starts
>> >>> terminating the service it does so by going through ExecStop= and
>> >>> ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
>> >>> anyway.
>> >>
>> >> So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
>> >> with RuntimeMaxSec=, which is the normal procedure to exit with
>> >> on-success exit-code, why systemd marks unit as "failed", when
>> >> RuntimeMaxSec= is hit? Can't catch the logic yet...
>> >
>> > It's the same as with a daemon exiting non-zero. In that case we'll
>> > also continue with ExecStop= and place the service in a failed state.
>>
>> So, if I define, for example, RuntimeMaxSec=15s, that means unit should
>> stop its job in the interval=[0; 14.59]s and 15.00s will be interval
>> overflow with exit-code 'failure'. OK. But what if unit will stop its
>> job on, e.g., 13th second? Exit-code=success?
>
> Yes.
>
> RuntimeMaxSec= just says "abort this shit if it takes longer than
> this". The usecase is to use it for stuff which is not supposed to
> take this long, and where it's better to abort it, and complain than
> to leave it running unbounded.

What is a use case for this, can you give an example? I can make few
for a Type=oneshot service (Note that this setting does not have any
effect on Type=oneshot services) like "send this email, search this
database" but I cannot come up with something for other service types.

However I think it would be nice to extend this to terminate say a
service taking all available CPU within certain time.

Umut

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

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

[Umut Tezduyar Lindskog]

I think so :) Better than giving wrong information.

On Thu, Nov 19, 2015 at 11:30 AM, Michael Biebl <mbi...@gmail.com> wrote:
> 2015-11-19 11:17 GMT+01:00 Umut Tezduyar Lindskog <u...@tezduyar.com>:
>> On Wed, Nov 18, 2015 at 10:13 AM, David Herrmann <dh.herrm...@gmail.com> 
>> wrote:
>
>>> * systemd will now bump the net.unix.max_dgram_qlen to 512 by
>>>   default now (the kernel default is 16). This is beneficial
>>
>> AFAIK default is 10 which means you can queue 11 messages before
>> blocking on the socket.
>> cat /proc/sys/net/unix/max_dgram_qlen
>
> Correct. Do you think we should update the comment in the code?
>
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Umut Tezduyar Lindskog]

On Wed, Nov 18, 2015 at 10:13 AM, David Herrmann  wrote:
> Hey!
>
> We just tagged a new release, slightly delayed due to the conference.
> It includes several new features, some old cruft removed, and many
> bugfixes!
>
> CHANGES WITH 228:
>
> * A number of properties previously only settable in unit
>   files are now also available as properties to set when
>   creating transient units programmatically via the bus, as it
>   is exposed with systemd-run's --property=
>   setting. Specifically, these are: SyslogIdentifier=,
>   SyslogLevelPrefix=, TimerSlackNSec=, OOMScoreAdjust=,
>   EnvironmentFile=, ReadWriteDirectories=,
>   ReadOnlyDirectories=, InaccessibleDirectories=,
>   ProtectSystem=, ProtectHome=, RuntimeDirectory=.
>
> * When creating transient services via the bus API it is now
>   possible to pass in a set of file descriptors to use as
>   STDIN/STDOUT/STDERR for the invoked process.
>
> * Slice units may now be created transiently via the bus APIs,
>   similar to the way service and scope units may already be
>   created transiently.
>
> * Wherever systemd expects a calendar timestamp specification
>   (like in journalctl's --since= and --until= switches) UTC
>   timestamps are now supported. Timestamps suffixed with "UTC"
>   are now considered to be in Universal Time Coordinated
>   instead of the local timezone. Also, timestamps may now
>   optionally be specified with sub-second accuracy. Both of
>   these additions also apply to recurring calendar event
>   specification, such as OnCalendar= in timer units.
>
> * journalctl gained a new "--sync" switch that asks the
>   journal daemon to write all so far unwritten log messages to
>   disk and sync the files, before returning.
>
> * systemd-tmpfiles learned two new line types "q" and "Q" that
>   operate like "v", but also set up a basic btrfs quota
>   hierarchy when used on a btrfs file system with quota
>   enabled.
>
> * tmpfiles' "v", "q" and "Q" will now create a plain directory
>   instead of a subvolume (even on a btrfs file system) if the
>   root directory is a plain directory, and not a
>   subvolume. This should simplify things with certain chroot()
>   environments which are not aware of the concept of btrfs
>   subvolumes.
>
> * systemd-detect-virt gained a new --chroot switch to detect
>   whether execution takes place in a chroot() environment.
>
> * CPUAffinity= now takes CPU index ranges in addition to
>   individual indexes.
>
> * The various memory-related resource limit settings (such as
>   LimitAS=) now understand the usual K, M, G, ... suffixes to
>   the base of 1024 (IEC). Similar, the time-related resource
>   limit settings understand the usual min, h, day, ...
>   suffixes now.
>
> * There's a new system.conf setting DefaultTasksMax= to
>   control the default TasksMax= setting for services and
>   scopes running on the system. (TasksMax= is the primary
>   setting that exposes the "pids" cgroup controller on systemd
>   and was introduced in the previous systemd release.) The
>   setting now defaults to 512, which means services that are
>   not explicitly configured otherwise will only be able to
>   create 512 processes or threads at maximum, from this
>   version on. Note that this means that thread- or
>   process-heavy services might need to be reconfigured to set
>   TasksMax= to a higher value. It is sufficient to set
>   TasksMax= in these specific unit files to a higher value, or
>   even "infinity". Similar, there's now a logind.conf setting
>   UserTasksMax= that defaults to 4096 and limits the total
>   number of processes or tasks each user may own
>   concurrently. nspawn containers also have the TasksMax=
>   value set by default now, to 8192. Note that all of this
>   only has an effect if the "pids" cgroup controller is
>   enabled in the kernel. The general benefit of these changes
>   should be a more robust and safer system, that provides a
>   certain amount of per-service fork() bomb protection.
>
> * systemd-nspawn gained the new --network-veth-extra= switch
>   to define additional and arbitrarily-named virtual Ethernet
>   links between the host and the container.
>
> * A new service execution setting PassEnvironment= has been
>   added that allows importing select environment variables
>   from PID1's environment block into the environment block of
>   the service.
>
> * 

[systemd-devel] public bus_event_loop_with_idle function

[Umut Tezduyar Lindskog]

Hey,

bus_event_loop_with_idle seems very useful function in terms of
shutting down services race free and it is both for kdbus/dbus-daemon.

Any plans making it public?

Umut
___
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

[Umut Tezduyar Lindskog]

On Tue, Nov 3, 2015 at 1:20 PM, Dimitri John Ledkov
<dimitri.j.led...@intel.com> wrote:
> On 3 November 2015 at 06:27, Umut Tezduyar Lindskog <u...@tezduyar.com> 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)

That is how I am envisioning it. uptimed seems a bit complex for
something so simple.

>
> 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
>> <lenn...@poettering.net> 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] "File exists warning" on first boot

[Umut Tezduyar Lindskog]

This is due to both services (getty@tty1.service and remote-fs.target)
having [Install] section.

I do not know why these services are not shipped without the [Install]
section like the rest of the other systemd services.

Umut

On Tue, Sep 8, 2015 at 10:36 AM, Johan x Lundin  wrote:
> Hello,
>
> On a fresh boot (no /etc/machine-id yet), I'm getting:
> systemd[1]: Failed to populate /etc with preset unit settings, ignoring: File
> exists
>
> The files that systemd is complaining about are installed by systemd
> itself (/etc/systemd/system/getty.target.wants/getty@tty1.service and
> /etc/systemd/system/multi-user.target.wants/remote-fs.target).
>
> Is there any reason not to let these files be populated in /etc on first boot,
> and remove the warning?
>
> Best Regards,
> Johan Lundin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Keeping track of usage time

[Umut Tezduyar Lindskog]

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?

Umut
___
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

[Umut Tezduyar Lindskog]

journalctl --list-boots seems great actually but wouldn't work for us.
We cannot keep lots of logs in our products.

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
<lenn...@poettering.net> 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

Re: [systemd-devel] systemd.conf 2015 Announcement and CfP

[Umut Tezduyar Lindskog]

Fantastic! Tried to purchase a ticket but seems like PayPal is the
only supported payment. Is this a glitch?

Umut

On Wed, Jul 29, 2015 at 5:55 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Heya!

 The first systemd conference, systemd.conf, will take place on
 November 5th-7th, 2015 at betahaus in Berlin-Kreuzberg, Germany. The
 systemd project is one of the core components of most of today’s Linux
 distributions. At systemd.conf 2015 we will discuss the state and
 future of the Linux core platform and plumbing. The intended audience
 of the conference are developers, distribution packagers as well as
 devops professionals. The conference will consist of presentations as
 well as an extended hackfest.

 → https://systemd.events/

 Please Register for the Conference!

 Only a limited number of tickets are available. If you plan on
 attending the conference, please sign up soon. If you sign up
 before August 16th, 2015, there’s an early-bird discount. A ticket
 is required to attend the conference. Tickets are on sale at:

 → https://systemd.events/systemdconf-2015/registration

 Call for Presentations

  We’d like to invite presentation proposals for systemd.conf
  2015. We are looking for talks including, but not limited to the
  following topics:

  - Use Cases: systemd in today’s and tomorrow’s devices and applications,
  - systemd and containers, in the cloud and on servers,
  - systemd in distributions,
  - Embedded systemd,
  - systemd on the desktop,
  - Networking with systemd,
  - D-Bus and kdbus IPC systems,
  - … and everything else related to systemd.

  Please submit your session proposals by August 31st, 2015 at:

  → https://systemd.events/systemdconf-2015/add/session

  We will notify submitters about proposal acceptance by
  September 15th, 2015.

  We will only accept presentations in English.

  More information about the CfP you may find on:

  → https://systemd.events/systemdconf-2015/call-presentations

 Contact Us

  If you wish to receive more information as it becomes available,
  follow us at +systemd on Google+. If you have any questions
  please send us an email to info@systemd.events.

  For more information about systemd, please consult:

  → https://wiki.freedesktop.org/www/Software/systemd/

  For more information about systemd.conf 2015, please consult:

  → https://systemd.events/

 Partners and Sponsoring

  systemd.conf 2015 is a cooperation of the systemd community and
  LinuxTag e. V. as organizing host.

  We are seeking corporate partners to help us create the best
  conference possible. Please visit
  https://systemd.events/systemdconf-2015/become-sponsor for more
  information on sponsoring systemd.conf 2015.

 Lennart

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

Re: [systemd-devel] Minimum required gcc version?

[Umut Tezduyar Lindskog]

For the reference, this problem is tracked @
https://github.com/systemd/systemd/issues/406

On Thu, Jun 18, 2015 at 5:34 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 18.06.15 17:33, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

 Hi,

 On Thu, Jun 18, 2015 at 03:20:04PM +0200, Lennart Poettering wrote:
  On Thu, 18.06.15 14:29, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
   Do we have a minimum required gcc version? The README just lists gcc
   without any version. However the current git fails to build with gcc-4.7:
   In this version, gcc produces -Wshadow warnings for variables with the 
   same
   name as a defined function (e.g. 'now' in several functions in
   src/core/device.c). This results in build errors because we compile with
   -Werror=shadow now.
 
  Hm, yuck. I figure we could add that only for gcc versions newer than
  that, with a configure check...
 
  or can't you add a -Wno-shadow to CFLAGS on the configure cmdline,
  overriding what we set there?

 I can easily work around this issue with cc_cv_CFLAGS__Werror_shadow=no in
 the environment for configure. I just wanted to report this in case you
 care about gcc-4.7.

 Well, it's easy enough to care for it I think in this case. If you
 send me a patch that conditionalizes this in the configure script
 depending on the gcc version I'd be willing to merge it.

 Lennart

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

Re: [systemd-devel] Getting boot progress and messages

[Umut Tezduyar Lindskog]

You can use PID 1's DBUS API -
http://www.freedesktop.org/wiki/Software/systemd/dbus/. Particularly
you should be interested in NJobs and Progress property.

Since it is too late to wait for DBus to come up you need to connect
to systemd directly (instead of going through dbus-daemon). The socket
you need to connect is /run/systemd/private
(http://www.freedesktop.org/software/systemd/man/systemd.html).

IMPORTANT: Man page says This interface is private to systemd and
should not be used in external projects. for /run/systemd/private. I
am not sure if this is still the case. If not, we need to change the
man page.

Umut

On Wed, Jun 24, 2015 at 10:40 AM, Thomas Schmidt
t.schm...@md-network.de wrote:
 Hello,
 for embedded system I’m writing small boot splash/progress bar daemon 
 (unfortunately plymouth doesn’t fit). Even after study of especially sd_.*(3) 
 manuals, mail archives, and source code it is not clear for me what could be 
 the best way to obtain the boot messages and boot proceed from another 
 process.
 On DBus respective SDBus API required information is available, unfortunately 
 the BUS is activated very late.

 Could someone point me into the right direction which interface (e.g. 
 socket/fifo/other API) could be the right systemd conform way ?


 Many Thanks
 Kind Regards
 Thomas Schmidt
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Getting boot progress and messages

[Umut Tezduyar Lindskog]

On Wed, Jun 24, 2015 at 11:53 AM, Daniel Mack dan...@zonque.org wrote:
 On 06/24/2015 11:30 AM, Umut Tezduyar Lindskog wrote:
 IMPORTANT: Man page says This interface is private to systemd and
 should not be used in external projects. for /run/systemd/private. I
 am not sure if this is still the case.

 Yes it is. The private socket is a hack that will go away mid-term when
 kdbus is fully adopted. If you still use it from external projects,
 prepare to rework the affected bits in the future.

Good to know Daniel. Thomas, you can always use systemctl to retrieve
these values if you don't care about the overhead. It is systemctl
connecting to the private socket.


 If not, we need to change the man page.

 Nope, it should stay in. The private socket is not an API that is
 guaranteed to remain available.


 Thanks,
 Daniel

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

[systemd-devel] feedback on sd-bus

[Umut Tezduyar Lindskog]

Hi,

We recently have reimplemented a central component of our software
stack with sd-bus and the results are very satisfactory. Though, we
have some feedback to discuss.

The reimplemented component is a glib based application. For this
reason, we have integrated GMain with sd-event (using Tom's sample
code). We are aware of the fact that sd-bus is relatively lower level
than gdbus.

- Auto generation tool coming with gdbus (gio) is priceless. Without
the tool, packing/upacking messages are time consuming.

- Reference counting on the bus messages needs to be handled by the
API user which is not that difficult but error prone. Again, maybe
some kind of auto generation tool can help us out. Which brings up
another question which is why are cleanup macros not public?

- A simple proxy object is needed. Simple proxy is needed to figure
out when proxy is online/offline. The current properties of the proxy
and getting events when the properties are changed. By default
creating gdbus proxy is expensive in a way that it starts the proxy,
loads properties etc (All of this can be turned off with flags
though). Maybe systemd's proxy can do all of it in a on-demand way by
default.

- Lennart's sd-bus introduction blog recommends the usage of gdbus if
the application is a glib application. I couldn't understand the
reason for this. We have all the hooks to integrate sd-event with
glib.

- Previously we opened a ticket about the under performing glib
(https://bugzilla.gnome.org/show_bug.cgi?id=749533). There are two
biggies mentioned in the ticket for the under performance. AFAIK,
sd-bus is also using gvariant, so that is not relevant. The other
issue is extra context switch on gdbus which doesn't seem to be
something easy to get rid of. Where does this leave us? A) Use high
level bus implementation with performance penalty, B) Use low level
bus implementation with the penalty of going lower level. Isn't it
possible to either get gdbus close to sd-bus or sd-bus close to gdbus?

Feedback is appreciated,
Umut
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sd-bus vs glib object path node hierarchy

[Umut Tezduyar Lindskog]

Hi,

I have noticed that glib vs sd-bus have different hierarchy in terms
of how objects are stacked. I don't have any argument why one or the
other one would be better but I was wondering what the reason for this
difference.

/com/a/b registered with sd_bus_add_object_vtable
Introspection:
└─/com/a/b

/com/a/b registered with glib
Introspection:
└─/com
  └─/com/a
└─/com/a/b

Umut
___
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

[Umut Tezduyar Lindskog]

On Mon, Jun 1, 2015 at 8:12 PM, 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.

 In recent months, keeping up with the mailing-list has become more and
 more cumbersome, with many of us missing mails or unable to keep up
 with the traffic. To make sure all community requests and patches will
 get handled in time, we're now trying out the github infrastructure.
 We encourage everyone in the development community to switch over now,
 even though the old fd.o infrastructure will still be maintained.
 Distributions are free to wait until the next release announcement
 before updating anything.

Does it mean that we should stop sending patches to the ML, instead we
should do it through the git? Also, there are some patches in the ML
that haven't been merged. Will you guys take care of it or should we
send them over github?

Umut


 If github does not work out, we will see what else we can try out. But
 lets give it at least a try.

 Thanks
 David

 [1] https://github.com/systemd-devs/systemd
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 6:25 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
  lenn...@poettering.net wrote:
   On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) 
   wrote:
  
   Hi,
  
   I was wondering if we have a way to provide vendor default masked
   service?
  
   Well, so far our thinking was that if the vendor wants to make a unit
   completely unavailable he should simply not ship it in the first
   place.
  
   What's the usecase for a vendor masking a unit, but installing it? Why
   not remove it in the first place entirely?
 
  If we ship a product without the service, we don't have a way of
  installing it again once the product is deployed.
 
  Use case would be: We use one software for a video encoder blade with
  multiple CPUs. Every CPU runs the same software. We have a special
  service which should only run on the first CPU. A generator installs
  the .wants link for the service on first CPU. Another service could
  try to talk to the special service over dbus causing it to be dbus
  activated (where special service is only allowed to be up on first
  CPU). We could install the dbus activation files with generator but it
  gets messy to offload this logic to a generator. Also, special service
  can be activated by using systemd's dbus interface.
 
  My recommendation would be to ship the dbus service file always, but
  make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
  and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
  to the real bus service. All you do in your generator now is create
  the symlink or not create it...
 
  Wouldn't that work?

 For dbus activation it would work but other services can still
 activate the service through systemd.

 But why is that a problem? If daemons explicitly request another
 service by invoking StartUnit() via the bus, why block this off in
 your usecase?

I think you are right. As long as we can stop the service from being
bus/socket activated (which we can), we should be good. Really not
much to do for explicit requests.

Our software has to interpret activation failure messages coming from
dbus [1] somehow to service shouldn't be started. I am guessing we
should also be future compatible that these messages will come from
someone else with kdbus or?

[1] - sender=org.freedesktop.DBus destination=:1.57 object=n/a
interface=n/a member=n/a cookie=3 reply_cookie=2 error=Unit
dbus-com.axis.PrioritizedTextOverlay.service failed to load: No such
file or directory.

Umut


 I can understand you don't want implicit activation via socket, boot,
 bus but that's all easily managable via systemctl disable and
 systemctl enable. What am I missing?

 Lennart

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

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

[Umut Tezduyar Lindskog]

On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov arvidj...@gmail.com wrote:
 On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
 u...@tezduyar.com wrote:
  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?

 If you do not use D-Bus daemon systemd will be listening on private
 socket. In this case the only check it does is that peer runs as UID=0
 (note - not EUID, so suid does not really help).
 I think with or without dbus systemd listens on the private socket
 (/run/systemd/private).

 No, private socket is used only as fallback when full D-Bus is not available.

I don't think so.

root@lnxumuttl:/home/umuttl/Development# strace -f systemctl 21 | grep connect
connect(3, {sa_family=AF_LOCAL, sun_path=/run/systemd/private}, 22) = 0
root@lnxumuttl:/home/umuttl/Development# systemctl status dbus
● dbus.service - D-Bus System Message Bus
   Loaded: loaded (/lib/systemd/system/dbus.service; static)
   Active: active (running) since Tue 2015-05-26 16:43:56 CEST; 2 days ago
 Docs: man:dbus-daemon(1)
 Main PID: 967 (dbus-daemon)
   CGroup: /system.slice/dbus.service
   └─967 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-bus: make sure type=error messages are also dumped

[Umut Tezduyar Lindskog]

---
 src/libsystemd/sd-bus/sd-bus.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index edc27ae..a6096f9 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -49,6 +49,17 @@
 #include bus-track.h
 #include bus-slot.h
 
+#define log_debug_bus_message(m) log_debug(Got message type=%s sender=%s 
destination=%s object=%s interface=%s member=%s cookie=% PRIu64  
reply_cookie=% PRIu64  error=%s, \
+  bus_message_type_to_string(m-header-type), \
+  strna(sd_bus_message_get_sender(m)), \
+  strna(sd_bus_message_get_destination(m)), \
+  strna(sd_bus_message_get_path(m)), \
+  strna(sd_bus_message_get_interface(m)), \
+  strna(sd_bus_message_get_member(m)), \
+  BUS_MESSAGE_COOKIE(m), \
+  m-reply_cookie, \
+  strna(m-error.message))
+
 static int bus_poll(sd_bus *bus, bool need_more, uint64_t timeout_usec);
 static int attach_io_events(sd_bus *b);
 static void detach_io_events(sd_bus *b);
@@ -2006,8 +2017,10 @@ _public_ int sd_bus_call(
 
 r = sd_bus_error_setf(error, 
SD_BUS_ERROR_INCONSISTENT_MESSAGE, Reply message contained file descriptors 
which I couldn't accept. Sorry.);
 
-} else if (incoming-header-type == 
SD_BUS_MESSAGE_METHOD_ERROR)
+} else if (incoming-header-type == 
SD_BUS_MESSAGE_METHOD_ERROR) {
+log_debug_bus_message(incoming);
 r = sd_bus_error_copy(error, 
incoming-error);
+}
 else
 r = -EIO;
 
@@ -2480,16 +2493,7 @@ static int process_message(sd_bus *bus, sd_bus_message 
*m) {
 bus-current_message = m;
 bus-iteration_counter++;
 
-log_debug(Got message type=%s sender=%s destination=%s object=%s 
interface=%s member=%s cookie=% PRIu64  reply_cookie=% PRIu64  error=%s,
-  bus_message_type_to_string(m-header-type),
-  strna(sd_bus_message_get_sender(m)),
-  strna(sd_bus_message_get_destination(m)),
-  strna(sd_bus_message_get_path(m)),
-  strna(sd_bus_message_get_interface(m)),
-  strna(sd_bus_message_get_member(m)),
-  BUS_MESSAGE_COOKIE(m),
-  m-reply_cookie,
-  strna(m-error.message));
+log_debug_bus_message(m);
 
 r = process_hello(bus, m);
 if (r != 0)
-- 
2.1.4

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

[systemd-devel] [PATCH] shared: do not include aux_h if it is off

[Umut Tezduyar Lindskog]

---
 src/shared/random-util.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/shared/random-util.c b/src/shared/random-util.c
index 88f5182..b230044 100644
--- a/src/shared/random-util.c
+++ b/src/shared/random-util.c
@@ -23,7 +23,9 @@
 #include sys/stat.h
 #include fcntl.h
 #include time.h
+#ifdef HAVE_SYS_AUXV_H
 #include sys/auxv.h
+#endif
 #include linux/random.h
 
 #include random-util.h
-- 
2.1.4

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

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  I was wondering if we have a way to provide vendor default masked
  service?
 
  Well, so far our thinking was that if the vendor wants to make a unit
  completely unavailable he should simply not ship it in the first
  place.
 
  What's the usecase for a vendor masking a unit, but installing it? Why
  not remove it in the first place entirely?

 If we ship a product without the service, we don't have a way of
 installing it again once the product is deployed.

 Use case would be: We use one software for a video encoder blade with
 multiple CPUs. Every CPU runs the same software. We have a special
 service which should only run on the first CPU. A generator installs
 the .wants link for the service on first CPU. Another service could
 try to talk to the special service over dbus causing it to be dbus
 activated (where special service is only allowed to be up on first
 CPU). We could install the dbus activation files with generator but it
 gets messy to offload this logic to a generator. Also, special service
 can be activated by using systemd's dbus interface.

 My recommendation would be to ship the dbus service file always, but
 make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
 and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
 to the real bus service. All you do in your generator now is create
 the symlink or not create it...

 Wouldn't that work?

For dbus activation it would work but other services can still
activate the service through systemd.

Umut


 Lennart

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

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 2:15 PM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
 On 28 May 2015 at 12:56, Umut Tezduyar Lindskog u...@tezduyar.com wrote:
 On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  I was wondering if we have a way to provide vendor default masked
  service?
 
  Well, so far our thinking was that if the vendor wants to make a unit
  completely unavailable he should simply not ship it in the first
  place.
 
  What's the usecase for a vendor masking a unit, but installing it? Why
  not remove it in the first place entirely?

 If we ship a product without the service, we don't have a way of
 installing it again once the product is deployed.

 Use case would be: We use one software for a video encoder blade with
 multiple CPUs. Every CPU runs the same software. We have a special
 service which should only run on the first CPU. A generator installs
 the .wants link for the service on first CPU. Another service could
 try to talk to the special service over dbus causing it to be dbus
 activated (where special service is only allowed to be up on first
 CPU). We could install the dbus activation files with generator but it
 gets messy to offload this logic to a generator. Also, special service
 can be activated by using systemd's dbus interface.

 My recommendation would be to ship the dbus service file always, but
 make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
 and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
 to the real bus service. All you do in your generator now is create
 the symlink or not create it...

 Wouldn't that work?

 For dbus activation it would work but other services can still
 activate the service through systemd.

 it will attempt to dbus activate non-existing service file since
 there wouldn't be a symlink with a name
 dbus-com.axis.foobar.waldi.service pointing to anything real, and thus
 effectively masked, no?!
Nope. They can call StartUnit (org.freedesktop.systemd1,
/org/freedesktop/systemd1) or systemctl start.
Umut

 --
 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] regression: crashing journal due to watchdog

[Umut Tezduyar Lindskog]

Hi,

The for (;;) loop in server_process_datagram might prevent journal
from feeding the watchdog if there is always something to receive in
the syslog socket. Potentially journald is restarted, applications
stall if the syslog socket is staying full

I thought about fixing it by checking the watchdog on every iteration
of for (;;) by using watchdog_last, watchdog_period and feeding
watchdog if necessary but none of those properties are public.

Current rate limit check is done right before we store the message
(after we receive it, after we forward it to console, wall, kmsg). I
think it is too late.

Maybe the best approach is having a rate limit on sd-event
(sd-event-source) so we can map rate limit options in journald.conf to
journal's sd-event.

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

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 I was wondering if we have a way to provide vendor default masked
 service?

 Well, so far our thinking was that if the vendor wants to make a unit
 completely unavailable he should simply not ship it in the first
 place.

 What's the usecase for a vendor masking a unit, but installing it? Why
 not remove it in the first place entirely?

If we ship a product without the service, we don't have a way of
installing it again once the product is deployed.

Use case would be: We use one software for a video encoder blade with
multiple CPUs. Every CPU runs the same software. We have a special
service which should only run on the first CPU. A generator installs
the .wants link for the service on first CPU. Another service could
try to talk to the special service over dbus causing it to be dbus
activated (where special service is only allowed to be up on first
CPU). We could install the dbus activation files with generator but it
gets messy to offload this logic to a generator. Also, special service
can be activated by using systemd's dbus interface.

Umut

 Lennart

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

Re: [systemd-devel] [PATCH] cgtop: raw output option (disable conversion to human-readable units)

[Umut Tezduyar Lindskog]

Hi Charles,

We have done something similar to this with the cpu accounting. The
option is --cpu=TYPE (There is also hidden key '%' on the tty output
which toggles between different display modes). If this patch will be
taken I think we should be consistent. Maybe something like --io=TYPE
or --memory=TYPE.

Umut

On Fri, May 22, 2015 at 11:56 PM, Charles Duffy char...@dyfis.net wrote:
 From: Charles Duffy chadu...@cisco.com

 ---
  src/cgtop/cgtop.c | 28 ++--
  1 file changed, 22 insertions(+), 6 deletions(-)

 diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
 index a390cf3..0dbac7f 100644
 --- a/src/cgtop/cgtop.c
 +++ b/src/cgtop/cgtop.c
 @@ -62,6 +62,7 @@ typedef struct Group {
  static unsigned arg_depth = 3;
  static unsigned arg_iterations = 0;
  static bool arg_batch = false;
 +static bool arg_raw = false;
  static usec_t arg_delay = 1*USEC_PER_SEC;

  static enum {
 @@ -533,15 +534,24 @@ static int display(Hashmap *a) {
  printf( %*s, maxtcpu, format_timespan(buffer, 
 sizeof(buffer), (nsec_t) (g-cpu_usage / NSEC_PER_USEC), 0));

  if (g-memory_valid)
 -printf( %8s, format_bytes(buffer, sizeof(buffer), 
 g-memory));
 +if(arg_raw) {
 +printf( %8ld, g-memory);
 +} else {
 +printf( %8s, format_bytes(buffer, 
 sizeof(buffer), g-memory));
 +}
  else
  fputs(-, stdout);

  if (g-io_valid) {
 -printf( %8s,
 -   format_bytes(buffer, sizeof(buffer), 
 g-io_input_bps));
 -printf( %8s,
 -   format_bytes(buffer, sizeof(buffer), 
 g-io_output_bps));
 +if(arg_raw) {
 +printf( %8ld, g-io_input_bps);
 +printf( %8ld, g-io_output_bps);
 +} else {
 +printf( %8s,
 +   format_bytes(buffer, sizeof(buffer), 
 g-io_input_bps));
 +printf( %8s,
 +   format_bytes(buffer, sizeof(buffer), 
 g-io_output_bps));
 +}
  } else
  fputs(--, stdout);

 @@ -561,6 +571,7 @@ static void help(void) {
   -c  Order by CPU load\n
   -m  Order by memory load\n
   -i  Order by IO load\n
 + -r  Provide raw (not human-readable) 
 numbers\n
  --cpu[=TYPE] Show CPU usage as time or percentage 
 (default)\n
   -d --delay=DELAYDelay between updates\n
   -n --iterations=N   Run for N iterations before exiting\n
 @@ -583,6 +594,7 @@ static int parse_argv(int argc, char *argv[]) {
  { delay,  required_argument, NULL, 'd' },
  { iterations, required_argument, NULL, 'n' },
  { batch,  no_argument,   NULL, 'b' },
 +{ raw,no_argument,   NULL, 'r' },
  { depth,  required_argument, NULL, ARG_DEPTH   },
  { cpu,optional_argument, NULL, ARG_CPU_TYPE},
  {}
 @@ -594,7 +606,7 @@ static int parse_argv(int argc, char *argv[]) {
  assert(argc = 1);
  assert(argv);

 -while ((c = getopt_long(argc, argv, hptcmin:bd:, options, NULL)) 
 = 0)
 +while ((c = getopt_long(argc, argv, hptcmin:brd:, options, NULL)) 
 = 0)

  switch (c) {

 @@ -649,6 +661,10 @@ static int parse_argv(int argc, char *argv[]) {
  arg_batch = true;
  break;

 +case 'r':
 +arg_raw = true;
 +break;
 +
  case 'p':
  arg_order = ORDER_PATH;
  break;
 --
 2.0.0

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

[systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

Hi,

I was wondering if we have a way to provide vendor default masked service?

Vendor default masked service has advantages like:
 - systemctl start won't work
 - dbus activation won't work

It is common that an embedded system doesn't use packages, rather it
ships everything in monolithic image. Enabling, disabling, presetting
is great to prevent a service from starting as part of the target but
it doesn't stop anyone trying to start it with systemd (systemctl
start, or dbus activation).

I have come up with my way but obviously systemctl unmask doesn't
mean anything in this case. I was wondering if there is a way I am not
aware of.

/usr/lib/systemd/system:
aa.service: Service file implementation
a.target.wants/a.service: Start the service with a.target.
a.service: Can either be a link to aa.service (start the service) or
/dev/null (service is masked, won't start).

If the service is masked (a.service - /dev/null), to enable it we
need to create (/etc/systemd/system/a.service -
/usr/lib/systemd/system/aa.service).

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

[systemd-devel] [PATCH] nspawn: be verbose about interface names

[Umut Tezduyar Lindskog]

Allowed interface name is relatively small. Lets not make
users go in to the source code to figure out what happened.

--machine=debian-tree conflicts with
--machine=debian-tree2

ex: Failed to add new veth \
 interfaces (host0, vb-debian-tree): File exists
---
 src/nspawn/nspawn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 5009363..646edea 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2627,7 +2627,7 @@ static int setup_veth(pid_t pid, char 
iface_name[IFNAMSIZ], int *ifi) {
 
 r = sd_rtnl_call(rtnl, m, 0, NULL);
 if (r  0)
-return log_error_errno(r, Failed to add new veth interfaces: 
%m);
+return log_error_errno(r, Failed to add new veth interfaces 
(host0, %s): %m, iface_name);
 
 i = (int) if_nametoindex(iface_name);
 if (i = 0)
-- 
2.1.4

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

Re: [systemd-devel] tentative state and unmount on mapper

[Umut Tezduyar Lindskog]

On Mon, May 18, 2015 at 3:59 PM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
 Hi,

 There have been few discussions about tentative state and unmounting
 and I am experiencing different problem in the same device logic.

 I am at 219 + 628c89cc + 496068a8 + 5259bcf6

 I have 2 mounts (one is bind mount) on mapper device.

 /proc/self/mountinfo:
 47 37 254:0 / /var/spool/storage/SD_DISK
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered

 systemctl -t device --all | grep map:
 dev-mapper-mmcblk0p1.device   loaded activating tentative 
 /dev/mapper/mmcblk0p1

 As soon as I unmount the bind mount, systemd picks up the change in
 /proc/self/mountinfo and changes the tentative device to dead and
 due to that all file systems BindsTo to the device are being
 unmounted. Application which mounted the partitions is not getting a
 chance to unmount the fs.

 Should I enumerate available mount units to see if anyone else has
 been mounted on the device that is about to be set as DEVICE_DEAD in
 device_update_found_one()?

For the achieve purpose, Lennart has implemented something similar at
394763f6 and fcd8b266. Things have worked for me. But the proper
solution is enabling udev awareness for DM/LVM.

Umut


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

Re: [systemd-devel] tentative state and unmount on mapper

[Umut Tezduyar Lindskog]

On Mon, May 18, 2015 at 11:02 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 18.05.15 15:59, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 There have been few discussions about tentative state and unmounting
 and I am experiencing different problem in the same device logic.

 I am at 219 + 628c89cc + 496068a8 + 5259bcf6

 I have 2 mounts (one is bind mount) on mapper device.

 /proc/self/mountinfo:
 47 37 254:0 / /var/spool/storage/SD_DISK
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
 rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered

 systemctl -t device --all | grep map:
 dev-mapper-mmcblk0p1.device   loaded activating tentative 
 /dev/mapper/mmcblk0p1

 As soon as I unmount the bind mount, systemd picks up the change in
 /proc/self/mountinfo and changes the tentative device to dead and
 due to that all file systems BindsTo to the device are being
 unmounted. Application which mounted the partitions is not getting a
 chance to unmount the fs.

 Should I enumerate available mount units to see if anyone else has
 been mounted on the device that is about to be set as DEVICE_DEAD in
 device_update_found_one()?

 The right fix is to ensure you ship the right udev rules for your DM
 setup, so that the devices are properly announced by udev. Note that
 DM/LVM/... might require compile switches to be specified to enable
 proper udev support.

 The tentative state is nothing the system should continously leave
 devices in. It's a state only used for very short time windows, before
 udev is up, or when a pseudo device (like a loopback block device) is
 created and immediately mounted. If you have booted up and see a
 device in tentative state, then something is really *wrong*.

 Lennart

- Isn't there a race in that short time window that if one tries to
unmount stuff, things might go south!

- If tentative is just a temporary state, than maybe we shouldn't send
the StartupFinished signal until device goes to plugged or dead state.

- Seems like poky is enabling udev rules for DM. Maybe we should add
required switches on README file to make DM work. So far I found
CONFIG_DM_UEVENT on kernel and some switches on lvm,
--enable-udev_sync, --enable-udev_rules, --with-udev-prefix=.

Umut


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

Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts

[Umut Tezduyar Lindskog]

On Tue, May 19, 2015 at 1:56 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 19.05.15 10:23, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,

 I have a better fix now.

  So the problem is that this tentative → dead transition only works if
  a device is referenced once, but causes overzealous unmounts if there
  are more references.

 Ah, indeed, that makes sense!

  We need a reference count, or check if the device is bound by other
  device still. Come to think of it now, we actually already have that:
 
Id=dev-foo.device
BoundBy=tmp-boot.mount tmp-etc.mount
 
  But my patch doesn't take that into account yet.

 This one does now. I left a fairly comprehensive commit log as this
 isn't that easy to explain/understand. If it's too verbose for you I
 can also trim it back a bit.

 I have now committed a different fix now, that keeps counting of the
 mount points in mount.c, instead of reaching over from device.c.

 I only gave this light testing, would be cool if you could check if
 this fixes things for you.

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

 This commit will now collect two sets of devices while going through
 /proc/self/mountinfo: the devices of lines that are no longer there,
 and the devices of lines that are there. Only for devices in the
 former set that are not in the latter we will now propagate an event
 to device.c.

 Does this make sense?

 +/* If we found a tentative device via mountinfo which is still
 + * referenced by other mounts than the one that just got unmounted, 
 we
 + * must leave it FOUND_MOUNT/tentative; otherwise we'd trigger
 + * unmounting of all other bound mounts. */
 +if (d-found == DEVICE_FOUND_MOUNT  n == 0) {
 +Iterator i;
 +Unit *bound;
 +
 +SET_FOREACH(bound, UNIT(d)-dependencies[UNIT_BOUND_BY], i) 
 {
 +if (bound-type == UNIT_MOUNT 
 +MOUNT(bound)-state != MOUNT_DEAD  
 MOUNT(bound)-state != MOUNT_FAILED) {
 +log_unit_debug(UNIT(d), Still bound by %s 
 (%s), keeping state.,
 +   bound-id, 
 mount_state_to_string(MOUNT(bound)-state));
 +return;
 +}
 +}
 +log_unit_debug(UNIT(d), Not referenced by any mounts any 
 more, changing to dead.);
 +}
 +
  previous = d-found;
  d-found = n;

 Lennart

Didn't work for me. Removed device doesn't go in to either cases, so
it never makes it to the around set but it makes it to gone set.

if (!mount-is_mounted)
{

}
else if (mount-just_mounted || mount-just_changed)
{

}

Umut


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

[systemd-devel] tentative state and unmount on mapper

[Umut Tezduyar Lindskog]

Hi,

There have been few discussions about tentative state and unmounting
and I am experiencing different problem in the same device logic.

I am at 219 + 628c89cc + 496068a8 + 5259bcf6

I have 2 mounts (one is bind mount) on mapper device.

/proc/self/mountinfo:
47 37 254:0 / /var/spool/storage/SD_DISK
rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
/dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
/dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered

systemctl -t device --all | grep map:
dev-mapper-mmcblk0p1.device   loaded activating tentative /dev/mapper/mmcblk0p1

As soon as I unmount the bind mount, systemd picks up the change in
/proc/self/mountinfo and changes the tentative device to dead and
due to that all file systems BindsTo to the device are being
unmounted. Application which mounted the partitions is not getting a
chance to unmount the fs.

Should I enumerate available mount units to see if anyone else has
been mounted on the device that is about to be set as DEVICE_DEAD in
device_update_found_one()?

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

Re: [systemd-devel] sd-bus vs gdbus on dbus-daemon

[Umut Tezduyar Lindskog]

On Thu, Apr 30, 2015 at 11:13 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
 Hi Simon,

 On Wed, Apr 29, 2015 at 5:34 PM, Simon McVittie
 simon.mcvit...@collabora.co.uk wrote:
 On 29/04/15 15:08, Umut Tezduyar Lindskog wrote:
 We [1] have noticed that there could be up to %50 performance gain on
 using sd-bus over gdbus on dbus-daemon.
 ...
 gdbus.c
   - g_dbus_proxy_new_for_bus_sync()
   - 50 x g_dbus_proxy_call_sync()

 sdbus.c
   - sd_bus_open_system()
   - 50 x sd_bus_get_property()

 If you want to compare apples with apples, I suggest using the
 lower-level g_bus_get() and g_dbus_connection_call[_sync]() instead of
 GDBusProxy. The design and priorities of sd-bus and GDBus are not really
 very similar, but GDBusProxy is certainly not the closest equivalent you
 can get.

 Thanks for the tip. I will re-run the measurements with
 g_dbus_connection_call_sync(g_bus_get_sync(),...). Just considering
 the traffic in the dbus, I do believe we have compared apple to apple.
 But if you believe we might get even more performance with raw API
 calls, then that is fantastic news!

Unfortunately I didn't get any better result with
g_dbus_connection_call_sync. I have updated the link
(https://drive.google.com/open?id=1O3FEnpdZ2auisYalKT6qJTiNV9cfDxya_qisbpGj3MQauthuser=0)
with the source code if you would like to double check my work.

Umut



 Also, if your application profile is such that (a) D-Bus is a
 significant factor in performance, and (b) sending 50 synchronous D-Bus
 messages per connection is anywhere near realistic, then you are
 probably not using D-Bus the way it is designed to be used.

 Measurement we have done was not about if dbus is the ipc we want or
 not. It was about comparing the performances of two libraries. It
 wouldn't have been fair to compare sending only 1 message on the dbus
 due to the performance penalty of creating a worker thread with gdbus.
 But it really didn't matter. 1, 2, 10, 50, in all cases gdbus
 (GDBusProxy) couldn't performed as good as sd-bus.


 See also http://permalink.gmane.org/gmane.comp.freedesktop.dbus/13663.

 --
 Simon McVittie
 Collabora Ltd. http://www.collabora.com/

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

Re: [systemd-devel] sd-bus vs gdbus on dbus-daemon

[Umut Tezduyar Lindskog]

Hi Greg,

On Wed, Apr 29, 2015 at 5:49 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Wed, Apr 29, 2015 at 04:08:50PM +0200, Umut Tezduyar Lindskog wrote:
 Hi,

 We [1] have noticed that there could be up to %50 performance gain on
 using sd-bus over gdbus on dbus-daemon. For this reason, we have high
 interest in using sd-bus. What are the plans in terms of making sd-bus
 API public?

 Details of the test [2]:

 gdbus.c
   - g_dbus_proxy_new_for_bus_sync()
   - 50 x g_dbus_proxy_call_sync()

 sdbus.c
   - sd_bus_open_system()
   - 50 x sd_bus_get_property()

 Two applications are run with ltrace, perf stat -e cycles, time
 and the results are compared.

 I'll echo Simon's statement here, making a call to
 g_dbus_proxy_call_sync() seems like an odd thing to test.  Is this
 really how your application wants to work?  Is it the normal call path
 that you need optimized?  How many messages do you normally send, or
 want to send, and how big of the data blob are you wanting to
 transmit/receive here?

We have variety of dbus clients sending small/big slow/fast sync/async
messages. But we have not focused on dbus's performance in the
experiment. We wanted to see the efficiency of 2 user space libraries
when it comes to a very simple use case (synchronously retrieving a
property).


 I ask as I'm trying to find how people would like to use D-Bus, if the
 existing dbus-daemon were sped up in various ways.

 Both of these traces show that userspace is sitting around for most of
 the time, I don't see a whole lot of actual CPU usage happening, do you?

Could you please explain how did you come up with that conclusion?
Granted not the top 10 calls are in g... libraries but there are many
entries that program has spent time in g... library. Also the pthread.

Umut


 thanks,

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

[systemd-devel] sd-bus vs gdbus on dbus-daemon

[Umut Tezduyar Lindskog]

Hi,

We [1] have noticed that there could be up to %50 performance gain on
using sd-bus over gdbus on dbus-daemon. For this reason, we have high
interest in using sd-bus. What are the plans in terms of making sd-bus
API public?

Details of the test [2]:

gdbus.c
  - g_dbus_proxy_new_for_bus_sync()
  - 50 x g_dbus_proxy_call_sync()

sdbus.c
  - sd_bus_open_system()
  - 50 x sd_bus_get_property()

Two applications are run with ltrace, perf stat -e cycles, time
and the results are compared.

[1] - Most of the work is done by Jonatan Nilsson, I have added minor points.
[2] - Full implementation details -
https://drive.google.com/open?id=1O3FEnpdZ2auisYalKT6qJTiNV9cfDxya_qisbpGj3MQauthuser=0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] 628c89cc (tentative devices) + disk/by-label udev rule

[Umut Tezduyar Lindskog]

It is not uncommon that file systems have the same volume label,
especially on flash drives. disk/by-label udev rule in
60-persistent-storage.rules generates a symb link to the device. 2
devices might have the same label link if they have same label.

After 628c89cc, this becomes very visible with Device
dev-disk-by\x2dlabel-Axis.device appeared twice with different sysfs
paths  error message.

The LABEL field of the volumes are relatively short (11 char on vfat,
16 on ext4). It won't be unique.

How can we solve it? What is the purpose of the disk/by-label rule?
Who uses that device node?

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

Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

[Umut Tezduyar Lindskog]

My two cents is feature can be implemented as long as we get support
from the application. For example sd-event has the builtin support to
quit when it is idle. Systemd can pass the exit-on-idle timeout to the
application via env variables so the event loop can configure itself
to quit.

I am not sure if glib event loop has this functionality already but I
would be very interested to have it. I am just waiting for kdbus.
Exiting on non-kdbus is still racy if we don't let systemd know
upfront.

Umut

On Mon, Apr 20, 2015 at 5:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote:

 If a service does not consume CPU during some time(can be configured
 by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the
 service will be stopped. This can be useful if the service provides
 some of activation methods.

 Hmm, I am not convinced this would be a good idea, sorry.

 The crux of the issue is that it is really hard to detect from the
 outside if a daemon is really idle. Only the daemon itself knows
 whether it is truly idle or not. I mean, it could just be waiting for
 some timer to elapse, or some other external event.

 I doubt this is really useful unless you have really really simple
 daemons that purely react on client requests and nothing else, and you
 know the codebase and that it is OK to terminate the daemon just
 because its CPU usage is zero. But if you know the codebase that well
 it would probably be a better idea to just add support for
 exit-on-idle directly to the daemon in question.

 exit-on-idle is really something that should be implemented *in* the
 daemon, and not done externally!

 Sorry,

 Lennart

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

[systemd-devel] bootloader time on a non-EFI bootloader

[Umut Tezduyar Lindskog]

Hi,

I would like to pass the time it was spent in bootloader to systemd.
Is there a kernel command line to pass this information on non EFI
bootloader? Or is there an another way?

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

Re: [systemd-devel] journald on embedded systems

[Umut Tezduyar Lindskog]

Getting inspiration from what you are proposing, you can already forward
messages to a datagram socket (syslog). You could implement a program to
empty out the datagram socket and only write the messages you want. Syslog
format doesnt know anything about FIELD though. One down side of this
implementation is that your program will be woken up for every message
causing extra context switch.

Regardless off this, it is interesting to hear out the thoughts about
filtering. There have been discussions about per service filtering too.

Umut

On Friday, March 13, 2015, Chris Morgan chmor...@gmail.com wrote:

 Hello.

 I posted this,
 http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html,
 some time ago about tiered logging for embedded systems.

 The goal is to guarantee that the flash memory will last the duration
 of the product by carefully controlling who writes to it.

 I'm back looking at the issue and wanted to re-open the discussion.

 One approach that came up would be to set Storage=volatile, a limit
 of say 10MB for the journal size, and then write a separate program
 that would filter out the journal entries and write them to a file on
 a physical disk. The filtering portion is required as we are using the
 journal to persist some important information that we'd like to log.
 We'd also like to preserve high priority messages but don't mind if we
 lose low priority ones across reboots.

 An upside of the external program is that we can filter on both high
 priority messages as well as those with specific FIELD=value
 entries. Downside is a custom format file and can't use journalctl to
 search through it, no log rotation, no size limits etc.

 At the time there was some thought of putting this into journald
 itself. I'm wondering how that would fit given the desire to use more
 complicated matching to decide which entries were put into the
 persisted journal.

 If it would fit inside of journald I'd be willing to implement it but
 we would need to come up with a way to configure the filtering, where
 the files are persisted etc. The filtering is a new requirement since
 the last time this was discussed.

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

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

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Umut Tezduyar Lindskog]

Ok! I have another problem with pc files but I solve it downstream.
When I configure systemd with --configure=/usr and set the DESTDIR to
my host path, the pc files don't have the DESTDIR extension. I solve
it manually by 'sed'ding the files after installation. I thought maybe
your patch solves this problem too. Thanks!


On Thu, Mar 12, 2015 at 8:27 AM, Jeff Waugh j...@bethesignal.org wrote:
 On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
 u...@tezduyar.com wrote:
 What does this fix Jeff, could you please explain?

 Here's the relevant part of a pkg-config file produced during make:

 prefix=/usr
 exec_prefix=/usr
 libdir=/usr/lib
 includedir=/usr/include

 Versus during configure:

 prefix=/usr
 exec_prefix=/usr
 libdir=${exec_prefix}/lib
 includedir=${prefix}/include

 Which disproportionately affects cross-compiling and similar build situations.

 OpenWrt includes an equivalent change for kmod (which Lucas mentioned
 as I've submitted it upstream), and without an upstream change will
 have to carry one for systemd too.

 Finally, a supporting appeal to authority: If you check GNOME-land,
 practically all pkg-config files are generated at configure time. :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure

[Umut Tezduyar Lindskog]

What does this fix Jeff, could you please explain?

On Tue, Mar 10, 2015 at 7:04 PM, Jeff Waugh j...@bethesignal.org wrote:
 Generate pkg-config files during configure as God (Havoc) intended. This fixes
 all of systemd's pkg-config files when cross-compiling (and possibly other use
 cases).

 (Note: I might've missed some things to tidy up in Makefile.am, but not 100%
 sure.)

 Signed-off-by: Jeff Waugh j...@bethesignal.org
 ---
  Makefile.am  |  3 ---
  configure.ac | 10 ++
  2 files changed, 10 insertions(+), 3 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 3539e03..d2ebc81 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -6442,9 +6442,6 @@ man/%: man/%.in
  sysctl.d/%: sysctl.d/%.in
 $(SED_PROCESS)

 -%.pc: %.pc.in
 -   $(SED_PROCESS)
 -
  %.conf: %.conf.in
 $(SED_PROCESS)

 diff --git a/configure.ac b/configure.ac
 index 29111f5..21b8008 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1510,6 +1510,16 @@ AC_CONFIG_FILES([
  docs/libudev/version.xml
  docs/gudev/Makefile
  docs/gudev/version.xml
 +src/libudev/libudev.pc
 +src/compat-libs/libsystemd-id128.pc
 +src/compat-libs/libsystemd-daemon.pc
 +src/compat-libs/libsystemd-login.pc
 +src/compat-libs/libsystemd-journal.pc
 +src/libsystemd/sd-id128/libsystemd-id128.pc
 +src/libsystemd/libsystemd.pc
 +src/udev/udev.pc
 +src/core/systemd.pc
 +src/gudev/gudev-1.0.pc
  ])

  AC_OUTPUT
 --
 1.9.1

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

[systemd-devel] [PATCH] cgtop: fix assert when not on tty

[Umut Tezduyar Lindskog]

systemd-cgtop --dept=1 -b -n 10 -d 0.1 | cat

Assertion 'new_length = 3' failed at src/shared/util.c:3 \
595, function ellipsize_mem(). Aborting.
Aborted (core dumped)
---
 src/cgtop/cgtop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index 3c7ad40..46ba1aa 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -447,7 +447,7 @@ static int display(Hashmap *a) {
 Group *g;
 Group **array;
 signed path_columns;
-unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 0;
+unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 3;
 char buffer[MAX3(21, FORMAT_BYTES_MAX, FORMAT_TIMESPAN_MAX)];
 
 assert(a);
-- 
2.1.1

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

Re: [systemd-devel] Cleaning up transient scopes

[Umut Tezduyar Lindskog]

On Thu, Mar 5, 2015 at 12:00 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 04.03.15 18:51, Alexander Larsson (al...@redhat.com) wrote:

 If i run a transient scope on the user systemd instance like:

 $ systemd-run --user --scope true

 Then the scope seems to live past the end of the process. Is there any
 way to make it automatically go away with the last process in the
 cgroup?

 Well, yes, the idea is that that just works. However, this is kinda
 broken if the systemd instance managing your scope is not PID 1, as we
 don't get SIGCHLD then.

It has been broken for PID 1 too for some time,
https://bugs.freedesktop.org/show_bug.cgi?id=86520
Umut

 Do you create any subcgroups? presumably not?

 Normally it should just work then, but I must admit that --user scopes
 got much less testing that system scopes...

 Lennart

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

[systemd-devel] how to nest slices under system.slice

[Umut Tezduyar Lindskog]

Hi,

How do I add a slice that is inside the system.slice?

Following slice gets nested to -.slice where I want to nest it inside
system.slice (just like instantaneous service slices).

hello.slice
[Unit]
Description=hello slice

I tried following which produced the correct output with systemctl
show -p Slice hello.slice but the slice was still in the top level
hierarchy.

[Unit]
Description=hello slice
[Slice]
Slice=system.slice

# ls -al /sys/fs/cgroup/systemd/
drwxr-xr-x4 root root 0 Mar 14 05:35 hello.slice
drwxr-xr-x   89 root root 0 Mar 14 05:35 system.slice
...
...
-rw-r--r--1 root root 0 Mar 14 05:47 tasks
-rw-r--r--1 root root 0 Mar 14 05:35 release_agent

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

Re: [systemd-devel] Service watchdog feature in state ACTIVATING ?

[Umut Tezduyar Lindskog]

Hi Marko,

On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com
wrote:

 Hi,

 I ran into a use case where the activation phase of a service takes
 significantly longer than the desired watchdog period (Activating:
 10-20secs, Watchdog: 1-5secs).

 I found out that the watchdog features starts not before the service is in
 state START_POST. This means for my use case that the system is blind for
 10-20secs (whatever I set as startup timeout here).

 Is there any way to activate the watchdog feature already in phase
 ACTIVATING?


Why would you need this? Watchdog is to prevent system being stuck
somewhere. If activation fails within TimeoutStartSec=, systemd will put
the service in failed to activate state anyways.

Is waiting 20 seconds to detect the freeze is too much for your case? Is it
not possible to lower the activation time?

Umut


 I guess there should be a second watchdog configuration parameter to allow
 services to use different values for the states ACTIVATING and RUNING.
 Otherwise, people who are not interested in having a watchdog observation
 during startup will run into troubles ...

 Any opinions on that?


 Best regards

 Marko Hoyer

 Advanced Driver Information Technology GmbH
 Software Group II (ADITG/SW2)
 Robert-Bosch-Str. 200
 31139 Hildesheim
 Germany

 Tel. +49 5121 49 6948
 Fax +49 5121 49 6999
 mho...@de.adit-jv.com javascript:;

 ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car
 Multimedia GmbH and DENSO Corporation
 Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
 Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org javascript:;
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[systemd-devel] [PATCH] core: downgrade unit type not supported message

[Umut Tezduyar Lindskog]

Otherwise every daemon reload prints out warnings like:

systemd[1]: Unit type .busname is not supported on this system.
systemd[1]: Unit type .swap is not supported on this system.
---
 src/core/manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/manager.c b/src/core/manager.c
index 4775219..bc9b7ec 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -961,7 +961,7 @@ int manager_enumerate(Manager *m) {
 int q;
 
 if (unit_vtable[c]-supported  
!unit_vtable[c]-supported(m)) {
-log_info(Unit type .%s is not supported on this 
system., unit_type_to_string(c));
+log_debug(Unit type .%s is not supported on this 
system., unit_type_to_string(c));
 continue;
 }
 
-- 
2.1.1

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

Re: [systemd-devel] [PATCH] journald: Introduce RFC 5424 syslog

[Umut Tezduyar Lindskog]

Hi Susant,

On Thu, Feb 19, 2015 at 8:58 AM, Susant Sahani sus...@redhat.com wrote:
 This patch adds support for RFC 5424 syslog format to journald. Journald
 can now forward logs to a multicast UDP group.

 RFC 5424 format:
 PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP
 [SD-ID]s SP MSG

 Example conf:

 file: journald.conf
 SysLogAddress=239.0.0.1:6000
 ---
  Makefile.am   |   1 +
  man/journald.conf.xml |  12 ++
  src/journal/journald-gperf.gperf  |   1 +
  src/journal/journald-native.c |   3 +
  src/journal/journald-server.c |  40 +-
  src/journal/journald-server.h |  14 ++
  src/journal/journald-stream.c |   4 +
  src/journal/journald-syslog-network.c | 246 
 ++
  src/journal/journald-syslog.c |   3 +
  src/journal/journald-syslog.h |   2 +
  10 files changed, 325 insertions(+), 1 deletion(-)
  create mode 100644 src/journal/journald-syslog-network.c

 diff --git a/Makefile.am b/Makefile.am
 index ba63f68..b015f69 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4487,6 +4487,7 @@ libsystemd_journal_core_la_SOURCES = \
 src/journal/journald-kmsg.h \
 src/journal/journald-syslog.c \
 src/journal/journald-syslog.h \
 +   src/journal/journald-syslog-network.c \
 src/journal/journald-stream.c \
 src/journal/journald-stream.h \
 src/journal/journald-server.c \
 diff --git a/man/journald.conf.xml b/man/journald.conf.xml
 index 364b58f..4fb037b 100644
 --- a/man/journald.conf.xml
 +++ b/man/journald.conf.xml
 @@ -355,6 +355,18 @@
/varlistentry

varlistentry
 +termvarnameSysLogAddress=/varname/term
 +listitemparaControls whether log messages received by the
 +journal daemon shall be forwarded to a multicast UDP network
 +group in syslog RFC 5424 format./para
 +
 +paraThe the address string format is similar to socket units. See
Double the.
 +
 citerefentryrefentrytitlesystemd.socket/refentrytitlemanvolnum1/manvolnum/citerefentry
 +/para
 +/listitem
 +  /varlistentry
 +
 +  varlistentry
  termvarnameTTYPath=/varname/term

  listitemparaChange the console TTY to use if
 diff --git a/src/journal/journald-gperf.gperf 
 b/src/journal/journald-gperf.gperf
 index 74554c1..9cdffbc 100644
 --- a/src/journal/journald-gperf.gperf
 +++ b/src/journal/journald-gperf.gperf
 @@ -40,3 +40,4 @@ Journal.MaxLevelKMsg,   config_parse_log_level,  0, 
 offsetof(Server, max_lev
  Journal.MaxLevelConsole,config_parse_log_level,  0, offsetof(Server, 
 max_level_console)
  Journal.MaxLevelWall,   config_parse_log_level,  0, offsetof(Server, 
 max_level_wall)
  Journal.SplitMode,  config_parse_split_mode, 0, offsetof(Server, 
 split_mode)
 +Journal.SysLogAddress,  config_parse_syslog_network_address, 0, 
 offsetof(Server, syslog_addr)
 diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
 index 851625d..9fd370f 100644
 --- a/src/journal/journald-native.c
 +++ b/src/journal/journald-native.c
 @@ -273,6 +273,9 @@ void server_process_native_message(
  if (s-forward_to_syslog)
  server_forward_syslog(s, priority, identifier, 
 message, ucred, tv);

 +if (s-forward_to_network)
 +server_forward_syslog_network(s, priority, 
 identifier, message, ucred, tv);
 +
  if (s-forward_to_kmsg)
  server_forward_kmsg(s, priority, identifier, 
 message, ucred);

 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
 index 7ee8174..de4ef50 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
 @@ -86,7 +86,7 @@ static const char* const split_mode_table[_SPLIT_MAX] = {
  DEFINE_STRING_TABLE_LOOKUP(split_mode, SplitMode);
  DEFINE_CONFIG_PARSE_ENUM(config_parse_split_mode, split_mode, SplitMode, 
 Failed to parse split mode setting);

 -static uint64_t available_space(Server *s, bool verbose) {
 +uint64_t available_space(Server *s, bool verbose) {
  char ids[33];
  _cleanup_free_ char *p = NULL;
  sd_id128_t machine;
 @@ -1356,6 +1356,35 @@ static int server_parse_config_file(Server *s) {
   false, s);
  }

 +int config_parse_syslog_network_address(const char *unit,
 +const char *filename,
 +unsigned line,
 +const char *section,
 +unsigned section_line,
 +const char *lvalue,
 +int ltype,
 +const char *rvalue,
 +void *data,
 +void 

Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold

[Umut Tezduyar Lindskog]

For the reference, LTO doesn't work with systemd 218 on mips:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026326.html

On Wed, Feb 18, 2015 at 7:45 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 LTO may be unreliable, does not work properly in several archs
 It may crash or produce wrong code.

 Compiler developers also said we should not provide production
 RPM packages with LTO enabled.

 GOLD also does not work everywhere.
 ---
  configure.ac | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 9a2235b..38194ca 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -207,10 +207,15 @@ AS_CASE([$CC], [*clang*],
 -Wno-gnu-variable-sized-type-not-at-end \
  ])])

 -AS_CASE([$CFLAGS], [*-O[[12345\ ]]*],
 -[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
 -   -flto -ffat-lto-objects])],
 -[AC_MSG_RESULT([skipping -flto, optimization not enabled])])
 +AC_ARG_ENABLE([lto], AS_HELP_STRING([--disable-lto], [Disable Link time 
 optimization]))
 +AS_IF([test x$enable_lto != xno], [
 +AS_CASE([$CFLAGS], [*-O[[12345\ ]]*], [
 +CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [-flto 
 -ffat-lto-objects])
 +CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS],[-Wl,-fuse-ld=gold])
 +],
 +[AC_MSG_RESULT([skipping -flto, optimization not enabled])])
 +])
 +
  AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags)

  AS_CASE([$CFLAGS], [*-O[[12345\ ]]*],
 @@ -226,7 +231,7 @@ CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\
  -Wl,-z,relro \
  -Wl,-z,now \
  -pie \
 --Wl,-fuse-ld=gold])
 +])
  AC_SUBST([OUR_LDFLAGS], $with_ldflags $sanitizer_ldflags)

  AC_CHECK_SIZEOF(pid_t)
 --
 2.3.0

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

[systemd-devel] [PATCHv3] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.

This also optimizes the startup tiny bit since we have udev
rules running on network devices and setting sysctl through
the rules.
---
 src/sysctl/sysctl.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..275a5b7 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
*value) {
 n = stpcpy(p, /proc/sys/);
 strcpy(n, property);
 
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
 k = write_string_file(p, value);
 if (k  0) {
 log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,20 @@ static int parse_file(Hashmap *sysctl_options, const char 
*path, bool ignore_eno
 p = normalize_sysctl(strstrip(p));
 value = strstrip(value);
 
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+STRV_FOREACH(i, arg_prefixes) {
+t = path_startswith(*i, /proc/sys/);
+if (t == NULL)
+t = *i;
+if (path_startswith(p, t))
+goto found;
+}
+/* not found */
+continue;
+}
+
+found:
 existing = hashmap_get2(sysctl_options, p, v);
 if (existing) {
 if (streq(value, existing))
-- 
2.1.1

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

Re: [systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

On Wed, Feb 4, 2015 at 4:55 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, Feb 04, 2015 at 03:50:01PM +0100, Umut Tezduyar Lindskog wrote:
 not while applying the parsed sysctl values. Otherwise
 info Overwriting earlier assignment of %s in file %s is
 visible many times even though the given --prefix doesn't
 try to set the overridden value.
 ---
  src/sysctl/sysctl.c | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

 diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
 index 973e67e..b22aff5 100644
 --- a/src/sysctl/sysctl.c
 +++ b/src/sysctl/sysctl.c
 @@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
 *value) {
  n = stpcpy(p, /proc/sys/);
  strcpy(n, property);

 -if (!strv_isempty(arg_prefixes)) {
 -char **i;
 -bool good = false;
 -
 -STRV_FOREACH(i, arg_prefixes)
 -if (path_startswith(p, *i)) {
 -good = true;
 -break;
 -}
 -
 -if (!good) {
 -log_debug(Skipping %s, p);
 -return 0;
 -}
 -}
 -
  k = write_string_file(p, value);
  if (k  0) {
  log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
 @@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const 
 char *path, bool ignore_eno
  p = normalize_sysctl(strstrip(p));
  value = strstrip(value);

 +if (!strv_isempty(arg_prefixes)) {
 +char **i, *t;
 +bool good = false;
 +STRV_FOREACH(i, arg_prefixes) {
 +t = path_startswith(*i, /proc/sys/);
 +if (t == NULL)
 +t = *i;
 +if (path_startswith(p, t)) {
 +good = true;
 +break;
 +}
 +}
 +if (!good)
 +continue;
 +}
 While at it, wouldn't it be better to use a goto and do away with the
 good variable. This will give a diff of -7/+3, a win also for readability 
 imho.

How Zbyszek. I am confused.
Umut


 Zbyszek


 +
  existing = hashmap_get2(sysctl_options, p, v);
  if (existing) {
  if (streq(value, existing))
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
 src/sysctl/sysctl.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..9f9ecc2 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
*value) {
 n = stpcpy(p, /proc/sys/);
 strcpy(n, property);
 
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
 k = write_string_file(p, value);
 if (k  0) {
 log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,24 @@ static int parse_file(Hashmap *sysctl_options, const char 
*path, bool ignore_eno
 p = normalize_sysctl(strstrip(p));
 value = strstrip(value);
 
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = *i;
+if (startswith(t, /proc/sys/)) {
+t = t + strlen(/proc/sys/);
+}
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good) {
+continue;
+}
+}
+
 existing = hashmap_get2(sysctl_options, p, v);
 if (existing) {
 if (streq(value, existing))
-- 
2.1.1

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

[systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
 src/sysctl/sysctl.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..b22aff5 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
*value) {
 n = stpcpy(p, /proc/sys/);
 strcpy(n, property);
 
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
 k = write_string_file(p, value);
 if (k  0) {
 log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const char 
*path, bool ignore_eno
 p = normalize_sysctl(strstrip(p));
 value = strstrip(value);
 
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = path_startswith(*i, /proc/sys/);
+if (t == NULL)
+t = *i;
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good)
+continue;
+}
+
 existing = hashmap_get2(sysctl_options, p, v);
 if (existing) {
 if (streq(value, existing))
-- 
2.1.1

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

Re: [systemd-devel] Support for staged startup

[Umut Tezduyar Lindskog]

Hi,

What you have figured out is so far the only way if you want to have
dynamic targets.
If you do not use --no-block to start your second target, first
target will never finish.
Other caveat of your way is that systemd doesn't know about your final
target until it receives systemctl start destination.target. Since
it doesn't know about the target, units that are requested by
destination.target will not have the default dependencies applied.

For example, if your destination target WANTS hello.socket (which has
DefaultDependencies=yes), hello.socket will not be started before
socket.target.

Umut


On Fri, Jan 30, 2015 at 7:06 AM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 Hi Alison,

 -Original Message-
 From: Alison Chaiken [mailto:ali...@she-devel.com]
 Sent: Thursday, January 29, 2015 8:17 PM
 To: systemd-devel@lists.freedesktop.org
 Cc: Hoyer, Marko (ADITG/SW2)
 Subject: Re: Support for staged startup

 Marko Hoyer asks:
  I'd like to realize a staged startup with systemd which is mainly
 about:
  - starting up a static tree up to a final service
  - the only job of the final service is to kick off the start of an
  additional sub tree of units This kind of startup could be realized
  simply by adding an additional one shot service which executes:
  systemctl start xxx.target

 Marko, one target can already be specified as After another.   If
 B.target is present in one of the appropriate directories and specifies

 After=A.target

 and all the services of the final sub-tree are symlinked in a
 B.target.wants directory, doesn't the behavior you need result?   What
 is  missing?Of course, some of the units linked in B.target.wants
 may already be started by the time A.target completes if they are part
 of a earlier target or if they are needed by an earlier unit.   To
 suppress that behavior, you'd have to edit the individual units.

 I don't know of any use case for one unit to start another directly.
 Is there one?

 1.) Coming up with a small tree first reduces the loading time of the unit 
 set (not so much important in my case)

 2.) If you wanna create some dynamics between target A and target B so that 
 depending on the startup situation services are already started before A or 
 in another round they are delayed until A is done, you probably need to 
 disconnect them from the static startup tree and pull them in dynamically at 
 the desired time.


 -- Alison

 --
 Alison Chaiken   ali...@she-devel.com
 650-279-5600
 http://{she-devel.com,exerciseforthereader.org}
 Never underestimate the cleverness of advertisers, or mischief makers,
 or criminals.  -- Don Norman

 Best regards

 Marko Hoyer
 Software Group II (ADITG/SW2)

 Tel. +49 5121 49 6948

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

Re: [systemd-devel] ConditionNeedsUpdate date comparison

[Umut Tezduyar Lindskog]

Hi,

On Tue, Jan 27, 2015 at 1:35 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 26.01.15 14:00, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 condition_test_needs_update() wants the timestamp of /usr to be newer
 than what is being checked.

 Is there a reason why we don't check for /usr !=
 Condition.parameter?

 Well, when I hacked that up, I didn't think of this case.

 What are you saying ConditionNeedsUpdate=/usr is supposed to even
 mean?

We are not on the same page. I never meant ConditionNeedsUpdate=/usr.


 Not that we explicitly document that /etc and /var are the only valid
 parameters currently (because we only manage those stamp
 files with systemd-update-done.service). Hence,
 ConditionNeedsUpdate=/usr is undefined currently, and it's not clear
 to me what is should mean?

 It makes sense to check for /usr  Condition.parameter in a package
 managed linux but our embedded system is upgrading the entire /usr
 partition.

 ConditionNeedsUpdate=/etc is working fine when we upgrade our image
 but it fails when we downgrade it since the timestamp of /usr is older
 than /etc/.updated.

 Well, this stuf is not intended to support downgrades. I don't think
 that can ever work...

 But anyway, I don't really understand what you are trying to say I
 must admit. Could you please elaborate?

Sure.

Pretty much what I am saying is we wan't to use
ConditionNeedsUpdate=/etc for downgrade case. Why do you think it
won't work?

Instead of IF time(/usr)  time(/etc/.updated), we can check IF
time(/usr) != time(/etc/.updated).

Umut



 Lennart

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

[systemd-devel] ConditionNeedsUpdate date comparison

[Umut Tezduyar Lindskog]

Hi,

condition_test_needs_update() wants the timestamp of /usr to be newer
than what is being checked.

Is there a reason why we don't check for /usr != Condition.parameter?

It makes sense to check for /usr  Condition.parameter in a package
managed linux but our embedded system is upgrading the entire /usr
partition.

ConditionNeedsUpdate=/etc is working fine when we upgrade our image
but it fails when we downgrade it since the timestamp of /usr is older
than /etc/.updated.

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

[systemd-devel] Fwd: [systemd-commits] Makefile.am src/bus-proxyd units/.gitignore units/systemd-bus-proxyd.service.m4.in units/systemd-bus-pro...@.service.m4.in units/systemd-bus-proxyd.socket units/

[Umut Tezduyar Lindskog]

Hi David,

Have you done any experiment in terms of the number of connections can
be made on 32 bit arch with bus proxy being multi-threaded instead of
multi-processed?

Umut


-- Forwarded message --
From: David Herrmann dvd...@kemper.freedesktop.org
Date: Sat, Jan 17, 2015 at 2:00 PM
Subject: [systemd-commits] Makefile.am src/bus-proxyd units/.gitignore
units/systemd-bus-proxyd.service.m4.in
units/systemd-bus-pro...@.service.m4.in
units/systemd-bus-proxyd.socket units/user
To: systemd-comm...@lists.freedesktop.org


 Makefile.am   |   14 +
 src/bus-proxyd/bus-proxyd.c   |  243 ++
 units/.gitignore  |4
 units/systemd-bus-proxyd.service.m4.in|   19 ++
 units/systemd-bus-proxyd.socket   |1
 units/systemd-bus-pro...@.service.m4.in   |   22 --
 units/user/.gitignore |2
 units/user/systemd-bus-proxyd.service.in  |   13 +
 units/user/systemd-bus-proxyd.socket  |1
 units/user/systemd-bus-pro...@.service.in |   16 -
 10 files changed, 161 insertions(+), 174 deletions(-)

New commits:
commit a8a1a43f482af480c375a97921df6b42452c7092
Author: David Herrmann dh.herrm...@gmail.com
Date:   Sat Jan 17 13:57:46 2015 +0100

bus-proxy: turn into multi-threaded daemon

Instead of using Accept=true and running one proxy for each connection, we
now run one proxy-daemon with a thread per connection. This will enable us
to share resources like policies in the future.

diff --git a/Makefile.am b/Makefile.am
index 20f760c..88b4c67 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2699,6 +2699,10 @@ libsystemd_proxy_la_LIBADD = \
 systemd_bus_proxyd_SOURCES = \
src/bus-proxyd/bus-proxyd.c

+systemd_bus_proxyd_CFLAGS = \
+   $(AM_CFLAGS) \
+   -pthread
+
 systemd_bus_proxyd_LDADD = \
libsystemd-proxy.la \
libsystemd-internal.la \
@@ -2714,24 +2718,24 @@ systemd_stdio_bridge_LDADD = \

 if ENABLE_KDBUS
 nodist_systemunit_DATA += \
-   units/systemd-bus-proxyd@.service
+   units/systemd-bus-proxyd.service

 dist_systemunit_DATA += \
units/systemd-bus-proxyd.socket

 nodist_userunit_DATA += \
-   units/user/systemd-bus-proxyd@.service
+   units/user/systemd-bus-proxyd.service

 dist_userunit_DATA += \
units/user/systemd-bus-proxyd.socket
 endif

 EXTRA_DIST += \
-   units/systemd-bus-pro...@.service.m4.in \
-   units/user/systemd-bus-pro...@.service.in
+   units/systemd-bus-proxyd.service.m4.in \
+   units/user/systemd-bus-proxyd.service.in

 CLEANFILES += \
-   units/systemd-bus-proxyd@.service.m4
+   units/systemd-bus-proxyd.service.m4

 if HAVE_SMACK
 bus-proxyd-set-cap-hook:
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index debaab2..702f021 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -6,6 +6,7 @@
   Copyright 2010 Lennart Poettering
   Copyright 2013 Daniel Mack
   Copyright 2014 Kay Sievers
+  Copyright 2015 David Herrmann

   systemd is free software; you can redistribute it and/or modify it
   under the terms of the GNU Lesser General Public License as published by
@@ -31,9 +32,11 @@
 #include sys/poll.h
 #include stddef.h
 #include getopt.h
+#include pthread.h

 #include log.h
 #include util.h
+#include hashmap.h
 #include socket-util.h
 #include sd-daemon.h
 #include sd-bus.h
@@ -53,17 +56,118 @@
 #include synthesize.h

 static char *arg_address = NULL;
-static char *arg_command_line_buffer = NULL;
-static bool arg_drop_privileges = false;
 static char **arg_configuration = NULL;

+typedef struct {
+int fd;
+} ClientContext;
+
+static ClientContext *client_context_free(ClientContext *c) {
+if (!c)
+return NULL;
+
+close(c-fd);
+free(c);
+
+return NULL;
+}
+
+DEFINE_TRIVIAL_CLEANUP_FUNC(ClientContext*, client_context_free);
+
+static int client_context_new(ClientContext **out, int fd) {
+_cleanup_(client_context_freep) ClientContext *c = NULL;
+
+c = new0(ClientContext, 1);
+if (!c)
+return log_oom();
+
+c-fd = fd;
+
+*out = c;
+c = NULL;
+return 0;
+}
+
+static void *run_client(void *userdata) {
+_cleanup_(client_context_freep) ClientContext *c = userdata;
+_cleanup_(proxy_freep) Proxy *p = NULL;
+int r;
+
+r = proxy_new(p, c-fd, c-fd, arg_address);
+if (r  0)
+goto exit;
+
+r = proxy_load_policy(p, arg_configuration);
+if (r  0)
+goto exit;
+
+r = proxy_hello_policy(p, getuid());
+if (r  0)
+goto exit;
+
+r = proxy_run(p);
+
+exit:
+return NULL;
+}
+
+static int loop_clients(int accept_fd) {
+pthread_attr_t attr;
+int r;
+
+r = pthread_attr_init(attr);
+if (r  0) {
+r = log_error_errno(errno, Cannot 

[systemd-devel] Relative links in tmpfiles.d/etc.conf

[Umut Tezduyar Lindskog]

Hi,

Our /etc is a sym link and due to that all the links created by
tmpfiles.d/etc.conf are wrong. Is there a reason why the links are
relative?

I would like to send a patch to either:
a) Convert the relative links to absolute ones.
b) Follow the sym link before creating the relative one.

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

Re: [systemd-devel] forever loop during garbage collection

[Umut Tezduyar Lindskog]

Ping?

On Wednesday, December 10, 2014, Umut Tezduyar Lindskog u...@tezduyar.com
wrote:

 On Mon, Dec 8, 2014 at 8:09 PM, Lennart Poettering
 lenn...@poettering.net javascript:; wrote:
  On Sun, 30.11.14 14:38, Umut Tezduyar Lindskog (u...@tezduyar.com
 javascript:;) wrote:
 
  Hi,
 
  We are experiencing an unbreakable loop in manager_dispatch_gc_queue.
  Problem happens when systemd runs in sysV compatibility mode (Porky
  enables this).
 
  Seems like manager_dispatch_gc_queue's while loop gets stuck and seems
  like unit_gc_sweep cannot make a decision about the unit. As a result,
  it marks the unit with offset_unsure and adds the unit back to gc
  queue.
 
  If I am reading the code correctly recursive unit_gc_sweep will never
  be able to remove the unit from the gc queue if it is referenced by
  another unit and if another unit is referenced by the unit.
 
  A is referenced by B
  B is referenced by A
 
  So in this case first A will be processed by the GC sweep, it will
  follow the link to B while setting the state to IN_PATH and invoke the
  GC sweep on that. B will then be set to IN_PATH too. GC sweep now
  follows its link back, and up at A again, but this time return quickly
  because its state is set to IN_PATH. Due to this, it will then set B's
  state to UNSURE, and return to A, which in effect will now be set to
  UNSURE too. Now, we return into GC queue dispatch call, which will
  notice that it is UNSURE and uprgade that to BAD, and kill it because
  there's nothin in the unit's dependency network that is clearly a
  GOOD, and hence should be removed.
 
  The essence of cycle breaking here is really in
  manager_dispatch_gc_queue() which uprgades UNSURE to BAD in the end. I
  am not seeing how this could end up in an endless loop hence.

 I have debugged it more and as you have said there is no bug in code
 but it takes so long to go out of unit_gc_sweep I thought there is a
 forever loop.

 Attached is my patch on 216 and

 https://drive.google.com/file/d/0B_uiALgWpGXtZ0VidURxSnVhcDA/view?usp=sharing
 is a part of the log after patch.

 It has been 3 hours since I issued systemctl isolate and according
 to the logs I can see that garbage collection logic is making it's way
 back up. I guess it will eventually resolve itself but after so many
 hours.

 (Search for - - and it is happening every 300.000
 lines)

 Problem seemed to be introduced on 95ed329 - Move handling of sysv
 initscripts to a generator.

 This is totally due to how sysV generator is linking services but I
 think slowness on GC can happen on a complex system with many units
 linked with each other.

 Thoughts?
 Umut

 
 
  We have this circular referenced by dependency between units and I am
  quite sure they are due to sysV compatibility.
 
  I know that systemd does not allow circular dependency between units
  (ex, wants, or after) but do we allow circular referenced by
  dependency? If so, then it is expected that manager_dispatch_gc_queue
  gets stuck.
 
  We can reproduce it on 216/217 when we isolate a target.
 
  Note: Line
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n875
  should be before
 
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n872
  since unit_gc_sweep() sets the u-in_gc_queue = true if it cannot make
  a decision and we set it back to false.
 
  This is intended. After the sweep returned back to the anchor we can
  make our decision: either add the unit to the cleanup queue in which
  case it should removed from the GC queue, or it is reinstantated as
  a good unit that should continue to exist, in which case it should be
  removed from the GC queue too.
 
  Can't see a bug here...
 
  Can you elaborate on how precisely you are encountering the GC loop?
 
  Lennart
 
  --
  Lennart Poettering, Red Hat

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

Re: [systemd-devel] Improving module loading

[Umut Tezduyar Lindskog]

On Sat, Dec 20, 2014 at 6:10 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Sat, Dec 20, 2014 at 10:45:34AM +, Hoyer, Marko (ADITG/SW2) wrote:
 Hi,

  -Original Message-
  From: systemd-devel [mailto:systemd-devel-
  boun...@lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog
  Sent: Tuesday, December 16, 2014 4:55 PM
  To: systemd-devel@lists.freedesktop.org
  Subject: [systemd-devel] Improving module loading
 
  Hi,
 
  Is there a reason why systemd-modules-load is loading modules
  sequentially? Few things can happen simultaneously like resolving the
  symbols etc. Seems like modules_mutex is common on module loads which
  gets locked up on few occasions throughout the execution of
  sys_init_module.

 We are actually doing this (in embedded systems which need to be up
 very fast with limited resources) and gained a lot. Mainly, IO and CPU
 can be better utilized by loading modules in parallel (one module is
 loaded while another one probes for hardware or is doing memory
 initialization).

 If you have control over your kernel, why not just build the modules
 into the kernel, then all of this isn't an issue at all and there is no
 overhead of module loading?

For us, licenses are the problem.
Umut


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

Re: [systemd-devel] Improving module loading

[Umut Tezduyar Lindskog]

Hi Marko,

Thank you very much for your feedback!

On Sat, Dec 20, 2014 at 11:45 AM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 Hi,

 -Original Message-
 From: systemd-devel [mailto:systemd-devel-
 boun...@lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog
 Sent: Tuesday, December 16, 2014 4:55 PM
 To: systemd-devel@lists.freedesktop.org
 Subject: [systemd-devel] Improving module loading

 Hi,

 Is there a reason why systemd-modules-load is loading modules
 sequentially? Few things can happen simultaneously like resolving the
 symbols etc. Seems like modules_mutex is common on module loads which
 gets locked up on few occasions throughout the execution of
 sys_init_module.

 We are actually doing this (in embedded systems which need to be up very fast 
 with limited resources) and gained a lot. Mainly, IO and CPU can be better 
 utilized by loading modules in parallel (one module is loaded while another 
 one probes for hardware or is doing memory initialization).


 The other thought is, what is the preferred way of loading modules when
 they are needed. Do they have to be loaded on ExecStartPre= or as a
 separate service which has ExecStart that uses kmod to load them?
 Wouldn't it be useful to have something like ExecStartModule=?

 I had such a discussion earlier with some of the systemd guys. My intention 
 was to introduce an additional unit for module loading for exactly the reason 
 you mentioned. The following (reasonable) outcome was:

Do you have links for the discussions, I cannot find them. systemd
already has a service that loads the modules.

 - It is dangerous to load kernel modules from PID 1 since module loading can 
 get stuck
 - Since modules are actually loaded with the thread that calls the syscall, 
 systemd would need additional threads
 - Multi Threading is not really aimed in systemd for stability reasons
 The probably safest way to do what you intended is to use an additional 
 process to load your modules, which could be easily done by using 
 ExecStartPre= in a service file. We are doing it exactly this way not with 
 kmod but with a tool that loads modules in parallel.

 Btw: Be careful with synchronization. We found that lots of kernel modules 
 are exporting device nodes in the background (alsa, some graphics driver, 
 ...). With the proceeding mentioned above, you are moving the kernel module 
 loading and the actual use of the driver interface very close together in 
 time. This might lead to race conditions. It is even worse when you need to 
 access sys attributes, which are exported by some drivers even after the 
 device is already available and uevents have been sent out. For such modules, 
 there actually is no other way for synchronization but waiting for the 
 attributes to appear.

We are aware of the potential complications and races. But good to be
reminded :)

Umut



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

 Best regards

 Marko Hoyer
 Software Group II (ADITG/SW2)

 Tel. +49 5121 49 6948

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

[systemd-devel] [PATCH] build: add option to disable hwdb

[Umut Tezduyar Lindskog]

---
 Makefile-man.am | 9 ++---
 Makefile.am | 2 ++
 configure.ac| 6 ++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 45b8238..c6506aa 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -14,7 +14,6 @@ MANPAGES += \
man/file-hierarchy.7 \
man/halt.8 \
man/hostname.5 \
-   man/hwdb.7 \
man/journalctl.1 \
man/journald.conf.5 \
man/kernel-command-line.7 \
@@ -73,7 +72,6 @@ MANPAGES += \
man/systemd-halt.service.8 \
man/systemd-hibernate-resume-generator.8 \
man/systemd-hibernate-resume@.service.8 \
-   man/systemd-hwdb.8 \
man/systemd-inhibit.1 \
man/systemd-initctl.service.8 \
man/systemd-journald.service.8 \
@@ -676,6 +674,12 @@ man/systemd-user.conf.html: man/systemd-system.conf.html
 man/user.conf.d.html: man/systemd-system.conf.html
$(html-alias)
 
+if ENABLE_HWDB
+MANPAGES += \
+man/hwdb.7 \
+man/systemd-hwdb.xml
+
+endif
 
 if ENABLE_BACKLIGHT
 MANPAGES += \
@@ -1705,7 +1709,6 @@ EXTRA_DIST += \
man/systemd-hibernate-resume-generator.xml \
man/systemd-hibernate-res...@.service.xml \
man/systemd-hostnamed.service.xml \
-   man/systemd-hwdb.xml \
man/systemd-inhibit.xml \
man/systemd-initctl.service.xml \
man/systemd-journal-gatewayd.service.xml \
diff --git a/Makefile.am b/Makefile.am
index a7a2b6d..8489a6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3607,6 +3607,7 @@ udevadm_LDADD = \
libudev-core.la
 
 # 
--
+if ENABLE_HWDB
 INSTALL_DIRS += \
$(sysconfdir)/udev/hwdb.d
 
@@ -3655,6 +3656,7 @@ INSTALL_DATA_HOOKS += \
 
 hwdb-remove-hook:
-test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin
+endif
 
 # 
--
 TESTS += \
diff --git a/configure.ac b/configure.ac
index 90aa3cc..9296c25 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1191,6 +1191,11 @@ AM_CONDITIONAL([ENABLE_GUDEV], [test x$enable_gudev = 
xyes])
 AS_IF([test x$enable_gudev = xyes], [ AC_DEFINE(HAVE_GLIB, 1, [Define if 
glib is available]) ])
 
 # 
--
+AC_ARG_ENABLE(hwdb, [AC_HELP_STRING([--disable-hwdb], [disable hardware 
database support])],
+   enable_hwdb=$enableval, enable_hwdb=yes)
+AM_CONDITIONAL(ENABLE_HWDB, [test x$enable_hwdb = xyes])
+
+# 
--
 have_manpages=no
 AC_ARG_ENABLE(manpages, AS_HELP_STRING([--disable-manpages], [disable 
manpages]))
 AS_IF([test x$enable_manpages != xno], [have_manpages=yes])
@@ -1430,6 +1435,7 @@ AC_MSG_RESULT([
 dbus:${have_dbus}
 nss-myhostname:  ${have_myhostname}
 gudev:   ${enable_gudev}
+hwdb:${enable_hwdb}
 gintrospection:  ${enable_introspection}
 terminal:${have_terminal}
 kdbus:   ${have_kdbus}
-- 
2.1.1

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

[systemd-devel] [PATCHv2] build: add option to disable hwdb

[Umut Tezduyar Lindskog]

Umut: I can't generate man list since I am cross compiling
Please run make update-man-list and include changes on
Makefile-man.am.

I have updated the Makefile-man.am manually on v1, even though
very first that file says DO NOT EDIT IT.

---
 Makefile.am  | 2 ++
 configure.ac | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index a7a2b6d..8489a6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3607,6 +3607,7 @@ udevadm_LDADD = \
libudev-core.la
 
 # 
--
+if ENABLE_HWDB
 INSTALL_DIRS += \
$(sysconfdir)/udev/hwdb.d
 
@@ -3655,6 +3656,7 @@ INSTALL_DATA_HOOKS += \
 
 hwdb-remove-hook:
-test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin
+endif
 
 # 
--
 TESTS += \
diff --git a/configure.ac b/configure.ac
index 90aa3cc..9296c25 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1191,6 +1191,11 @@ AM_CONDITIONAL([ENABLE_GUDEV], [test x$enable_gudev = 
xyes])
 AS_IF([test x$enable_gudev = xyes], [ AC_DEFINE(HAVE_GLIB, 1, [Define if 
glib is available]) ])
 
 # 
--
+AC_ARG_ENABLE(hwdb, [AC_HELP_STRING([--disable-hwdb], [disable hardware 
database support])],
+   enable_hwdb=$enableval, enable_hwdb=yes)
+AM_CONDITIONAL(ENABLE_HWDB, [test x$enable_hwdb = xyes])
+
+# 
--
 have_manpages=no
 AC_ARG_ENABLE(manpages, AS_HELP_STRING([--disable-manpages], [disable 
manpages]))
 AS_IF([test x$enable_manpages != xno], [have_manpages=yes])
@@ -1430,6 +1435,7 @@ AC_MSG_RESULT([
 dbus:${have_dbus}
 nss-myhostname:  ${have_myhostname}
 gudev:   ${enable_gudev}
+hwdb:${enable_hwdb}
 gintrospection:  ${enable_introspection}
 terminal:${have_terminal}
 kdbus:   ${have_kdbus}
-- 
2.1.1

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

Re: [systemd-devel] [PATCH] build: add option to disable hwdb

[Umut Tezduyar Lindskog]

:) See my second patch's comment Michael.

On Fri, Dec 19, 2014 at 3:17 PM, Michael Biebl mbi...@gmail.com wrote:
 That said, Makefile-man.am contains a comment, that this file
 shouldn't be edited directly but rather be updated via make
 update-man-list

 2014-12-19 15:12 GMT+01:00 Michael Biebl mbi...@gmail.com:
 +if ENABLE_HWDB
 +MANPAGES += \
 +man/hwdb.7
 +man/systemd-hwdb.xml

 Shouldn't this rather be systemd-hwdb.8 ?

 I also don't see a reason to remove man/systemd-hwdb.xml from EXTRA_DIST.
 You want to include that file in the dist tarball always.

 2014-12-19 13:25 GMT+01:00 Tom Gundersen t...@jklm.no:
 Hm, this broke the manpage building:

 $ ./autogen.sh c  make man/systemd-hwdb.8
 [...]
 make: *** No rule to make target 'man/systemd-hwdb.xml', needed by
 'man/systemd-hwdb.8'.  Stop.

 Care to take a look?

 Cheers,

 Tom

 On Fri, Dec 19, 2014 at 11:47 AM, Umut Tezduyar Lindskog
 umut.tezdu...@axis.com wrote:
 ---
  Makefile-man.am | 9 ++---
  Makefile.am | 2 ++
  configure.ac| 6 ++
  3 files changed, 14 insertions(+), 3 deletions(-)

 diff --git a/Makefile-man.am b/Makefile-man.am
 index 45b8238..c6506aa 100644
 --- a/Makefile-man.am
 +++ b/Makefile-man.am
 @@ -14,7 +14,6 @@ MANPAGES += \
 man/file-hierarchy.7 \
 man/halt.8 \
 man/hostname.5 \
 -   man/hwdb.7 \
 man/journalctl.1 \
 man/journald.conf.5 \
 man/kernel-command-line.7 \
 @@ -73,7 +72,6 @@ MANPAGES += \
 man/systemd-halt.service.8 \
 man/systemd-hibernate-resume-generator.8 \
 man/systemd-hibernate-resume@.service.8 \
 -   man/systemd-hwdb.8 \
 man/systemd-inhibit.1 \
 man/systemd-initctl.service.8 \
 man/systemd-journald.service.8 \
 @@ -676,6 +674,12 @@ man/systemd-user.conf.html: 
 man/systemd-system.conf.html
  man/user.conf.d.html: man/systemd-system.conf.html
 $(html-alias)

 +if ENABLE_HWDB
 +MANPAGES += \
 +man/hwdb.7 \
 +man/systemd-hwdb.xml
 +
 +endif

  if ENABLE_BACKLIGHT
  MANPAGES += \
 @@ -1705,7 +1709,6 @@ EXTRA_DIST += \
 man/systemd-hibernate-resume-generator.xml \
 man/systemd-hibernate-res...@.service.xml \
 man/systemd-hostnamed.service.xml \
 -   man/systemd-hwdb.xml \
 man/systemd-inhibit.xml \
 man/systemd-initctl.service.xml \
 man/systemd-journal-gatewayd.service.xml \
 diff --git a/Makefile.am b/Makefile.am
 index a7a2b6d..8489a6b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3607,6 +3607,7 @@ udevadm_LDADD = \
 libudev-core.la

  # 
 --
 +if ENABLE_HWDB
  INSTALL_DIRS += \
 $(sysconfdir)/udev/hwdb.d

 @@ -3655,6 +3656,7 @@ INSTALL_DATA_HOOKS += \

  hwdb-remove-hook:
 -test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin
 +endif

  # 
 --
  TESTS += \
 diff --git a/configure.ac b/configure.ac
 index 90aa3cc..9296c25 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1191,6 +1191,11 @@ AM_CONDITIONAL([ENABLE_GUDEV], [test 
 x$enable_gudev = xyes])
  AS_IF([test x$enable_gudev = xyes], [ AC_DEFINE(HAVE_GLIB, 1, [Define 
 if glib is available]) ])

  # 
 --
 +AC_ARG_ENABLE(hwdb, [AC_HELP_STRING([--disable-hwdb], [disable hardware 
 database support])],
 +   enable_hwdb=$enableval, enable_hwdb=yes)
 +AM_CONDITIONAL(ENABLE_HWDB, [test x$enable_hwdb = xyes])
 +
 +# 
 --
  have_manpages=no
  AC_ARG_ENABLE(manpages, AS_HELP_STRING([--disable-manpages], [disable 
 manpages]))
  AS_IF([test x$enable_manpages != xno], [have_manpages=yes])
 @@ -1430,6 +1435,7 @@ AC_MSG_RESULT([
  dbus:${have_dbus}
  nss-myhostname:  ${have_myhostname}
  gudev:   ${enable_gudev}
 +hwdb:${enable_hwdb}
  gintrospection:  ${enable_introspection}
  terminal:${have_terminal}
  kdbus:   ${have_kdbus}
 --
 2.1.1

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



 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?



 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo