Re: [systemd-devel] systemd-nspawn: where is my container root?

[Lennart Poettering]

On Do, 28.06.18 20:25, Nikolaus Rath (nikol...@rath.org) wrote:

> On Jun 26 2018, Lennart Poettering  wrote:
> > On Di, 26.06.18 09:39, Nikolaus Rath (nikol...@rath.org) wrote:
> >
> >> Hi,
> >> 
> >> That makes sense.. but is there any way to find out *globally* what
> >> devices are mounted in *any* namespace?
> >
> > If you a PID from any process that belongs to the container you can
> > list its mounts by doing /proc/$PID/mountinfo. You can also access its
> > files through the /proc/$PID/root pseudo directory. 
> >
> > There's also /usr/lib/systemd/systemd-dissect --mount if you want to
> > look into a raw image and have it mounted externally just like
> > systemd-nspawn would do it.
> 
> That's good to know, thanks! My question was meant a little different
> though (and is probably somewhat off-topic, but it fit nicely into the
> thread):
> 
> If any process could potentially sit in its own namespace (whether
> created by systemd or manually) and have its own mounts, is there any
> way for me to get a list of *all* the mounts in any namespace (without
> having to determine which pids have their own namespace and query
> them one by one)?

Try this:

for f in /proc/*/mountinfo ; do cat $f ; done | sort -un 

it will output a list of all mounts in all processes on the system,
neatly sorted by the numeric mount id.

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] What should mount /sys/fs/fuse/connections?

[Lennart Poettering]

On Do, 28.06.18 20:23, Nikolaus Rath (nikol...@rath.org) wrote:

> Hello,
> 
> I'm maintainer of libfuse. libfuse ships with a SysV init script[1] that
> I'd like to replace with a systemd unit file. It currently does just two
> things:
> 
> 1. loads fuse kernel module
> 2. mounts fusectl filesystem at /sys/fs/fuse/connections
> 
> I don't think there is a need to retain the function to load the kernel
> module (that's probably better done by eg. /etc/modules), but I am not
> sure how to migrate the mounting of the control filesystem.
> 
> My gut feeling is that this should be done by udev in response to the
> fuse kernel module being loaded. Is that correct? If so, does libfuse
> need to install a systemd unit (or probably rather a udev rules file) in
> order for this to happen? Or should things just work(tm) nowadayS

systemd already contains a .mount unit for this
(sys-fs-fuse-connections.mount), which is pulled in automatically when
the kmod is loaded, see 99-systemd.rules. Hence you shouldn't need to
have any further script or such in place, it should already get
mounted out of the box.

Since the mount unit is activated asynchronously, there's a minor race
however, and services which want to access the mount point should
order themselves explicitly after the unit and pull it in, for example
through:

Wants=sys-fs-fuse-connections.mount
After=sys-fs-fuse-connections.mount

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] systemd-nspawn: where is my container root?

[Nikolaus Rath]

On Jun 26 2018, Lennart Poettering  wrote:
> On Di, 26.06.18 09:39, Nikolaus Rath (nikol...@rath.org) wrote:
>
>> Hi,
>> 
>> That makes sense.. but is there any way to find out *globally* what
>> devices are mounted in *any* namespace?
>
> If you a PID from any process that belongs to the container you can
> list its mounts by doing /proc/$PID/mountinfo. You can also access its
> files through the /proc/$PID/root pseudo directory. 
>
> There's also /usr/lib/systemd/systemd-dissect --mount if you want to
> look into a raw image and have it mounted externally just like
> systemd-nspawn would do it.

That's good to know, thanks! My question was meant a little different
though (and is probably somewhat off-topic, but it fit nicely into the
thread):

If any process could potentially sit in its own namespace (whether
created by systemd or manually) and have its own mounts, is there any
way for me to get a list of *all* the mounts in any namespace (without
having to determine which pids have their own namespace and query
them one by one)?


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] What should mount /sys/fs/fuse/connections?

[Nikolaus Rath]

Hello,

I'm maintainer of libfuse. libfuse ships with a SysV init script[1] that
I'd like to replace with a systemd unit file. It currently does just two
things:

1. loads fuse kernel module
2. mounts fusectl filesystem at /sys/fs/fuse/connections

I don't think there is a need to retain the function to load the kernel
module (that's probably better done by eg. /etc/modules), but I am not
sure how to migrate the mounting of the control filesystem.

My gut feeling is that this should be done by udev in response to the
fuse kernel module being loaded. Is that correct? If so, does libfuse
need to install a systemd unit (or probably rather a udev rules file) in
order for this to happen? Or should things just work(tm) nowadayS

Thanks,
-Nikolaus

[1] https://github.com/libfuse/libfuse/blob/master/util/init_script

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] weird systemd-inhibit behaviour

[Amish]

Hello

I am trying out systemd-inhibit as follows (on Arch Linux systemd 
version 238.133-4) but things dont seem to be working as expected.


So I would like to know if I am missing something or is there a bug?

Note: Everything is commented in /etc/systemd/logind.conf and there is 
no logind.conf.d directory in /run, /etc or /usr paths.


Case 1)
Inside multi-user.target - logged in to local tty as root.

# systemd-inhibit 
--what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown 
sleep 300 &

# systemd-inhibit --list
    Who: sleep 300 (UID 0/root, PID 2544/systemd-inhibit)
    What: 
shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch

 Why: Unknown reason
    Mode: block
...
$ echo switched to non-root user
$ systemctl suspend
Operation inhibited by "sleep 300" (PID 2544 "systemd-inhibit", user 
root), reason is "Unknown reason".

Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl suspend -i'.
# echo back as root user
# systemctl suspend # or halt or poweroff or reboot

It goes ahead and performs the action even if I am not using -i 
(--ignore-inhibitors) switch.


Documentation for -i (--ignore-inhibitors) states this:
If any locks are taken, shutdown and sleep state requests will normally 
fail (regardless of whether privileged or not) and a list of active 
locks is printed.


It clearly states - "privileged or not" - so even if I am running 
systemctl as root - it should not shutdown or sleep in above case.


Case 2)
Inside graphical.target - using KDE plasma - logged in as a non-root user.

Same first command as in case 1).

# logged into KDE as non-root user but command below run as root inside 
konsole
# systemd-inhibit 
--what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown 
sleep 300 &


Now if I click KDE Menu-->Leave-->Suspend (Suspend to RAM) ... it blocks 
suspend and asks me for root password - stating that there is an inhibitor.


But if I click KDE Menu-->Leave-->Shut Down ... it goes ahead and shuts 
down the machine.


/usr/lib/sddm/sddm.conf.d/sddm.conf has these systemctl commands 
mentioned in it:


HaltCommand=/usr/bin/systemctl poweroff
RebootCommand=/usr/bin/systemctl reboot

So I believe something is not right or I am doing something wrong in an 
unexpected way.


Case 2) may be KDE related issue but case 1) should atleast have worked 
as expected.


Can anyone else test?

Thank you,

Amish.

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

Re: [systemd-devel] starting a service before anything else....

[Alberto Salvia Novella]

I myself started using SystemD just a couple of days ago. And even when 
in the beginning it looked difficult, now it makes all the sense.


Doing this by scripting would be much more difficult. Actually you only 
have to take into account who your service is wantedBy, and and if it's 
needed to be started before or after it.


The rest just corner cases, or small improvements.


Alberto 


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] starting a service before anything else....

[Lennart Poettering]

On Do, 28.06.18 16:55, MALET Jean-Luc (jeanluc.malet.snow...@gmail.com) wrote:

> [Unit]
> Description=mount some file systems before anything and prepare the system
> Before=systemd-remount-fs.service
> 
> [Service]
> Type=oneshot
> ExecStart=/etc/init.d/setup.sh start
> 
> [Install]
> WantedBy=swap.target

Unless this tool has anything to do with swap management, it shouldn't
hook into swap.target.

Early boot services are usually pulled in by sysinit.target,
i.e. you want WantedBy=sysinit.target.

A concept of "before everything" doesn't exist in systemd, because
it's conceptually a major source of problems (i mean, what do you do
if you have multiple services that want to run before everything?).

If your service is related to mounts, and you want to make sure you
run before all mounts that haven't explicitly turned off default
dependencies, then order yourself before "local-fs-pre.target" and
pull it in with Wants=. You can achieve something similar by ordering
yourself before systemd-remount-fs.service as that aleady carries
those deps, and hence you transitively gain the same ordering deps if
you order yourself before it.

Note that all early boot stuff needs to set DefaultDependencies=no as
otherwise it will automatically be place in the late boot phase.

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] starting a service before anything else....

[Alberto Salvia Novella]

sudo systemctl daemon-reload; sudo systemctl disable [unit]; sudo 
systemctl enable [unit]



Alberto 


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] starting a service before anything else....

[Alberto Salvia Novella]

WantedBy=systemd-remount-fs.service


Alberto 


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] starting a service before anything else....

[Mantas Mikulėnas]

On Thu, Jun 28, 2018, 18:37 MALET Jean-Luc 
wrote:

> Hi!
>
> I'm in charge of setting up an embedded solution based on debian, so on
> systemd, I'm more used to old init process, that was easy to tweak
> because based on script... but well... times seems now on systemd.
>
> I'm really puzzled because since the documentation seems to lack
> information, I have to find information on tutorials that focus only on
> late services..
>
> I found on one how to find the targets using "systemctl list-units
> --type=target" and some diagram explaining what target are suposed to be
> run in what order but well...
>
> my issue is that I've to run a script as early as possible, before
> mounts are done because lot of service will fail without , so I created
> a service
>

Mainly I guess it's because systemd wants to *avoid* things like "before
everything else" or "after everything else". (What if two units want to be
first?) The idea is that dependencies should be a little more explicit if
possible. For example, some of your services require /var/foo to be
mounted? They can depend on "var-foo.mount" or at least "local-fs.target".
And so on.

(Well, not to the extreme of course: even systemd has synchronization
points like basic.target, local-fs.target, ...)


>
> [Unit]
> Description=mount some file systems before anything and prepare the system
> Before=systemd-remount-fs.service
>
> [Service]
> Type=oneshot
> ExecStart=/etc/init.d/setup.sh start
>
> [Install]
> WantedBy=swap.target
>
>
> using journalctl I found that the first Reached point was the
> swap.target so it looked like a good WantedBy, but looking at the
> journalctl showed that the service was still not run in early systemd
> steps... so I added a Before rule using the "systemctl list-units
> --type=service" to guess what service where run on the system... and
> well... it's not working as expected... I still see my service run after
> some other services...
>

basic.target or sysinit.target would be a better place, depending on what
you do.

It might be a good idea to split the mega-script up if it tries to perform
several distinct tasks, too.

In either case, add "DefaultDependencies=no" to your services, to opt out
of all the hidden dependencies (which if I remember correctly are static,
essentially After=basic.target).
-- 

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

Re: [systemd-devel] Graphical session targets as standard

[Alberto Salvia Novella]

The graphical target not for the system, but for the user session:

systemctl --user status graphical-session.target
● graphical-session.target - Current graphical user session
   Loaded: loaded (/usr/lib/systemd/user/graphical-session.target; 
static; vendor preset: enabled)

   Active: inactive (dead)
 Docs: man:systemd.special(7)

cat /usr/lib/systemd/user/graphical-session.target
[Unit]
Description=Current graphical user session
Documentation=man:systemd.special(7)
Requires=basic.target
RefuseManualStart=yes
StopWhenUnneeded=yes


Alberto 


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Graphical session targets as standard

[Mantas Mikulėnas]

The thread is about systemd --user.

On Thu, Jun 28, 2018, 18:06 Reindl Harald  wrote:

> what problem needs to be solved?
>
> [root@srv-rhsoft:/usr/lib/systemd/system]$ ls | grep graphical
> drwxr-xr-x. 2 root root 4,0K 2018-05-04 12:46 graphical.target.wants
> lrwxrwxrwx  1 root root   16 2018-05-04 10:40 default.target ->
> graphical.target
> -rw-r--r--  1 root root  558 2018-02-21 12:29 graphical.target
> lrwxrwxrwx  1 root root   16 2018-05-04 10:40 runlevel5.target ->
> graphical.target
>
> [root@srv-rhsoft:/usr/lib/systemd/system]$ cat graphical.target
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
>
> [Unit]
> Description=Graphical Interface
> Documentation=man:systemd.special(7)
> Requires=multi-user.target
> Wants=display-manager.service
> Conflicts=rescue.service rescue.target
> After=multi-user.target rescue.service rescue.target
> display-manager.service
> AllowIsolate=yes
> [root@srv-rhsoft
>
> Am 28.06.2018 um 15:50 schrieb Ryan Gonzalez:
> > I *think* it's the login manager?
> >
> > On June 27, 2018 11:41:22 PM Alberto Salvia Novella
> >  wrote:
> >
> >> Currently many Linux Distributions don't activate
> >> graphical-session.target and graphical-session-pre.target during login.
> >>
> >> I liked to know which software should ideally be in charge of that. So
> >> I can inform their developers about it, and have that behavior widely
> >> adopted
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

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

Re: [systemd-devel] Graphical session targets as standard

[Peter Hoeg]

Reindl,


what problem needs to be solved?
[root@srv-rhsoft:/usr/lib/systemd/system]$ ls | grep graphical


we are talking about the *user* targets that will be activated by login 
managers, not the *system* targets.

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

Re: [systemd-devel] starting a service before anything else....

[Reindl Harald]

Am 28.06.2018 um 16:55 schrieb MALET Jean-Luc:
> I'm in charge of setting up an embedded solution based on debian, so on
> systemd, I'm more used to old init process, that was easy to tweak
> because based on script... but well... times seems now on systemd.
> 
> I'm really puzzled because since the documentation seems to lack
> information, I have to find information on tutorials that focus only on
> late services..
> 
> I found on one how to find the targets using "systemctl list-units
> --type=target" and some diagram explaining what target are suposed to be
> run in what order but well...
> 
> my issue is that I've to run a script as early as possible, before
> mounts are done because lot of service will fail without , so I created
> a service
> 
> [Unit]
> Description=mount some file systems before anything and prepare the system
> Before=systemd-remount-fs.service
+ DefaultDependencies=no
> 
> [Service]
> Type=oneshot
> ExecStart=/etc/init.d/setup.sh start


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

[systemd-devel] starting a service before anything else....

[MALET Jean-Luc]

Hi!

I'm in charge of setting up an embedded solution based on debian, so on 
systemd, I'm more used to old init process, that was easy to tweak 
because based on script... but well... times seems now on systemd.


I'm really puzzled because since the documentation seems to lack 
information, I have to find information on tutorials that focus only on 
late services..


I found on one how to find the targets using "systemctl list-units 
--type=target" and some diagram explaining what target are suposed to be 
run in what order but well...


my issue is that I've to run a script as early as possible, before 
mounts are done because lot of service will fail without , so I created 
a service



[Unit]
Description=mount some file systems before anything and prepare the system
Before=systemd-remount-fs.service

[Service]
Type=oneshot
ExecStart=/etc/init.d/setup.sh start

[Install]
WantedBy=swap.target


using journalctl I found that the first Reached point was the 
swap.target so it looked like a good WantedBy, but looking at the 
journalctl showed that the service was still not run in early systemd 
steps... so I added a Before rule using the "systemctl list-units 
--type=service" to guess what service where run on the system... and 
well... it's not working as expected... I still see my service run after 
some other services...


on sysV init, it was easy to track down what would be run and assign 
order... here I'm puzzled because there are only partial information 
from tutorials and it's not clear what will be run, what is the entry 
point target, how to list the dependencies since some are hidden and 
built in...


so can you help me? how can I run my service (before it was run in rcS 
script, so that we were sure that it was the first thing done)


thanks

JLM

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

Re: [systemd-devel] Graphical session targets as standard

[Reindl Harald]

what problem needs to be solved?

[root@srv-rhsoft:/usr/lib/systemd/system]$ ls | grep graphical
drwxr-xr-x. 2 root root 4,0K 2018-05-04 12:46 graphical.target.wants
lrwxrwxrwx  1 root root   16 2018-05-04 10:40 default.target ->
graphical.target
-rw-r--r--  1 root root  558 2018-02-21 12:29 graphical.target
lrwxrwxrwx  1 root root   16 2018-05-04 10:40 runlevel5.target ->
graphical.target

[root@srv-rhsoft:/usr/lib/systemd/system]$ cat graphical.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@srv-rhsoft

Am 28.06.2018 um 15:50 schrieb Ryan Gonzalez:
> I *think* it's the login manager?
> 
> On June 27, 2018 11:41:22 PM Alberto Salvia Novella
>  wrote:
> 
>> Currently many Linux Distributions don't activate
>> graphical-session.target and graphical-session-pre.target during login.
>>
>> I liked to know which software should ideally be in charge of that. So
>> I can inform their developers about it, and have that behavior widely
>> adopted
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Graphical session targets as standard

[Ryan Gonzalez]

I *think* it's the login manager?


On June 27, 2018 11:41:22 PM Alberto Salvia Novella  
wrote:



Currently many Linux Distributions don't activate
graphical-session.target and graphical-session-pre.target during login.

I liked to know which software should ideally be in charge of that. So I
can inform their developers about it, and have that behavior widely adopted.


Alberto 



--
___
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] the intended behavior of EnvironmentFile

[Lennart Poettering]

On Mi, 27.06.18 00:33, Igor Bukanov (i...@mir2.org) wrote:

> Hi,
> 
> the man page for systemd.exec tells that for EnvironmentFile:
> 
> The files listed with this directive will be read shortly before the
> process is executed (more specifically, after all processes from a
> previous unit state terminated. This means you can generate these
> files in one unit state, and read it with this option in the next).
> 
> Yet for a service unit with, for example,  several ExecStartPost
> commands the environment files are parsed before each invocation of
> ExecStartPost even if there is no change in the state of the unit and
> not all processes are terminated. I.e. when starting a service like:
> 
> [Service]
> Type=oneshot
> EnvironmentFile=-/run/foo.env
> ExecStart=/bin/sh -c 'echo FOO=BAR > /run/foo.env'
> ExecStartPost=/bin/sh -c 'echo $FOO; echo FOO=BAR2 > /run/foo.env; sleep 5&'
> ExecStartPost=/bin/sh -c 'echo $FOO; echo FOO=BAR3 > /run/foo.env'
> ExecStartPost=/bin/sh -c 'echo $FOO'
> 
> the log contains BAR BAR2 BAR3 even if there no change of the state in
> the unit state between ExecStartPost and the last ExecStartPost runs
> when the sleep command still runs.
> 
> It is just poor wording in the documentation, isn't it? I.e. the
> intended behavior is that the environment file are parsed before
> executing any Exec* line irrespective of the unit state, right?

Yes, it's poor wording. Could you file a github issue about this
please, so that we can fix it? (even better: post a PR)

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] systemd-tmpfiles subvolume handling vs. changing default btrfs root

[Lennart Poettering]

On Mi, 27.06.18 23:25, Ignaz Forster (ifors...@suse.de) wrote:

> 3) Set the default btrfs subvolume to the backup snapshot subvolume (or a
> copy of it)
> 
> I'm talking about case *3* here. Whenever one wants to roll back to a
> certain snapshot one would just call e.g.
>   btrfs subvolume set-default /.snapshots/123/snapshot/
> and reboot.
> 
> In contrast to case 1 and 2 there is no dedicated static "/" subvolume
> (which also implies this is not a "Nested", but a "Flat" or "Mixed" layout
> as outlined on
> https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout), but the
> default btrfs subvolume will always point to the snapshot of the last
> rollback. (On openSUSE this mechanism is also used for read-only systems
> where each update will switch to a new snapshot.)
> 
> 
> I'd sum this up as: subvolumes for system directories should never be
> created as children of a snapshot as snapshots are a variable thing.

tmpfiles won't create any subvolumes for you — except if they are
missing. tmpfiles can't guess the complex mappings you applied to your
tree, it can't know that you don't want to allow recursive snapshots,
but place them all in the same dir and bind mount them. Also, if I
understand correctly the way suse sets this up always *requires*
additions to fstab for any subvol created, which is clearly out of
focus for tmpfiles.

Also, tmpfiles won't actually create any subvols below /usr (unless a
user dropped something in to do that on its own), it will only do so
in the root dir for precisely /var, /tmp, /home and /srv. All others
are created below /var. Which means you rule of "don't create subvols
below system directories" isn't actually touched, because the
read-only OS is monopolized in /usr anyway... Or maybe I am still not
getting what you are trying to say?

> > The assumption systemd-tmpfiles makes is always that the subvolumes
> > it implicitly creates for you if they are missing are associated
> > with the subvolume they are created below, and that this means they
> > are snapshotted, removed and otheerwise managed along with them.
> 
> Keeping this logic more or less assumes that snapshots will always be used
> as static backups and pattern 3 from above must not be used.

I don't see that at all. I mean, this all depends how you want to
associate /var with /. my assumption is that they belong together, but
i figure that's not what you have in mind? you want to keep using the
same /var even though you switch back and forth to different /?

i am not sure if follow fully, but i think the model should be the
other way round: keep the root file system in one subvolume, and keep
/usr completely separate from that, and only combine the two through
bind mounts when you want to go for one specific version. In that
mode, all subvolumes systemd generates would be children of the root
subvolume, as they should be, but /usr would be separate.

> > systemd will never create disassociated subvolumes for you.
> 
> That's the problem - it will create subvolumes which will just disappear
> from the system when switching to the next snapshot.

Well, no, if snapshots are done recursively they wouldn't, they would
be switched at the same time.

> > But quite frankly I don't grok the problem at hand, i.e. what you are
> > trying to do, even.
> 
> Was this explanation any better?

Not really still, what I don't grok what precisely a "system snapshot"
in suse terms is actually supposed to entail. Is it supposed to
contain only the vendor RPMs, i.e. only /usr? or everything except
/home, /srv, /var, /tmp? Or the inverse of that?

Lennart

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