Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net пишет: Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Provide boot completed indication? systemd already provides starting and running states. Which logically implies that bootup is finished when starting is replaced by running. Add new timer condition which fires at this point? This will stop misusing Idle for poor man's replacement of proper boot completed event. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Wed, 23.04.14 21:01, Andrey Borzenkov (arvidj...@gmail.com) wrote: В Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net пишет: Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Provide boot completed indication? systemd already provides starting and running states. Which logically implies that bootup is finished when starting is replaced by running. Well, it works the other way round. running is entered as soon as there are no jobs anymore... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, On Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net wrote: [...] Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Yes. Of course, the meaning of long really depends... but it can be ~10 sec. Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Use systemctl enable debug-shell... OK will do. I didn't know about the debug shell. Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Wed, 23.04.14 13:15, Leonid Isaev (lis...@umail.iu.edu) wrote: Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... Hmm, thinking about this: the problem is actually not restricted to persistent timers, any timer that has OnBootSec=10ms or so is also affected by this, should the boot take longer than 10ms... Another option might be to change what Type=idle means: instead of making it wait until the job queue is empty it might be better to simply make it wait until the default job is finished (with other words, until graphical.target is reached). That way it doesn't matter what services are added in by timers... Somehow this appears like the better solution to me. This probably also means changing the manager state machine, and splitting its starting state into two: one state for the time until the default target is not yet reached, and a second state for the time until the job queue is actually empty. I added this to the TODO list now. I'd be happy to take a patch for this though! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 20:30:35 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 23.04.14 13:15, Leonid Isaev (lis...@umail.iu.edu) wrote: Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... Hmm, thinking about this: the problem is actually not restricted to persistent timers, any timer that has OnBootSec=10ms or so is also affected by this, should the boot take longer than 10ms... Another option might be to change what Type=idle means: instead of making it wait until the job queue is empty it might be better to simply make it wait until the default job is finished (with other words, until graphical.target is reached). I think it was discussed in the past and it was exact reason Idle was introduced - because default.target is not accurate representation of finished startup sequence. Is it technically possible to track jobs that resulted from dependency closure of default.target? I.e. all units pulled in (directly or indirectly) by default target? This would probably be more accurate approximation of at the end of startup and automatically fix problem discussed here. It would also provide more or less useful startup finished synchronization point. That way it doesn't matter what services are added in by timers... Somehow this appears like the better solution to me. This probably also means changing the manager state machine, and splitting its starting state into two: one state for the time until the default target is not yet reached, and a second state for the time until the job queue is actually empty. I added this to the TODO list now. I'd be happy to take a patch for this though! Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Am 22.04.2014 07:07, schrieb Lennart Poettering: On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote: According to [1], when a persistent timer runs its service on boot, it delays startup. Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'd have to build a test-case for this, since I have not seen any negative effect myself yet (I can't do this until later this week). I'm CC'ing the original reporter, maybe he can give more information. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler tho...@archlinux.org wrote: I'm CC'ing the original reporter, maybe he can give more information. I think you forgot to do that... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Am 22.04.2014 10:33, schrieb Tom Gundersen: On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler tho...@archlinux.org wrote: I'm CC'ing the original reporter, maybe he can give more information. I think you forgot to do that... Strange stuff - he is listed in CC in the mail I received, but his address is missing on-list. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, I'll try to answer all questions at once... On Tue, 22 Apr 2014 09:37:29 +0200 Thomas Bächler tho...@archlinux.org wrote: Am 22.04.2014 07:07, schrieb Lennart Poettering: Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. This is right for the usual, e.g. OnBootSec= timers. Just to give a little background, archlinux has recently replaced daily cron jobs (like indexing of man and locate databases) with OnCalendar= timers: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html . From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. Right. I see no delay between scheduling an OnCalendar= timer and starting the corresponding service. This wouldn't be a problem in general, but if the /var/lib/systemd/stamp-... file is old enough, the timer and service are launched at boot. However, the latter usually takes some time to start. Ideally, one would like to specify the above delay in the .timer file, because services started by the OnCalendar timers are sometimes maintainance jobs and not always needed for booting the system. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Tue, 22.04.14 12:13, Leonid Isaev (lis...@umail.iu.edu) wrote: Am 22.04.2014 07:07, schrieb Lennart Poettering: Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. This is right for the usual, e.g. OnBootSec= timers. Just to give a little background, archlinux has recently replaced daily cron jobs (like indexing of man and locate databases) with OnCalendar= timers: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html . Awesome! This sounds great! From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. Right. I see no delay between scheduling an OnCalendar= timer and starting the corresponding service. This wouldn't be a problem in general, but if the /var/lib/systemd/stamp-... file is old enough, the timer and service are launched at boot. However, the latter usually takes some time to start. Ideally, one would like to specify the above delay in the .timer file, because services started by the OnCalendar timers are sometimes maintainance jobs and not always needed for booting the system. Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Use systemctl enable debug-shell... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote: According to [1], when a persistent timer runs its service on boot, it delays startup. Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
