Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
12.07.2020 23:37, Uoti Urpala пишет: > On Sun, 2020-07-12 at 17:13 +0300, Andrei Borzenkov wrote: >> 12.07.2020 16:21, Amish пишет: >>> I have a timer file like this: >>> >>> [Unit] >>> Description=Foo >>> After=multi-user.target >>> >>> [Timer] >>> OnCalendar=*:0/5 >>> Persistent=false >>> >>> [Install] >>> WantedBy=timers.target > > >>> Because AFAIK timers.target runs before multi-user.target. But here >>> something inside timers.target waits for multi-user.target. >>> >>> So how does systemd resolve this loop? >>> >> >> There is no loop. There is no transitive dependency between timer unit >> and service unit. Timer unit gets started early and enqueues start job >> for service unit; this start job waits for multi-user.target according >> to After dependency. Mulitple invocation of timer will try enqueue start >> job again which will simply be merged with existing pending request. > > But shouldn't the After line be in the .service file, not the timer, in > this case? The timer should be ready early if it's activated by > timers.target, the service should wait before running. > Sorry, I did not pay attention. In this case there is no loop as well, because timers.target itself does not have any Before dependencies by default. So timer.target becomes active after multi-user.target but it does not really affect anything. In particular other timers will be activated as soon as possible, they won't be delayed until timers.target is active. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
On Sun, 2020-07-12 at 17:13 +0300, Andrei Borzenkov wrote: > 12.07.2020 16:21, Amish пишет: > > I have a timer file like this: > > > > [Unit] > > Description=Foo > > After=multi-user.target > > > > [Timer] > > OnCalendar=*:0/5 > > Persistent=false > > > > [Install] > > WantedBy=timers.target > > Because AFAIK timers.target runs before multi-user.target. But here > > something inside timers.target waits for multi-user.target. > > > > So how does systemd resolve this loop? > > > > There is no loop. There is no transitive dependency between timer unit > and service unit. Timer unit gets started early and enqueues start job > for service unit; this start job waits for multi-user.target according > to After dependency. Mulitple invocation of timer will try enqueue start > job again which will simply be merged with existing pending request. But shouldn't the After line be in the .service file, not the timer, in this case? The timer should be ready early if it's activated by timers.target, the service should wait before running. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-analyze security and SystemCallFilter
why are these bad and scored? including syscalls to the blacklist is hardly wrong systemd-243.8-1.fc31.x86_64 ✗ SystemCallFilter=~@clockSystem call blacklist defined for service, and @clock is included 0.1 ✗ SystemCallFilter=~@debugSystem call blacklist defined for service, and @debug is included 0.1 ✗ SystemCallFilter=~@module System call blacklist defined for service, and @module is included 0.1 ✗ SystemCallFilter=~@mountSystem call blacklist defined for service, and @mount is included 0.1 ✗ SystemCallFilter=~@raw-io System call blacklist defined for service, and @raw-io is included 0.1 ✗ SystemCallFilter=~@reboot System call blacklist defined for service, and @reboot is included 0.1 ✗ SystemCallFilter=~@swap System call blacklist defined for service, and @swap is included0.1 ✗ SystemCallFilter=~@privileged System call blacklist defined for service, and @privileged is not included 0.2 ✗ SystemCallFilter=~@resourcesSystem call blacklist defined for service, and @resources is not included 0.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 7/11/20 11:05 PM, Paul Menzel wrote: > If systemd is still the same, your distribution upgrade wasn’t relevant to > the issue at hand, was it? no, I didn't state that it was. What's relevant is that I followed the suggested workaround made to me, and there was no observed effect. It was simply mentioned here on the off-chance that @ distro-upgrade some backport/patch/fix might have been implemented. Clearly it wasn't. > The upstream project only supports the latest two versions of systemd, which > currently are 244 and 245. Please report your issues to openSUSE. Lennart was kind enough to comment previously. I'm asking Lennart for additional comment on his recommendation ... made here, so asked here. > Please report your issues to openSUSE. as stated in my OP, it already has been. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald, syslog.socket and service activation
03.07.2020 12:09, Thomas HUMMEL пишет: > > > On 02/07/2020 20:48, Andrei Borzenkov wrote: > > >> Once again - dependencies in systemd are between jobs, not between units. > > Ok. I may have missed some docs but I've read several man sections > (likesystemd.service(5) and so on) as well as some 0pointer blog > articles) and I did experiment a lot. > I did not see this explained as clearly as you do here. At the opposite > it tends to focus on units (at least that's how I've read it the first > time), hence the confusion ? In fact, when reading those for the first > time I was left wanting to know more about transactions and jobs (which > are mentioned but really quickly). [Note that this is by no way a > criticism, just a/my feedback]. Watching debug logs gave me hints but > were not sufficient to come to the understanding you give me right now. > systemd was designed to perform one single task - start well defined collection of units during system boot. When you consider this, it does not really matter whether you talk about unit or job dependency, end result is the same. I sincerely hope it was honest self delusion and not deliberate marketing trick to facilitate acceptance. Later systemd became abused as dynamic service manager, misleading documentation played not the last role in it. This thread is typical example. >> Rule 1: "B requires A" means "when starting B also submit start job for >> A and if this job failed *before we start activating B* cancel >> activation of B". If there is already start job for A for other reasons, >> the first part does nothing. > > Ok. What could be other reasons and do you mean this other reason would > itself have already added the A dependency and its management for itself ? > Unit could have been started (or at least requested to be started) due to dependencies of other units. >> >> Rule 2: "B after A" means "if start job for A is present in job queue >> wait for this job to complete before proceeding with start job for B". >> >> In your case on boot you have general Before dependency syslog.socket - >> sockets.target - basic.target - rsyslog.service and start request for >> both syslog.socket and rsyslog.service are queued. Start job for >> rsyslog.service is always delayed at least after basic.target (rule 2). >> At this point systemd already tried and failed to start syslog.socket, >> so rule 1 applies. > > Ok. So I guess my test when I, after reboot, run 4 ou 5 systemctl start > rsyslog.service and only the last one succeeds corresponds to this "race > condition" you described above ? > Yes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
12.07.2020 16:21, Amish пишет: > Hello, > > This is a question out of curiosity and not currently any problem. > > I have a timer file like this: > > [Unit] > Description=Foo > After=multi-user.target > > [Timer] > OnCalendar=*:0/5 > Persistent=false > > [Install] > WantedBy=timers.target > > And corresponding service file like this: > > [Unit] > Description=Foo > > [Service] > Type=oneshot > ExecStart=-/usr/bin/checkservices > > /usr/bin/checkservices checks if some important services are running and > sends alert if not. > > Above timer is supposed to run every five minutes. But not while system > is still booting. > > If I do not put After=multi-user.target then timer gets triggered even > before those services have begun (while booting) and sends false alarm. > > With above settings, I do not face that issue. > > But just out of curiosity I am eager to know if this or something > similar can cause loop and hang system forever from booting? > > Because AFAIK timers.target runs before multi-user.target. But here > something inside timers.target waits for multi-user.target. > > So how does systemd resolve this loop? > There is no loop. There is no transitive dependency between timer unit and service unit. Timer unit gets started early and enqueues start job for service unit; this start job waits for multi-user.target according to After dependency. Mulitple invocation of timer will try enqueue start job again which will simply be merged with existing pending request. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
Hello, This is a question out of curiosity and not currently any problem. I have a timer file like this: [Unit] Description=Foo After=multi-user.target [Timer] OnCalendar=*:0/5 Persistent=false [Install] WantedBy=timers.target And corresponding service file like this: [Unit] Description=Foo [Service] Type=oneshot ExecStart=-/usr/bin/checkservices /usr/bin/checkservices checks if some important services are running and sends alert if not. Above timer is supposed to run every five minutes. But not while system is still booting. If I do not put After=multi-user.target then timer gets triggered even before those services have begun (while booting) and sends false alarm. With above settings, I do not face that issue. But just out of curiosity I am eager to know if this or something similar can cause loop and hang system forever from booting? Because AFAIK timers.target runs before multi-user.target. But here something inside timers.target waits for multi-user.target. So how does systemd resolve this loop? Thanks in advance Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
