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
 

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.
> Creat

Re: [systemd-devel] loose thoughts around portable services

[Umut Tezduyar Lindskog]

Thanks for your reply.

On Mon, Oct 18, 2021 at 9:49 AM Lennart Poettering 
wrote:

> On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (umut.tezdu...@axis.com)
> wrote:
>
> > 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?
>
> The "trusted" profile basically means you dealt with that
> synchronization yourself in some way.
>
> That said: systemd's nss-systemd NSS module can nowadays (v249) read
> user definitions from drop-in JSON fragments in
> /run/host/userdb/. This is is used by nspawn's --bind-user= feature to
> make a host user easily available in a container, with group info,
> password and so on. My plan was to also make use of this in the unit
> executor, i.e. so that whenever RootDirectory=/RootImage= are used the
> service manager places such minimal user info for the selected user
> there, so that the user is perfectly resolvable inside the service
> too. This is particularly relevant for DynamicUser=1 services. I
> haven't come around actually implementing that though. Given
> nss-systemd is enabled in most bigger distro's nssswitch.conf file
> these days I think this is a really nice approach to propagate user
> databases like that.
>

Why don't we also make the varlink user API available to most of the
profiles? This way sandboxed service doesn't need any of the nss conf and
libraries if they don't want to. Most profiles allow dbus communication. I
guess in a similar thought, most system services should be able to do a
user lookup in a modern way.


>
> > 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.
>
> I guess we could add BindUser= or so, which could control the
> /run/host/userdb/ propagation I proposed above.
>
> > 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.
>
> Right now profiles are a concept of portabled, not of the service
> manager. There's a github issue somewhere where people asked us to
> make this generically usable from services too, so I guess you are not
> the only one who'd like someting like that.
>

One important thing that would be missed in that case is the RootDirectory,
RootImage which is I think is important to restrict the file system.


> > Has there been any thought about nesting profiles? Example, one
> > profile can include other profiles in it.
>
> File an RFE issue. I guess we could support that for any profile x
> we'd implicitly also pull in x.d/*.conf, or so.
>

We could implement our own profiles without needing nesting but we believe
it is beneficial to collaborate on profiles upstream and have common
additions to upstream profiles with nesting other profiles. If we get to it
before other people, we would really like to contribute and send a patch on
this.


>
> > 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.
>
> Interesting idea.
>
> Current git has all kinds of JSON hookup for systemd-analyze security
> btw, so tools could do that externally too. But you are right, doing
> this implicitly might indeed make sense. Please file an RFE issue on
> github.
>

So the background is that we have many different domain experts but only
few systemd domain experts. Even less systemd sandboxing experts. We could
ask the systemd sandboxing experts to go through 50+ services and make sure
they apply the "least privilege principle" however A) This would be a one
time change and it would miss all newly implemented services. B) These
experts are not experts in other domains. It would be hard for them to
figure out what needs to be closed/opened.

Another idea we had was to use the default configuration settings but
turned out to be complex task to make the changes on the service files due
to the diversity of services, effort it takes to educate th

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/
>> >

Re: [systemd-devel] stacked extension not working

[Umut Tezduyar Lindskog]

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/
> > > > 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.
> > >
>
>

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.
>
> * journalctl will periodically

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
 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
>>  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
 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&q=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&instruction 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  wrote:
> 2015-11-19 11:17 GMT+01:00 Umut Tezduyar Lindskog :
>> On Wed, Nov 18, 2015 at 10:13 AM, David Herrmann  
>> 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 will now bump the net.

[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
 wrote:
> On 3 November 2015 at 06:27, Umut Tezduyar Lindskog  wrote:
>> journalctl --list-boots seems great actually but wouldn't work for us.
>> We cannot keep lots of logs in our products.
>>
>
> You shouldn't need to keep lots of logs, just a timer unit that would
> query and store/transmit the bootids/deltas (possibly in a round-robin
> fashion)

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

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

[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] How to automount

[Umut Tezduyar Lindskog]

I am not sure if automount is really the right way to go. In the end,
your automount path will fail if your device is not plugged in.

You could always use udev rules (ENV{SYSTEMD_WANTS}='media-ext.mount')
to mount the volume.
http://www.freedesktop.org/software/systemd/man/systemd.device.html

Umut

On Sat, Sep 19, 2015 at 11:05 AM, Paul D. DeRocco
 wrote:
> I want a removable flash drive to be automatically mounted when I plug it
> in, and unmounted when I unplug it. I've done what seems to be required by
> the systemd.automount man page, but it's not working.
>
> The physical drive appears as /dev/sdb1 (it is a partitioned drive). The
> mount point (which exists) is /media/ext. I created a media-ext.mount
> file:
>
> [Mount]
> What=/dev/sdb1
> Where=/media/ext
> Options=noatime,exec,umask=0,sync,errors=continue
>
> and a media-ext.automount file:
>
> [Automount]
> Where=/media/ext
>
> Initially it doesn't work at all. If I manually restart
> media-ext.automount, then it puts into the mount table:
>
> systemd-1 on /media/ext type autofs ...
>
> but when I plug in the drive, nothing else happens. When I try to access
> the drive, it just hangs until I hit ctrl-C.
>
> I'm guessing that media-ext.automount should mount systemd-1 on startup,
> and it should be automagically changed to /dev/sdb1 when I plug something
> in. How do I get these two things to happen?
>
> --
>
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.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] 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
 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
 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]

On Wed, Jun 24, 2015 at 11:53 AM, Daniel Mack  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

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

[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] [PATCH] random-util: guard including sys/auxv.h with the corresponding ifdef check

[Umut Tezduyar Lindskog]

http://lists.freedesktop.org/archives/systemd-devel/2015-May/032473.html

On Tue, Jun 2, 2015 at 11:07 AM, Michael Olbrich
 wrote:
> ---
>  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 88f5182508e7..b230044f5099 100644
> --- a/src/shared/random-util.c
> +++ b/src/shared/random-util.c
> @@ -23,7 +23,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef HAVE_SYS_AUXV_H
>  #include 
> +#endif
>  #include 
>
>  #include "random-util.h"
> --
> 2.1.4
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Umut Tezduyar Lindskog]

On Mon, Jun 1, 2015 at 8:12 PM, David Herrmann  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] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.

[Umut Tezduyar Lindskog]

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

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

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

[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 
 #include 
 #include 
+#ifdef HAVE_SYS_AUXV_H
 #include 
+#endif
 #include 
 
 #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] systemctl as non-root

[Umut Tezduyar Lindskog]

On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov  wrote:
> On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
>  wrote:
>>>> > On May 28, 2015 2:28 PM,  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 2>&1 | 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

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

[Umut Tezduyar Lindskog]

On Fri, May 29, 2015 at 5:26 AM, Andrei Borzenkov  wrote:
> В Thu, 28 May 2015 17:21:14 -0700
> aaron_wri...@selinc.com пишет:
>
>> Brandon Philips  wrote on 05/28/2015 05:10:33 PM:
>> > Access to the system dbus is controlled by dbus policies. You will
>> > need to write a policy for giving this user access to the systemd1
>> object.
>> >
>>
>> I compiled systemd without dbus support (--disable-dbus), and there is no
>> dbus daemon or dbus lib on the system. Is that a requirement to get the
>> functionality I want? I didn't see much need for dbus as the system works
>> quite well without it. Well, except for this of course.
>>
>> > On May 28, 2015 2:28 PM,  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).
Umut
>
> I wonder how access control is implemented in kdbus case.
> ___
> 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] 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

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 2:15 PM, Dimitri John Ledkov
 wrote:
> On 28 May 2015 at 12:56, Umut Tezduyar Lindskog  wrote:
>> On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
>>  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
>>>>  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

Re: [systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 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
>>  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 Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 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

[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] [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  wrote:
> From: Charles Duffy 
>
> ---
>  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
 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] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts

[Umut Tezduyar Lindskog]

On Tue, May 19, 2015 at 1:56 PM, Lennart Poettering
 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

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

[Umut Tezduyar Lindskog]

On Mon, May 18, 2015 at 11:02 PM, Lennart Poettering
 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

[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
 wrote:
> Hi Simon,
>
> On Wed, Apr 29, 2015 at 5:34 PM, Simon McVittie
>  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_qisbpGj3MQ&authuser=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  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

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

[Umut Tezduyar Lindskog]

Hi Simon,

On Wed, Apr 29, 2015 at 5:34 PM, Simon McVittie
 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!

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

[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_qisbpGj3MQ&authuser=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
 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  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 
> 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  wrote:
> On Thu, Mar 12, 2015 at 6:16 PM, Umut Tezduyar Lindskog
>  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  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 
> ---
>  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

[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] Cleaning up transient scopes

[Umut Tezduyar Lindskog]

On Thu, Mar 5, 2015 at 12:00 AM, Lennart Poettering
 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

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

[Umut Tezduyar Lindskog]

Hi Marko,

On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) 
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 
>
> 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 
> 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  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:
> VERSION 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 @@
>
>
>
> +SysLogAddress=
> +Controls whether log messages received by the
> +journal daemon shall be forwarded to a multicast UDP network
> +group in syslog RFC 5424 format.
> +
> +The the address string format is similar to socket units. See
Double "the".
> +
> systemd.socket1
> +
> +
> +  
> +
> +  
>  TTYPath=
>
>  Change 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 *userdata) {
> +Server *s = userdata;
> +int r;
> +
> +assert(filename);
> +assert

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
 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
 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] [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

[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

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)
 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
 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

Re: [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 un

[Umut Tezduyar Lindskog]

Hi,

On Sat, Jan 17, 2015 at 4:51 PM, David Herrmann  wrote:
> Hi
>
> On Sat, Jan 17, 2015 at 4:21 PM, Umut Tezduyar Lindskog
>  wrote:
>> 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?
>
> I don't think it makes much of a difference. I'm about to push a patch
> to share the policy, which will reduce memory consumption slightly.
> But apart from that, I don't think it matters much.

I think in theory it should matter. Physical address extension extends
the 4 gb address space. When the proxy is per process, physical memory
and the allowed number of processes is the limit of how many clients
can be connected to dbus. On the other hand, when proxy is per thread,
the 32 bit address space is the limit.

Anyways, I have checked the overhead of new connection when proxy is
per thread and it is negligible enough that you can have thousands of
connection.

Thanks,
Umut

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