Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

Hey Silvio, On 07/07/2021 20:04, Silvio Knizek wrote: after touching /etc/fstab you're supposed to run `systemctl daemon- reload` to re-trigger the generators. This is in fact a feature to announce changes in configuration files to systemd. See man:systemd.generator for more information.

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

On Thu, Jul 8, 2021 at 10:12 AM Christian Rohmann < christian.rohm...@frittentheke.de> wrote: > Hey Silvio, > On 07/07/2021 20:04, Silvio Knizek wrote: > > after touching /etc/fstab you're supposed to run `systemctl daemon- > reload` to re-trigger the generators. This is in fact a feature to >

[systemd-devel] Antw: [EXT] Re: Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

>>> Christian Rohmann schrieb am 08.07.2021 >>> um 09:12 in Nachricht <23423e6a-4c69-1683-8758-40f98d444...@frittentheke.de>: ... > Otherwise the "reaction" of an unmount to a just successfully happend > mount is still quite surprising to a user. When trying to fix a broken system, my first

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

Hey Mantas, On 08/07/2021 10:39, Mantas Mikulėnas wrote: I am then just wondering why the issue referred to (https://github.com/systemd/systemd/issues/1741 ) is still open? Are there still further plans to make systemd properly

Re: [systemd-devel] Restricting swap usage for a process managed via systemd

Thanks Mantas for replying. I have made the below changes. Added systemd.unified_cgroup_hierarchy=1 in /etc/default/grub ran sudo update-grub and rebooted the node. GRUB_CMDLINE_LINUX="audit=1 rootdelay=180 nousb net.ifnames=0 biosdevname=0 fsck.mode=force fsck.repair=yes ipv6.disable=1

[systemd-devel] Expired Message in Log

Hi Folks, For my customer I have to verify the logger in its system, which is journald (241). For that I have written some tests that should verify if expired messages will been thrown out of the log. As you can see, the configuration is set in that way that messages older than 12 months shall

Re: [systemd-devel] Expired Message in Log

On 08.07.2021 18:33, Andreas Krueger wrote: > Hi Folks, > > For my customer I have to verify the logger in its system, which is journald > (241). For that I have written some tests that should verify if expired > messages will been thrown out of the log. As you can see, the configuration > is

Re: [systemd-devel] Restricting swap usage for a process managed via systemd

Hello Debraj. On Thu, Jul 08, 2021 at 05:10:44PM +0530, Debraj Manna wrote: > >> Linux vrni-platform 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 > >> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > [...] > GRUB_CMDLINE_LINUX="audit=1 rootdelay=180 nousb net.ifnames=0 biosdevname=0 >

Re: [systemd-devel] Concurrent login / daemon-reload produces abandoned sessions

Hello Nicolas. On Wed, Jul 07, 2021 at 02:12:51PM +0200, Nicolas Bock wrote: > Using systemd-248.3-1ubuntu1 on Ubuntu Impish the following > script produces multiple abandoned sessions: > > $ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl > daemon-reload & ssh localhost