[systemd-devel] PrivateNetwork=yes is memory costly
Hi, It seems that PrivateNetwork=yes is a memory consuming directive. The kernel seems to allocate quite an amount of memory for each service (~50 kB) that has this directive enabled. I wonder if this is expected and if anyone has had similar experience? Is there any ways to reduce the usage? Best Regards Christopher Wong
[systemd-devel] Antw: Re: [systemd‑devel] Antw: [EXT] Re: timer "OnBootSec=15m" not triggering
>>> Lennart Poettering schrieb am 07.03.2022 um 14:08 in Nachricht : > On Mo, 07.03.22 12:24, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> Thanks for that. The amazing things are that "systemd.analyze verify" finds > no >> problem and "enable" virtually succeeds, too: > > Because there is no problem really: systemd allows you to define your > targets as you like, and we generally focus on a model where you can > extend stuff without requiring it to be installed. i.e. we want to > allow lose coupling, where stuff can be ordered against other stuff, > or be pulled in by other stuff without requiring that the other stuff > to be hard installed. Thus you can declare that you want to be pulled > in by a target that doesn't exist, and that's *not* considered an > issue, because it might just mean that you haven't installed the > package that defines it. > > Example: if you install mysql and apache, then there's a good reason > you want that mysql runs before apache, so that the web apps you run > on apache can access mysql. Still it should be totally OK to install > one without the other, and it's not a bug thus if one refers to the > other in its unit files, even if the other thing is not installed. Hi! Well, I think it is more likely that the user wants to refer to an existing target rather than refering to a future target. Likewise verify complains about a missing manual page (Documentation) and about missing executables. Command ... is not executable: No such file or directory ...: man ... command failed with code 16 To be consistent, verify should also complain about missing targets referred to. (The manual page and executable could be added at some later time, too) Regards, Ulrich > > Lennart > > ‑‑ > Lennart Poettering, Berlin
Re: [systemd-devel] Antw: [EXT] Re: timer "OnBootSec=15m" not triggering
On Mo, 07.03.22 12:24, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Thanks for that. The amazing things are that "systemd.analyze verify" finds no > problem and "enable" virtually succeeds, too: Because there is no problem really: systemd allows you to define your targets as you like, and we generally focus on a model where you can extend stuff without requiring it to be installed. i.e. we want to allow lose coupling, where stuff can be ordered against other stuff, or be pulled in by other stuff without requiring that the other stuff to be hard installed. Thus you can declare that you want to be pulled in by a target that doesn't exist, and that's *not* considered an issue, because it might just mean that you haven't installed the package that defines it. Example: if you install mysql and apache, then there's a good reason you want that mysql runs before apache, so that the web apps you run on apache can access mysql. Still it should be totally OK to install one without the other, and it's not a bug thus if one refers to the other in its unit files, even if the other thing is not installed. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: timer "OnBootSec=15m" not triggering
>>> Mantas Mikulenas schrieb am 07.03.2022 um 10:39 in Nachricht : > On Mon, Mar 7, 2022 at 11:22 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> Hi! >> >> I wrote some services that should run when booting and some time after >> booting. >> As it seems the service to run during boot works, but the timer-triggered >> one >> does not. >> I have no idea why. >> >> Here are the details: >> # systemctl status prevent-fencing-loop.service >> ● prevent-fencing-loop.service - Prevent Pacemaker Fencing-Loop >> Loaded: loaded (/usr/lib/systemd/system/prevent-fencing-loop.service; >> enabled; vendor preset: disabled) >> Active: inactive (dead) since Sat 2022-03-05 10:33:50 CET; 1 day 23h >> ago >>Docs: man:boot-loop-handler(8) >>Main PID: 5226 (code=exited, status=0/SUCCESS) >> >> Mar 05 10:33:50 h19 systemd[1]: Starting Prevent Pacemaker Fencing-Loop... >> Mar 05 10:33:50 h19 boot-loop-handler[5234]: 1 of 4 allowable boots >> Mar 05 10:33:50 h19 systemd[1]: prevent-fencing-loop.service: Succeeded. >> Mar 05 10:33:50 h19 systemd[1]: Finished Prevent Pacemaker Fencing-Loop. >> >> So this service ran during boot. >> >> # systemctl status reset-boot-counter.timer >> ● reset-boot-counter.timer - Reset Boot-Counter after 15 minutes >> Loaded: loaded (/usr/lib/systemd/system/reset-boot-counter.timer; >> enabled; vendor preset: disabled) >> Active: inactive (dead) >> Trigger: n/a >> > > It's not a problem with any of the [Timer] On* configuration – the problem > is that the whole .timer unit isn't active, so its triggers won't get > scheduled in the first place. > > >> [Install] >> WantedBy=timer.target >> > > The timer is not being scheduled because it's WantedBy a nonexistent > target. I think you meant 'timer*s*.target' here. Hi! Thanks for that. The amazing things are that "systemd.analyze verify" finds no problem and "enable" virtually succeeds, too: # systemctl enable reset-boot-counter.timer Created symlink /etc/systemd/system/timer.target.wants/reset-boot-counter.timer → /usr/lib/systemd/system/reset-boot-counter.timer. But you are correct that the target is "timers": # ll /etc/systemd/system/timer* /etc/systemd/system/timer.target.wants: total 4 lrwxrwxrwx 1 root root 48 Mar 7 12:05 reset-boot-counter.timer -> /usr/lib/systemd/system/reset-boot-counter.timer /etc/systemd/system/timers.target.wants: total 40 lrwxrwxrwx 1 root root 42 Nov 6 2020 backup-rpmdb.timer -> /usr/lib/systemd/system/backup-rpmdb.timer lrwxrwxrwx 1 root root 46 Nov 6 2020 backup-sysconfig.timer -> /usr/lib/systemd/system/backup-sysconfig.timer lrwxrwxrwx 1 root root 43 Nov 6 2020 btrfs-balance.timer -> /usr/lib/systemd/system/btrfs-balance.timer lrwxrwxrwx 1 root root 41 Nov 6 2020 btrfs-scrub.timer -> /usr/lib/systemd/system/btrfs-scrub.timer lrwxrwxrwx 1 root root 43 Nov 6 2020 check-battery.timer -> /usr/lib/systemd/system/check-battery.timer lrwxrwxrwx 1 root root 36 Nov 6 2020 fstrim.timer -> /usr/lib/systemd/system/fstrim.timer lrwxrwxrwx 1 root root 39 Nov 6 2020 logrotate.timer -> /usr/lib/systemd/system/logrotate.timer lrwxrwxrwx 1 root root 35 Nov 9 2020 mandb.timer -> /usr/lib/systemd/system/mandb.timer lrwxrwxrwx 1 root root 45 Nov 6 2020 snapper-cleanup.timer -> /usr/lib/systemd/system/snapper-cleanup.timer lrwxrwxrwx 1 root root 46 Nov 6 2020 snapper-timeline.timer -> /usr/lib/systemd/system/snapper-timeline.timer Basically I shouldn't have trusted Message-ID: <7d547aa30624f2dc8d22ea7f84507fa1d8e9c678.ca...@gmx.net> ;-) Regards, Ulrich > > -- > Mantas Mikulėnas
Re: [systemd-devel] timer "OnBootSec=15m" not triggering
[Install] WantedBy=timer.target It's supposed to be timers.target
Re: [systemd-devel] timer "OnBootSec=15m" not triggering
On Mon, Mar 7, 2022 at 11:22 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > Hi! > > I wrote some services that should run when booting and some time after > booting. > As it seems the service to run during boot works, but the timer-triggered > one > does not. > I have no idea why. > > Here are the details: > # systemctl status prevent-fencing-loop.service > ● prevent-fencing-loop.service - Prevent Pacemaker Fencing-Loop > Loaded: loaded (/usr/lib/systemd/system/prevent-fencing-loop.service; > enabled; vendor preset: disabled) > Active: inactive (dead) since Sat 2022-03-05 10:33:50 CET; 1 day 23h > ago >Docs: man:boot-loop-handler(8) >Main PID: 5226 (code=exited, status=0/SUCCESS) > > Mar 05 10:33:50 h19 systemd[1]: Starting Prevent Pacemaker Fencing-Loop... > Mar 05 10:33:50 h19 boot-loop-handler[5234]: 1 of 4 allowable boots > Mar 05 10:33:50 h19 systemd[1]: prevent-fencing-loop.service: Succeeded. > Mar 05 10:33:50 h19 systemd[1]: Finished Prevent Pacemaker Fencing-Loop. > > So this service ran during boot. > > # systemctl status reset-boot-counter.timer > ● reset-boot-counter.timer - Reset Boot-Counter after 15 minutes > Loaded: loaded (/usr/lib/systemd/system/reset-boot-counter.timer; > enabled; vendor preset: disabled) > Active: inactive (dead) > Trigger: n/a > It's not a problem with any of the [Timer] On* configuration – the problem is that the whole .timer unit isn't active, so its triggers won't get scheduled in the first place. > [Install] > WantedBy=timer.target > The timer is not being scheduled because it's WantedBy a nonexistent target. I think you meant 'timer*s*.target' here. -- Mantas Mikulėnas
[systemd-devel] timer "OnBootSec=15m" not triggering
Hi! I wrote some services that should run when booting and some time after booting. As it seems the service to run during boot works, but the timer-triggered one does not. I have no idea why. Here are the details: # systemctl status prevent-fencing-loop.service ● prevent-fencing-loop.service - Prevent Pacemaker Fencing-Loop Loaded: loaded (/usr/lib/systemd/system/prevent-fencing-loop.service; enabled; vendor preset: disabled) Active: inactive (dead) since Sat 2022-03-05 10:33:50 CET; 1 day 23h ago Docs: man:boot-loop-handler(8) Main PID: 5226 (code=exited, status=0/SUCCESS) Mar 05 10:33:50 h19 systemd[1]: Starting Prevent Pacemaker Fencing-Loop... Mar 05 10:33:50 h19 boot-loop-handler[5234]: 1 of 4 allowable boots Mar 05 10:33:50 h19 systemd[1]: prevent-fencing-loop.service: Succeeded. Mar 05 10:33:50 h19 systemd[1]: Finished Prevent Pacemaker Fencing-Loop. So this service ran during boot. # systemctl status reset-boot-counter.timer ● reset-boot-counter.timer - Reset Boot-Counter after 15 minutes Loaded: loaded (/usr/lib/systemd/system/reset-boot-counter.timer; enabled; vendor preset: disabled) Active: inactive (dead) Trigger: n/a Triggers: ● reset-boot-counter.service Docs: man:boot-loop-handler(8) So my guess is the timer never triggered, and the service was never started: # systemctl status reset-boot-counter.service ● reset-boot-counter.service - Reset Boot-Counter for detecting Fencing-Loop Loaded: loaded (/usr/lib/systemd/system/reset-boot-counter.service; static) Active: inactive (dead) Docs: man:boot-loop-handler(8) The timer is: # systemctl cat reset-boot-counter.timer # /usr/lib/systemd/system/reset-boot-counter.timer [Unit] Description=Reset Boot-Counter after 15 minutes Documentation=man:boot-loop-handler(8) [Timer] OnBootSec=15m AccuracySec=1s [Install] WantedBy=timer.target "systemd-analyze verify" finds no problems. systemd being used is that of SLES15 SP3 (probably also openSUSE LEap 15.3) (systemd-246.16-150300.7.39.1.x86_64) Regards, Ulrich
