Re: [systemd-devel] networkd: How to keep ipv6 RA active but disable autoconf

2018-07-13 Thread Anthony Bourguignon 
Le vendredi 13 juillet 2018 à 17:08 +0200, Lennart Poettering a écrit :
> On Di, 10.07.18 15:29, Anthony Bourguignon (cont...@toniob.net)
> wrote:
> 
> > Hi,
> > 
> > The configuration with my provider is quite strange. I have to
> > activate
> > ipv6 RA to obtain a default route. But I don't want to have the
> > address
> > via autoconf. For that, I use a dhcpv6 pd, with static ip
> > configuration
> > after that.
> > 
> > Is there a way to activate RA but to disable autoconf ? In my
> > .network
> > conffile, I've got this :
> 
> This is not supported. Consider filing an RFE bug to request this.

The RFE is now opened :
  https://github.com/systemd/systemd/issues/9582

Thanks

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: send a dhcpv6 prefix delegation request

2018-07-13 Thread Anthony Bourguignon 
Le vendredi 13 juillet 2018 à 17:20 +0200, Lennart Poettering a écrit :
> On Di, 10.07.18 16:08, Anthony Bourguignon (cont...@toniob.net)
> wrote:
> 
> > Hello,
> > 
> > Is there a way to send a prefix delegation request when using
> > networkd
> > as a dhcpv6 client ?
> 
> There's explicit DHCPv6 PD support in current networkd versions, see
> IPv6PrefixDelegation= in systemd.network(5).

I've seen that option but the documentation is not very clear. I
thought it was only to activate PD on the server part. I'm probably
wrong.

I've just tried to add
  IPv6PrefixDelegation=True
in my .network file. But it didn't change anything in the dhcpv6
requests sent by this server. Only inf-req packets, not solicitation,
and no prefix delegation in it.

Did I miss something ?

Thanks

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

2018-07-13 Thread Paul Menzel 

Dear systemd folks,


I forgot to attach the logs.


Am 13.07.2018 um 20:20 schrieb Paul Menzel:


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
     argv_init[0] = init_filename;

     pr_info("Run %s as init process\n", init_filename);
     return do_execve(getname_kernel(init_filename),
     (const char __user *const __user *)argv_init,
     (const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[    0.287632] Run /sbin/init as init process
[    0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

     $ ls -lh /lib/systemd/systemd
     -rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.



Kind regards,

Paul
[0.00] Linux version 4.18.0-rc4-00097-g33ec366fda95 (root@f2fc51708d66) 
(gcc version 7.3.0 (Debian 7.3.0-24)) #96 SMP Fri Jul 13 15:26:28 UTC 2018
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] type 16
[0.00] BIOS-e820: [mem 0x1000-0x0009] usable
[0.00] BIOS-e820: [mem 0x000c-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xc7d3bfff] usable
[0.00] BIOS-e820: [mem 0xc7d3c000-0xc7ff] type 16
[0.00] BIOS-e820: [mem 0xc800-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00011eff] usable
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0xc7d3c max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-back
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0C000 mask FF800 write-back
[0.00]   2 base 08000 mask FC000 write-back
[0.00]   3 base 0 mask F8000 write-back
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00011f00 aka 4592M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] Scanning 1 areas for low memory corruption
[0.00] initial memory mapped: [mem 0x-0x0fff]
[0.00] Base memory trampoline at [(ptrval)] 9b000 size 16384
[0.00] BRK [0x0fc61000, 0x0fc61fff] PGTABLE
[0.00] log_buf_len: 33554432 bytes
[0.00] early log buf free: 259860(99%)
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0800 24 (v02 CORE  )
[0.00] ACPI: XSDT 0xC7D4D0E0 6C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: FACP 0xC7D4F850 F4 (v04 CORE   COREBOOT 
 CORE )
[0.00] ACPI: DSDT 0xC7D4D280 0025C7 (v02 ASROCK COREBOOT 
00010001 INTL 20180629)
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: SSDT 0xC7D4F950 8A (v02 CORE   COREBOOT 
002A CORE 002A)
[0.00] ACPI: TCPA 0xC7D4F9E0 32 (v02 CORE   COREBOOT 
 CORE )
[0.00] ACPI: APIC 0xC7D4FA20 5C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: HEST 0xC7D4FA80 28 (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: SSDT 0xC7D4FAB0 00168E (v02 AMDALIB 
0001 MSFT 0400)
[0.00] ACPI: SSDT 0xC7D51140 0003DE (v01 AMDPOWERNOW 
0001 AMD  0001)
[0.00] ACPI: VFCT

[systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

2018-07-13 Thread Paul Menzel 

Dear systemd folks,


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
argv_init[0] = init_filename;

pr_info("Run %s as init process\n", init_filename);
return do_execve(getname_kernel(init_filename),
(const char __user *const __user *)argv_init,
(const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[0.287632] Run /sbin/init as init process
[0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

$ ls -lh /lib/systemd/systemd
-rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.


Kind regards,

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

Re: [systemd-devel] .network has [Link] and there's already .link

2018-07-13 Thread Lennart Poettering 
On Fr, 13.07.18 18:52, Francis Moreau (francis.m...@gmail.com) wrote:

> Hello,
> 
> I dont understand .network has [Link] section whereas network device
> configuration can also done with .link file.
> 
> It seems that there's a overlap... what is the rational here ?

.link generally only contains link-specific options, while .network
generally only contains network-specific options. There are a few
options howver that are kinda in the middle, and fit into both
categories, for example the MTU. Hence .network has a section for that
kind of stuff, even though .link already has them.

Lennart

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

[systemd-devel] .network has [Link] and there's already .link

2018-07-13 Thread Francis Moreau 
Hello,

I dont understand .network has [Link] section whereas network device
configuration can also done with .link file.

It seems that there's a overlap... what is the rational here ?

Thank you in advance.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /var/log/journal full, journald is not removing journal files

2018-07-13 Thread Lennart Poettering 
On Mi, 11.07.18 12:54, Chris Murphy (li...@colorremedies.com) wrote:

> systemd-238-8.git0e0aa59.fc28.x86_64
> 
> I'm really confused by what I'm seeing.
> 
> Jul 10 09:13:40 f28h.local systemd-journald[493]: System journal
> (/var/log/journal/bbe68372db9f4c589a1f67f008e70864) is 1.2G, max 1.3G,
> 90.0M free.
> [chris@f28h ~]$ du -sh /var/log/journal/bbe68372db9f4c589a1f67f008e70864/
> 1.6G/var/log/journal/bbe68372db9f4c589a1f67f008e70864/
> [chris@f28h ~]$
> 
> [chris@f28h ~]$ df -h
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/nvme0n1p7  1.9G  1.9G   73M  97% /var/log
> 
> journald.conf is Fedora default except
> SystemMaxUse=2G
> 
> 
> 1. Somehow systemd-journald is deciding to max at 1.3G, instead of the
> specified 2G, which is fine. But I don't know how it arrives at this.
> 2. Clearly max 1.3G is being busted, the contents of var/log/journal
> are greater than the max. non-journal files total ~83M and have not
> grown at all in the last week (and multiple reboots).
> 3. If I change SystemMaxUse=1300M there is no change. No attempt by
> journald to clean up /var/log/journal, and no errors, it uses /run/log
> instead and never switches to persistent logging.
> 4. My reading of man journald.conf is that that SystemKeepFree=
> defaults to 15% of the file system space, so even with SystemMaxUse=2G
> journald should have deleted journal files before getting to 100%
> full.
> 5. If I boot with systemd.log_level=debug, there are no journald
> entries that help understand why there's no transition from volatile
> to persistent storage, i.e. hey var/log/journal is full, and also that
> I can't delete files because $reasons, or whatever.
> 
> Extra info: this is a 2G f2fs file system mounted at /var/log. Seems
> to be working well except for this little problem but I don't see it
> being the cause. journald isn't even attempting to delete its own
> journal files to free up space.

Any chance you can reproduce this on a less exotic file system?

Note that there is "journactl --vacuum-xyz=" these days, which let you
know what it's doing (in particular with debug logging turned on, by
setting the SYSTEMD_LOG_LEVEL=debug env var).

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] networkd: send a dhcpv6 prefix delegation request

2018-07-13 Thread Lennart Poettering 
On Di, 10.07.18 16:08, Anthony Bourguignon (cont...@toniob.net) wrote:

> Hello,
> 
> Is there a way to send a prefix delegation request when using networkd
> as a dhcpv6 client ?

There's explicit DHCPv6 PD support in current networkd versions, see
IPv6PrefixDelegation= in systemd.network(5).

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] logind: How to process enumerate buttons in parallel?

2018-07-13 Thread Lennart Poettering 
On Do, 12.07.18 16:51, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> Dear systemd folks,
> 
> 
> Trying to decrease the start-up time, I noticed that `systemd-logind`
> probes devices in serial(?) (instead of parallel).
> 
> From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`:
> 
> ```
> udev_list_entry_foreach(item, first) {
> _cleanup_(udev_device_unrefp) struct udev_device *d = NULL;
> int k;
> 
> d = udev_device_new_from_syspath(m->udev, 
> udev_list_entry_get_name(item));
> if (!d)
> return -ENOMEM;
> 
> k = manager_process_button_device(m, d);
> if (k < 0)
> r = k;
> }
> ```
> 
> The macro is defined as below:
> 
> ```
> /**
>  * udev_list_entry_foreach:
>  * @list_entry: entry to store the current position
>  * @first_entry: first entry to start with
>  *
>  * Helper to iterate over all entries of a list.
>  */
> #define udev_list_entry_foreach(list_entry, first_entry) \
> for (list_entry = first_entry; \
>  list_entry != NULL; \
>  list_entry = udev_list_entry_get_next(list_entry))
> ```
> 
> Is there a way to do that in parallel?

systemd components are generally single threaded. Probing input
devices from systemd is unlikely to be a performance problem. I mean,
we don't process 10K devices here, but usually not more than 25 or
so... Also the code isn't really CPU or IO bound here, it just does a
few open() and ioctl() calls mostly.

Before spending time on optimizing anything like this: did you did
profiling on this, that shows clearly that this is performance
relevant at all?

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] networkd: How to keep ipv6 RA active but disable autoconf

2018-07-13 Thread Lennart Poettering 
On Di, 10.07.18 15:29, Anthony Bourguignon (cont...@toniob.net) wrote:

> Hi,
> 
> The configuration with my provider is quite strange. I have to activate
> ipv6 RA to obtain a default route. But I don't want to have the address
> via autoconf. For that, I use a dhcpv6 pd, with static ip configuration
> after that.
> 
> Is there a way to activate RA but to disable autoconf ? In my .network
> conffile, I've got this :

This is not supported. Consider filing an RFE bug to request this.

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 to scale journald correctly?

2018-07-13 Thread Lennart Poettering 
On Di, 10.07.18 14:24, Martin Häcker (m...@sntl-publishing.com) wrote:

> 
> To work around this, we continued by increasing SystemMaxFileSize=20G to
> limit the amount of files journald would produce. This however led to
> the unexpected behaviour of journald exhausting the IO bandwith of the
> server it is running on. Documented here:
>  Interestingly this
> setting seemed to work well for some hours, but then suddenly let
> JournalD use up all IO resources of the system.
> 
> Which begs the question: What are the limits to file sizes, total log
> size, log intake rate, ... that journald is engineered to work well
> with? What can be reasonable values for these Settings? Where there any
> changes in recent releases that could affect this (not that I particular
> want to upgrade a core component of my CentOS systems).

Yes, the journal has received a ton of improvements in all areas since 219.

In general: splitting up too heavily makes journalctl grow with O(n)
where n is the number of split out files. This is the main performance
problem right now. THe O(n) thing is fixable, but so far nobody spent
the time to fix it fully.

journald is designed to just write out what is being thrown at it,
with the speed the underlying device permits. It is using relatively
large reception buffers for this, so that clients don't have to stall
on journald. If you flood journald heavily it will eventually cause
clients to block though.

In more recent journal versions (i.e. much newer than 219) log
metadata is cached, which will increase performance substantially
under load.

Also note that clients can slow journald considerably, if they for
example log at needlessly high log levels (that's because journald
will sync() after each append when it sees messages of CRIT, ALERT,
EMERG level...

journald's write logic is heavier than let's say syslog, as it builds
a bisection table for each field, as it adds entries to the end of
journal files, however, this shouldn't be overlay heavy.

I am not aware of any work on performance measurements for the
journald, and figuring out in detail how things scale, and were
improvements need to be made with greatest priority.

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] need to run systemctl --user daemon-reload to get USB device properly recognized

2018-07-13 Thread Lennart Poettering 
On Fr, 06.07.18 15:54, Matt Zagrabelny (mzagr...@d.umn.edu) wrote:

> Greetings,
> 
> I'm seeing some unexpected behavior for my systemd --user process.
> Background:
> 
> I've setup udev rules to fire off systemd --user units to download photos
> when my camera (PTP device) or my phone (MTP device) get plugged in. They
> are both USB devices:

Is this possibly the same issue as the following?

https://github.com/systemd/systemd/issues/9518

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] trying to hook into the luks crypt function in initramfs

2018-07-13 Thread Lennart Poettering 
On Fr, 06.07.18 01:25, Ratliff, John (jdrat...@iu.edu) wrote:

> I'd like to be able to unlock my luks encrypted drive (lvm -
> including the root partition) with a USB key, but if the USB key is
> not present, still ask for a passphrase.
> 
> I'm not clear on how systemd does the unlock during boot, but it
> seems that Fedora 28 and CentOS/RHEL 7 both use systemd for this
> task. Where would I look to change the behavior to do what I'm
> looking for?
> 
> In Debian/Ubuntu, there is a keyscript file that gets put into the
> initramfs, but I don't think theirs is systemd based. Arch has a
> similar method with a hook, but I've only used it with the
> non-systemd initramfs. Fedora has a crypt module, but I have to
> disable systemd or it won't work. I'm not sure what systemd is doing
> in the initramfs, so I'm not sure if I want to disable that module
> or not. I'm hoping there's a better way to interact with systemd.

systemd does not support keyscript, and there are no plans to add
this.

There's currently no easy way to do what you are trying to do, and
deal with the races inherent to the idea (i.e. the device the LUKS
volume is on might appear earlier or later than the USB key, hence
there must be a way).

My recommendation would be to hack up a small tool implementing this
concept:

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

Such a tool would look for the USB key as soon as the password is
queried, and supply it to the querier instantly.

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] Using udev to notify application of device insertion/removal

2018-07-13 Thread Lennart Poettering 
On Mo, 02.07.18 13:34, Paul D. DeRocco (pdero...@ix.netcom.com) wrote:

> System: Yocto-based RT Linux 4.10.17, systemd 232, 32-bit x86, no GUI.
> 
> I've created the following "midiUSB.rules" file:
> 
> ACTION=="add", KERNEL=="midiC*", SUBSYSTEM=="sound",
> SYMLINK+="snd/midi%b", RUN="/bin/touch /media/sda1/share/devchg"
> ACTION=="remove", KERNEL=="midiC*", SUBSYSTEM=="sound", RUN="/bin/touch
> /media/sda1/share/devchg"

This suggests the file you touch is located on removable media, which
makes me immediately wonder if maybe you are simply in some race,
where the removable media is not mounted at the time the touch runs.

Also, do note that systemd-udevd.service runs in its own mount
namespace, and mount propagation is somewhat limited.
> So it looks like it believes it's going to run my touch command when it's
> removed, but when I actually do it, I don't see the timestamp change.
> 
> Any ideas on what's wrong, or how to debug this further?

Run "strace -p1 -f -s500" on udevd, and look for the touch command
being execve()'ed anywhere.

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

2018-07-13 Thread Lennart Poettering 
On Fr, 29.06.18 21:04, Ignaz Forster (ifors...@suse.de) wrote:

> Reordered the quotes below for better reading flow.
> 
> Am 28.06.2018 um 10:52 schrieb Lennart Poettering:
> > > > 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?
> 
> That's the general idea, yes.*
> 
> Everything which contains variable or user data (i.e. which is not supposed
> to be rolled back like databases or files created by the user) will be put
> onto an own subvolume or partition.
> 
> For reference here's how this looks like on openSUSE Leap 15 again:
> ID parent top lvl path
> -- -- --- 
> 2575  5   /@
> 258257257 /@/var
> 259257257 /@/usr/local
> 260257257 /@/tmp
> 261257257 /@/srv
> 262257257 /@/root
> 263257257 /@/opt
> 264257257 /@/home
> 265257257 /@/boot/grub2/x86_64-efi
> 266257257 /@/boot/grub2/i386-pc
> 267257257 /@/.snapshots
> 411267267 /@/.snapshots/138/snapshot
> 412267267 /@/.snapshots/139/snapshot
> 
> 
> *) Some packages will still use /bin, /lib and the like, and those will be
> part of the snapshot; on the other hand distribution RPMs may also contain
> files or directories in e.g. /var, which will not be part of the snapshot.
> Because of that I'd prefer the term "static / read-only / unmodifiable part
> of the root file system" instead of "vendor RPMs".
> 
> > or everything except
> > /home, /srv, /var, /tmp?
> 
> Everything except the directories listed above, because those contain
> variable data which one usually doesn't want to reset just because e.g. a
> new kernel doesn't boot.
> That won't prevent the user from creating his own snapshots of these
> subvolumes of course.
> 
> > > > 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.
> 
> I think it's not relevant for this discussion, you were repeatedly talking
> about recursive snapshots now, however as far as I'm aware btrfs is not
> capable to doing that. I've found a patchset on
> https://www.spinics.net/lists/linux-btrfs/msg29205.html, but it seems the
> relevant parts for snapshot creation weren't added upstream.
> 
> So how are those recursive btrfs snapshots supposed to work?

So, systemd's btrfs code supports doing recursive snapshots (which is
exposed through "machinectl clone" or "systemd-nspawn
--ephemeral"). If the upstream btrfs tools don't support them, please
work with them to fix that. There's nothing too magic about them, it's
a pity that this isn't supported yet.

> > 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.
> 
> I agree that it's next to impossible to programmatically find out what a
> user intended to do with a specific layout.
> However in my opinion it would be preferable to create at least a working,
> though maybe not optimal configuration compared to a configuration which is
> known to break in several cases (independent of the distribution).
> 
> Instead of adding fstab entries (which I also have a bellyache with) it may
> be an alternative to create a mount unit instead. But yes, something would
> have to be done to mount those subvolumes on boot.

I am very much convinced that tmpfiles not should change mount
configuration. It's a tool to adjust file system objects on disk, and
it should remain that.

I think the much nicer approach is the one I suggested, i.e. where
subvol trees are always cloned in full, recursively, and it is solely
/usr and whatever else shall be disconnected fom them each tree that
is mounted into it.

> I'm wondering if just refusing to create a subvolume on a snapshot would be
> another option... That way the problem would be given back to the user or
> distribution.

My recommendation: if you really want to go with the design you
proposed, go ahead, but make sure you created the bind mounts early
enough, tmpfiles won't change them then. After all, tmpfiles will only
make changes if something is missing here, it will never change
anything that already exists into a subvol.

>

Re: [systemd-devel] [PATCH V1] Add L3 cache allocation settings in systemd

2018-07-13 Thread Lennart Poettering 
On Sa, 30.06.18 09:44, Zhangyanfei (YF) (yanfei.zh...@huawei.com) wrote:

> Hello,
> 
> I am sorry I can only send the patches by using email because of some
> security reasons and the limit of my workspace.

While we are fine with accepting smaller patches by email for complex
stuff (and this qualifies as such) we really need submissions via
github. Reviewing is otherwise such a mess.

Sorry,

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] weird systemd-inhibit behaviour

2018-07-13 Thread Lennart Poettering 
On Do, 28.06.18 22:24, Amish (anon.am...@gmail.com) wrote:

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

The docs are simply wrong on this one, please file a bug, so we fix them!

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

What happens if you run "systemctl -i poweroff" as unpriv user? Is
that honoured, or does that fail?

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] at replacement

2018-07-13 Thread Lennart Poettering 
On Do, 12.07.18 13:07, Filipe Brandenburger (filbran...@google.com) wrote:

> Hi,
> 
> On Thu, Jul 12, 2018 at 12:04 PM Matt Zagrabelny  wrote:
> > I know systemd can replace cron. Do folks use it to replace "at", too?
> >
> > I know it *can* - with two files per "at" entry and then enabling and 
> > starting the timer.
> >
> > Is there an easier with to replace "at" with systemd than creating two 
> > files and enabling and starting the timer?
> 
> Take a look at systemd-run and, in particular, options such as
> --on-active=, --on-calendar= and --timer-property=, which allow you to
> set a .timer option on demand for a single one-off command.
> 
> https://www.freedesktop.org/software/systemd/man/systemd-run.html#--on-active=
> 
> I hope this helps!

One addition to the above: note that "at"'s queue is maintained
persistently, while timers created transiently with "systemd-run" are
lost on the next reboot.

Lennart

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