Re: [systemd-devel] systemd-tmpfiles service related queries

[Mantas Mikulėnas]

On Mon, Oct 2, 2023 at 2:36 PM Pintu Agarwal  wrote:

> Hi All,
>
> I have a doubt related to systemd-tmpfiles-setup.service.
> This service is mentioned to be started after local-fs.target.
> {{{
> After=local-fs.target systemd-sysusers.service
> Before=sysinit.target shutdown.target
> }}}
> In this case this service takes only ~125ms.
> systemd-tmpfiles-setup.service (123ms)
>
> But in our case (QC chipset, arm64, qual-core), we wanted to move this
> service to start before local-fs.target, so we can push some of our
> services upward.
> {{{
> After=systemd-sysusers.service systemd-journald.service
> Before=local-fs.target sysinit.target shutdown.target
> }}}
> In this case it is taking more than ~1s but it helps to reduce the
> timing of other services.
> systemd-tmpfiles-setup.service (1.177s)
>
> So, I wanted to know two things:
> 1) What is the dependency if starting this service after local-fs target
> only ?
> 2) Is it fine to move this service to start before local-fs.target ?
> What could be the consequences and effect and how to verify it ?
>

The consequences are that if you configure tmpfiles to create something in
a separate mounted filesystem, without this dependency (ordering) it may
accidentally create files in the "lower" mountpoints before the filesystem
is mounted...

The alternative to using local-fs.target is to go through all of your
tmpfiles.d configurations and add specific After=foo.mount or
RequiresMountsFor=/foo/bar ordering – for each filesystem that the
configuration expects to be available – into your tmpfiles service.

-- 
Mantas Mikulėnas

[systemd-devel] systemd-tmpfiles service related queries

[Pintu Agarwal]

Hi All,

I have a doubt related to systemd-tmpfiles-setup.service.
This service is mentioned to be started after local-fs.target.
{{{
After=local-fs.target systemd-sysusers.service
Before=sysinit.target shutdown.target
}}}
In this case this service takes only ~125ms.
systemd-tmpfiles-setup.service (123ms)

But in our case (QC chipset, arm64, qual-core), we wanted to move this
service to start before local-fs.target, so we can push some of our
services upward.
{{{
After=systemd-sysusers.service systemd-journald.service
Before=local-fs.target sysinit.target shutdown.target
}}}
In this case it is taking more than ~1s but it helps to reduce the
timing of other services.
systemd-tmpfiles-setup.service (1.177s)

So, I wanted to know two things:
1) What is the dependency if starting this service after local-fs target only ?
2) Is it fine to move this service to start before local-fs.target ?
What could be the consequences and effect and how to verify it ?


Thanks,
Pintu

Re: [systemd-devel] systemd-nspawn/systemd.nspawn machinectl enable/start

[Mantas Mikulėnas]

Each nspawn container that's managed via machinectl is run as an instance
of "systemd-nspawn@.service". Add a [Service] ExecStartPre= to the instance
you need, using `systemctl edit` or similar.

On Mon, Oct 2, 2023 at 1:37 AM Rob Ert  wrote:

> Hello all,
>
> As I have not been able to find an answer to my question after consulting
> man pages and google, I am turning to this mailing list.
>
> I have a systemd-nspawn os container that I have set to automatically
> start with machinectl enable.
> I would like to automatically have a bcachefs snapshot created before the
> machine is started. As provisions for a hook to script something like this
> do not seem to be supported in systemd.nspawn,
> I would like to know what and where the best way and place to achieve this
> is?
>
> Please cc me.
>
> Many thanks,
> and all the best,
> Rob
>


-- 
Mantas Mikulėnas