[systemd-devel] Antw: Re: Can I enable/disable a target?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:24
in
Nachricht <20190509152440.GC5854@gardel-login>:
> On Do, 09.05.19 12:27, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Whenever I try to enable or disable a target (that exists), I get
>> "Failed to execute operation: No such file or directory". What file
>> or directory, please? Or what is the command trying to say?
> 
> Well, "systemctl enable" could not find the target unit file in the
> directories it searches for them. Where did you place the unit file?

Meanwhile I know: My generator was using bash, and for more reliability I
dared to add "set -u". As it turned out my version of Bash has a bug that
causes false reports of unset variables with arrays, so the generator failed
(the thread of handling exit codes of generators). As a consequence of that,
the unit file wasn't created any more (which I hadn't realized at that time).

But still combining the concepts "operation" and "No such file or directory"
is odd: An operation is neither a file nor a directory.

As said in an other thread, the preferred error message is something like
Failed to execute operation: blabla not found", where "blabla" is the unit in
question.

Regards,
Ulrich



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

[systemd-devel] Antw: Re: Wtrlt: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:28
in
Nachricht <20190509152826.GD5854@gardel-login>:
> On Do, 09.05.19 15:52, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> (Sorry, I didn't sent to the list before)
>> >>> Ulrich Windl  schrieb am 09.05.2019
um 
> 14:25
>> in Nachricht <5cd44c9a.ed38.00a...@rz.uni‑regensburg.de>:
>>  Michael Biebl  schrieb am 09.05.2019 um 12:26 in
Nachricht
>> > :
>> > > Hi
>> > >
>> > > Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl
>> > > :
>> > >
>> > >> Despite of that I'm missing a "systemctl validate ..." command. That
way I
>> > > wouldn't need to execute start, status, stop, just to find out that
some
>> > > settings are rejected.
>> > >
>> > > There is "systemd‑analyze verify".
>>
>> > That sounds interesting, but it seems I'll have to be root to use
>> > it, and
> 
> These limitations where lifted a long time ago. Please update.

It's good to hear, unfortunatey I'm unable to do that (enterprise environment
with certified software).

Regards,
Ulrich




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

[systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:20
in
Nachricht <20190509152036.GB5854@gardel-login>:
> On Do, 09.05.19 12:22, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> I had to subscribe to this list, even though I'm no systemd
>> fan. Still I'll have to deal with it as the distribution we use
>> switched to systemd...
> 
> Fantastic lead‑in. This is a perfect intro if you are asking for help,
> it creates the outmost desire in everyone who could help you to do so
> right‑away.

It just keeps the balance in the universe after all those "systemd is sooo
great" enthusiasm ;-)
Maybe you can make me change my mind...

> 
>> I'm porting my LSB code to systemd, and I'm having some
>> trouble. Cause of the trouble (and possible reason for systemd's
>> unpopularity) seems to be rather arbitrary restrictions without
>> reasoning (which is completely against the GNU spirit of seeking for
>> limitless software).
> 
> Hmm, the second paragaph even manages to improve upon the first. Your
> reader is now as enthusiastic as they could be to help your ASAP!

Yes, that's the "introduction to my personal frustration". I kept out the fact
that the list has a non-working "-request" address. That might add to the
overall impression I git so far...

> 
>> To be concrete: Why isn't it allowed to use an absolute path for
>> RuntimeDirectory, and wy isn't even a relative path allowed? In my
>> case I have a multi‑instance daemon, where the instances can be zero
>> to many. To avoid namespace conflicts, I created a /var/run/
>> directroy where all the instances put their stuff (in separate
>> directories each)
> 
> The "Runtime" in "RuntimeDirectory" should clarify that /run is where
> such dirs are created, hence we don't accept absolute dirs: the prefix
> must be /run, hence why specify it. If you want systemd to create a
> dir elsewhere, use StateDirectory= (which creates it in /var/lib) or
> CacheDirectory= (which creates it in /var/cache) or
> ConfigurationDirectory= which creates it in /etc.

Yes I got that once I understoood what the error message is acutally trying to
tell me ("absolute paths not allowed", you explained that earlier to me).

> 
> These four options map to the four main locations to place service
> data resources in. Well organized services only use those four places,
> since they come with clear life‑cycle and semantical definitions, and
> get first class support via the four settings. It's a gentle push that

Please let the admin decide what "well-organized" is.

> the various services follow established standards and place their
> stuff there and don't make up entirely random dirs outside of the
> typical hierarchy.

There's a difference between "random dirs" and subdirectories.

> 
> Before systemd v235 the RuntimeDirectory= setting did not support
> relative paths with "/" included. Starting with 235 it will accept
> them. Hence, please consider updating, you apparently run an older
> systemd version.

OK, so I wasn't that wrong with my claim. Unfortunately with an enterprise
distribution you don't want to install updates that make you loose support.
(The current most-recent SLES 15 is at systemd v234, unfortunately)

> 
> Note that "/var/run" is a legacy alias for "/run". It's highly
> recommended not to use the former anymore.

It it because you don't like sub-directories, or is it to save four bytes?
;-)

> 
>> Despite of that I'm missing a "systemctl validate ..." command. That
>> way I wouldn't need to execute start, status, stop, just to find out
>> that some settings are rejected.
> 
> "systemd‑analyze verify" exists. Since a long long time.

Not really: You can't verify a unit file while it's not "installed". Comare it
to validating an XML file, for example.

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

[systemd-devel] Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:08
in
Nachricht <20190509150818.GA5854@gardel-login>:
> On Do, 09.05.19 12:25, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> Hi!
>>
>> I'm developing a service and getting the status of my target gives:
>> ● iotwatch.target
>>Loaded: not-found (Reason: No such file or directory)
>>Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago
>>
>> I guess it's not a file named "Reason" that's missing. Despite of my
>> recommendation to create helpful error messages, can you explain what it 
> means?
>> Even after an strace I could not find out what is missing.
> 
> "Loaded" is a field that indicates whether the unit definition was
> properly loaded from the unit file. Here, it's shown as "not-found",
> which is the value indicating that no unit file by the name
> "iotwatch.target" could be found. Then, in brackets you get some
> additional information: here "Reason:" is the field that indicates the
> reason why the unit file wasn't found, and this usually gives you a
> UNIX error code, i.e. the text string associated with an "errno"
> code. "No such file or directory" is the string for ENOENT, i.e. it's
> the simplest of cases here: there really just was no file found by the
> name you requested.
> 
> Typically, when you see "not-found" as "Loaded" value, you'll also see
> "No such file or directory" as "Reason" value, but there are some
> other cases, since units are not always synthesized from unit files on
> disk, but from other concepts too.
> 

Thanks for the explanation; it's more clear now. However I'd prefer a message
like "Loaded: iotwatch.target could not be found", so
* name what is missing, and
* use an "errno message" only for specific system calls (not to summarize
several)

Regards,
Ulrich

> Lennart
> 
> --
> Lennart Poettering, Berlin



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

[systemd-devel] Antw: Re: Wtrlt: Antw: Re: Can I enable/disable a target?

[Ulrich Windl]

>>> Michael Biebl  schrieb am 09.05.2019 um 16:56 in Nachricht
:
> Am Do., 9. Mai 2019 um 15:52 Uhr schrieb Ulrich Windl
> :
>>
>> (Sorry, I didn't send to the list before)
>> >>> Ulrich Windl  schrieb am 09.05.2019 
>> >>> um 
> 14:28
>> in Nachricht <5cd44cae.ed38.00a...@rz.uni-regensburg.de>:
>>  Michael Biebl  schrieb am 09.05.2019 um 12:29 in 
>>  Nachricht
>> > :
>> > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
>> > > :
>> > >>
>> > >> Hi!
>> > >>
>> > >> Whenever I try to enable or disable a target (that exists), I get 
>> > >> "Failed 
> to
>> >
>> > > execute operation: No such file or directory". What file or directory,
>> > > please? Or what is the command trying to say?
>> > >
>> > > Can you share the target unit please.
>> > > Into what location have you installed the unit file?
>> >
>> > This is after fixing obvious errors:
>> > # systemctl enable iotwatch.target
>> > Failed to execute operation: No such file or directory
>> > # cat /run/systemd/generator.late/iotwatch.target
>> > [Unit]
>> > Description=iotwatch I/O performance monitor
>> > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
>> > After=nss-lookup.target time-sync.target paths.target
>> > Wants=iotwatch@VAR.service 
>> >
>> > [Install]
>> > WantedBy=multi-user.target
> 
> This doesn't make sense. You generate an ephemeral runtime unit in
> /run but you then try to enable it in /etc.

See /etc/fstab. it does make sense!

> 
> To make it easier to help, you should give us an idea/overview what
> you are trying to achieve. What you did so far (and why), what
> environment you are using etc.
> 
> It's really hard to give you a good answer when we don't even tell us
> the systemd version and distro you are using.

SLES12 SP3 / SP4. And the goal is very simple: Make may service that runs 
perfectly under init run under systemd with minimal changes to the runtime 
environment.

> 
> -- 
> 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] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Ulrich Windl]

>>> Andrei Borzenkov  schrieb am 09.05.2019 um 16:54 in
Nachricht <399aa684-a6bf-af19-dd09-bd670ec60...@gmail.com>:
> 09.05.2019 13:22, Ulrich Windl пишет:
>> Hi!
>> 
>> I had to subscribe to this list, even though I'm no systemd fan. Still I'll

> have to deal with it as the distribution we use switched to systemd...
>> 
>> I'm porting my LSB code to systemd, and I'm having some trouble. Cause of 
> the trouble (and possible reason for systemd's unpopularity) seems to be 
> rather arbitrary restrictions without reasoning (which is completely against

> the GNU spirit of seeking for limitless software).
>> 
>> To be concrete: Why isn't it allowed to use an absolute path for 
> RuntimeDirectory,
> 
> Wild guess - RuntimeDirectory is about security and permitting arbitrary
> path here rather contradicts this goal.

So root can run any program, but the PID of it may not be stored in a
subdirectory for security reasons???

> 
>> and wy isn't even a relative path allowed? In my case I have a 
> multi-instance daemon, where the instances can be zero to many. To avoid 
> namespace conflicts, I created a /var/run/ directroy
> 
> systemd does it for you.

That's irrelevant, bacause you are not allowed to use the directory, whoever
creates it.

> 
>> where all the instances put their stuff (in separate directories each)
>> 
>> Trying "RuntimeDirectory=/%i" inside @.service isn't
"accepted". 
> Still the instances start, can be checked and stopped, but there is a
message 
> when stopped saying
>> systemd[1]: [/usr/lib/systemd/system/@.service:12] Runtime
directory 
> is not valid, ignoring assignment: /%i
> 
> This works here; use of multilevel paths is even documented; granted,
> ability to use specifiers is not that obvious from manual page.

WHich version do you use, and how does your unit file look like?

> 
>> 
>> As "mkdir -p" exists for at least 25 years, I wonder what this is all
about.
>> 
> 
> I tentatively suspect that being less aggressive may actually help ...

If a program tells where I have to store my files creates frustration, and
that must go out...

> 
>> Despite of that I'm missing a "systemctl validate ..." command. That way I

> wouldn't need to execute start, status, stop, just to find out that some 
> settings are rejected.
>> 
>> Regards,
>> Ulrich
>> 
>> 
>> 
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"

[Ulrich Windl]

>>> Andrei Borzenkov  schrieb am 09.05.2019 um 16:32 in
Nachricht <11c2e9e7-4094-7c65-5840-9f69b54e3...@gmail.com>:
> 09.05.2019 13:25, Ulrich Windl пишет:
>> Hi!
>> 
>> I'm developing a service and getting the status of my target gives:
>> ● iotwatch.target
>>Loaded: not-found (Reason: No such file or directory)
>>Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago
>> 
>> I guess it's not a file named "Reason" that's missing. Despite of my
>> recommendation to create helpful error messages, can you explain what it 
> means?
>> Even after an strace I could not find out what is missing.
>> 
> 
> It means that unit definition file (iotwatch.target) was not found in
> any directory where systemd looks for it.

The confusing part is that something that cannot be found is "active" for 18
minutes ;-)

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

Re: [systemd-devel] user service not starting on login

[Topi Miettinen]

On 12.5.2019 18.08, Matt Zagrabelny wrote:

Hey Mantas and others,

On Thu, May 9, 2019 at 11:57 PM Mantas Mikulėnas > wrote:


On Fri, May 10, 2019 at 5:22 AM Matt Zagrabelny mailto:mzagr...@d.umn.edu>> wrote:

Greetings,

I am attempting to get a user service running on my session login.

The unit is called jack. I've enabled it via:

$ systemctl --user enable jack

When I boot up the system and log in I see that it is inactive.
I can start it manually without issue:

$ systemctl --user status jack
● jack.service - JACK 2
    Loaded: loaded
(/home/theophilus/.config/systemd/user/jack.service; enabled;
vendor preset: enabled)
    Active: inactive (dead)

$ journalctl --user -u jack -b
-- Logs begin at Thu 2019-05-09 20:54:31 CDT, end at Thu
2019-05-09 21:13:53 CDT. --
-- No entries --

$ systemctl --user cat jack
# /home/theophilus/.config/systemd/user/jack.service
[Unit]
Description=JACK 2
Before=sound.target
Before=pulseaudio.service
Requires=dbus.socket

[Service]
Type=dbus
BusName=org.jackaudio.Controller


Among other things, the bus name seems to be incorrect. In
jack2-dbus the only claimed name appears to be "org.jackaudio.service".

ExecStart=/usr/bin/jack_control start


The jack_control program does not spawn nor directly execute the
actual jackd daemon. Instead it *remotely*
activates org.jackaudio.service through D-Bus (you'll see jackdbus
under the dbus.service cgroup), then sends it a single method call
and exits.

In other words, jack_control is not a Type=dbus service, it's a
oneshot script that controls another Type=dbus service. You can
imagine that it's just a wrapper around `dbus-send` or `gdbus call`,
and is something you'd instead use in JACK's *ExecStartPost=*.

A direct conversion of jackdbus to a systemd service would look like
this – because of the way jackdbus is written, it always needs that
extra command to be sent over D-Bus (either by running `jack_control
start` or by using the manual tools):

(~/.config/systemd/user/jack.service)
[Service]
Type=dbus
BusName=org.jackaudio.service
ExecStart=/usr/bin/jackdbus auto
#ExecStartPost=/usr/bin/jack_control start
#ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o
/org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer
ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service
/org/jackaudio/Controller org.jackaudio.JackControl StartServer


I used this service file (thank you for providing it!), but it seems 
jack is still not starting when the user logs in to the session:


$ systemctl --user status jack
● jack.service
    Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service; 
enabled; vendor preset: enabled)

    Active: inactive (dead)

$ ps -ef | grep jack
theophi+  1200  1183  0 09:30 pts/3    00:00:00 grep jack

$ systemctl --user status jack
● jack.service
    Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service; 
enabled; vendor preset: enabled)

    Active: inactive (dead)

$ systemctl --user cat jack
# /home/theophilus/.config/systemd/user/jack.service
[Service]
Type=dbus
BusName=org.jackaudio.service
ExecStart=/usr/bin/jackdbus auto
#ExecStartPost=/usr/bin/jack_control start
#ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o 
/org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer
ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service 
/org/jackaudio/Controller org.jackaudio.JackControl StartServer


You are missing:

[Install]
WantedBy=default.target

Then when you enable it, systemd should create a symbolic link in directory
.config/systemd/user/default.target.wants
to your service.

-Topi



$ systemctl --user is-enabled jack
enabled

$ systemctl --user is-active jack
inactive

$ systemctl --user | grep jack

$ systemctl --user | grep bus
at-spi-dbus-bus.service  
                              loaded active running   Accessibility 
services bus
dbus.service
                               loaded active running   D-Bus User 
Message Bus
dbus.socket  
                              loaded active running   D-Bus User Message 
Bus Socket


If I start ardour (which makes use of jack) it (ardour) tells me jack is 
not running.


I can start the jack service:

$ systemctl --user start jack

So...

How can I figure out why it is not starting automatically?

Thanks!

-m

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

Re: [systemd-devel] user service not starting on login

[Matt Zagrabelny]

Hey Mantas and others,

On Thu, May 9, 2019 at 11:57 PM Mantas Mikulėnas  wrote:

> On Fri, May 10, 2019 at 5:22 AM Matt Zagrabelny 
> wrote:
>
>> Greetings,
>>
>> I am attempting to get a user service running on my session login.
>>
>> The unit is called jack. I've enabled it via:
>>
>> $ systemctl --user enable jack
>>
>> When I boot up the system and log in I see that it is inactive. I can
>> start it manually without issue:
>>
>> $ systemctl --user status jack
>> ● jack.service - JACK 2
>>Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service;
>> enabled; vendor preset: enabled)
>>Active: inactive (dead)
>>
>> $ journalctl --user -u jack -b
>> -- Logs begin at Thu 2019-05-09 20:54:31 CDT, end at Thu 2019-05-09
>> 21:13:53 CDT. --
>> -- No entries --
>>
>> $ systemctl --user cat jack
>> # /home/theophilus/.config/systemd/user/jack.service
>> [Unit]
>> Description=JACK 2
>> Before=sound.target
>> Before=pulseaudio.service
>> Requires=dbus.socket
>>
>> [Service]
>> Type=dbus
>> BusName=org.jackaudio.Controller
>>
>
> Among other things, the bus name seems to be incorrect. In jack2-dbus the
> only claimed name appears to be "org.jackaudio.service".
>
>
>> ExecStart=/usr/bin/jack_control start
>>
>
> The jack_control program does not spawn nor directly execute the actual
> jackd daemon. Instead it *remotely* activates org.jackaudio.service through
> D-Bus (you'll see jackdbus under the dbus.service cgroup), then sends it a
> single method call and exits.
>
> In other words, jack_control is not a Type=dbus service, it's a oneshot
> script that controls another Type=dbus service. You can imagine that it's
> just a wrapper around `dbus-send` or `gdbus call`, and is something you'd
> instead use in JACK's *ExecStartPost=*.
>
> A direct conversion of jackdbus to a systemd service would look like this
> – because of the way jackdbus is written, it always needs that extra
> command to be sent over D-Bus (either by running `jack_control start` or by
> using the manual tools):
>
> (~/.config/systemd/user/jack.service)
> [Service]
> Type=dbus
> BusName=org.jackaudio.service
> ExecStart=/usr/bin/jackdbus auto
> #ExecStartPost=/usr/bin/jack_control start
> #ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o
> /org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer
> ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service
> /org/jackaudio/Controller org.jackaudio.JackControl StartServer
>
>
I used this service file (thank you for providing it!), but it seems jack
is still not starting when the user logs in to the session:

$ systemctl --user status jack
● jack.service
   Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service;
enabled; vendor preset: enabled)
   Active: inactive (dead)

$ ps -ef | grep jack
theophi+  1200  1183  0 09:30 pts/300:00:00 grep jack

$ systemctl --user status jack
● jack.service
   Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service;
enabled; vendor preset: enabled)
   Active: inactive (dead)

$ systemctl --user cat jack
# /home/theophilus/.config/systemd/user/jack.service
[Service]
Type=dbus
BusName=org.jackaudio.service
ExecStart=/usr/bin/jackdbus auto
#ExecStartPost=/usr/bin/jack_control start
#ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o
/org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer
ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service
/org/jackaudio/Controller org.jackaudio.JackControl StartServer

$ systemctl --user is-enabled jack
enabled

$ systemctl --user is-active jack
inactive

$ systemctl --user | grep jack

$ systemctl --user | grep bus
at-spi-dbus-bus.service
   loaded active running   Accessibility services
bus
dbus.service
  loaded active running   D-Bus User Message Bus
dbus.socket
   loaded active running   D-Bus User Message Bus
Socket

If I start ardour (which makes use of jack) it (ardour) tells me jack is
not running.

I can start the jack service:

$ systemctl --user start jack

So...

How can I figure out why it is not starting automatically?

Thanks!

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

[systemd-devel] systemd-nspawn and cgroup hybrid mode

[Antoine Pietri]

Hi,

I have a probably dumb question for which I couldn't find an answer in
the docs. I'm trying to make a program that uses the cgroupv1 API run
into a systemd-nspawn container. In the host, I know that I can just
look at /proc/self/cgroup to see the path of my cgroup and write stuff
there. The legacy cgroup tree is properly created on the host:

$ systemd-run --pty find /sys/fs/cgroup/ | grep 'run-u[0-9]' | grep
group/memory/
/sys/fs/cgroup/memory/system.slice/run-u4161.service/cgroup.procs
/sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.use_hierarchy
/sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.kmem.tcp.usage_in_bytes
/sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.soft_limit_in_bytes
[...]

But when I'm in the container, it doesn't work anymore. Running the
same command returns no results. Now, this is most certainly due to
the fact that in the container, /sys/fs/cgroup is mounted in read-only
so systemd can't create anything in /sys/fs/cgroup/memory... but then,
what is the proper way to write into the legacy cgroups? I also tried
to turn on Delegate=true to see if it would change something, but it
doesn't.

Thanks,

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

[systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages

[Stanislav Angelovič]

Hi (Lennart :)

Quick question: Would it be possible to extend sd-bus to also allow
creating messages without requiring a bus?

Let me explain: Currently, if we want to create any message in sd-bus, we
need a valid bus pointer. That might make perfect sense for messages that
come from or will eventually go to bus. But sd-bus also supports plain
messages. Do we also need that hard msg->bus dependency for plain messages
which we use only as a local, temporary storage of serialized data?

Some years ago we had a little discussion about a few tweaks in sd-bus API
to allow modelling the concept of Variant type in higher-level sd-bus
bindings (
https://lists.freedesktop.org/archives/systemd-devel/2016-November/037929.html).
A Variant is essentially implemented as a class around plain sd-bus message
which is only used a storage of the underlying type. To create a Variant
instance, we simply call `sd_bus_message_new` factory with type
_SD_BUS_MESSAGE_TYPE_INVALID. Nice and simple. But that factory requires
real bus ptr. This leads to a more complicated, less efficient and
not-that-nice solution that must take hold of some bus (if there is none it
must create one), must cache the bus (so that it's not created and
destroyed at every creation/deletion of Variant instance). Yes, we have
`sd_bus_default_system`, but even with that there is some effort that has
some pitfalls (e.g. we can't `std::move` a Variant to a different thread,
because it might potentially outlive the current one). All that
nomenclature is needed just to get a plain message to read/write data from.

It looks like the bus is not really needed when the message is used as a
local storage only, i.e. when only these API functions are used:

* creating plain, empty message (`sd_bus_message_new`)
* writing/reading to/from the message (`sd_bus_message_append*`,
`sd_bus_message_read*`, ...)
* sealing the message (`sd_bus_message_seal`
* copying to/from the message (`sd_bus_message_copy`)
* rewinding the message (`sd_bus_message_rewind`)
* peeking message type (`sd_bus_message_peek_type`)
* reffing/unreffing the message (sd_bus_message_ref/unref`)

Even today, vast majority of these functions doesn't seem to need the bus.
The exception are `sd_bus_message_seal` and `sd_bus_message_new` itself.
We'd need to either modify `sd_bus_message_new` to allow taking in NULL bus
ptr, or creating a new function for creating such plain local messages.
We'd need to modify `sd_bus_message_seal` to simply consider the fact that
m->bus can be NULL. And we'd probably need to add asserts for m->bus to
functions which truly require real bus ptr presence. (We might even provide
the option to link the message to a real bus later, and introduce new
`sd_bus_message_set_bus` function, but I'm not sure whether that is good.)

To summarize: sd-bus already offers API for creating plain message. To make
it fully true, let's just not require the bus there. The proposed change
would IMHO make  sd-bus message more flexible, and would make it easier,
more intuitive and more robust to work with and model Variants around such
free-standing, bus-independent sd-bus messages in higher-level languages.

What do you think?

Thank you, and kind regards,

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