Re: systemd PathExists triggers
For reference, it was reported upstream originally as a regression [1] until Poettering confirmed that it was a fix for a broken behaviour [2]. For those interested in the details, reading the discussion there might help understand the context a little better. [1] https://github.com/systemd/systemd/issues/16669 [2] https://github.com/systemd/systemd/issues/16669#issuecomment-691193254 On Thu, Oct 1, 2020 at 10:21 AM Dimitri John Ledkov wrote: > > Conditions* are unaffected at all, and are unrelated to the issue at > hand whatsoever. > > On Thu, 1 Oct 2020 at 08:33, Christian Ehrhardt > wrote: > > > > On Wed, Sep 30, 2020 at 7:43 PM Brian Murray wrote: > > > > > > Recently there was a systemd change regarding PathExists for > > > systemd.path units that made systemd behave the way it was documented to > > > work. The effect being that if the PathExists or PathExistsGlob > > > condition is met the service is continually started which may not be the > > > behavior some packages expect as it didn't used to work that way. > > > > > > As an example apport's autoreport service uses PathExistsGlob to check > > > for a .crash file and then calls whoopsie-upload-all which used to run > > > once when the .crash file appeared. As of Groovy whoopsie-upload-all was > > > called continuously thereby causing systemd to use 100% of your CPU[1]. > > > > > > While this is resolved for apport's case, the Foundation's team thought > > > it was worth mentioning as other package's services may also be > > > impacted. > > > > Thanks Brian for your warning! > > I see in your list some .path files e.g. the aforementioned > > apport-autoreport.path > > that I understand if using a PathExist* will have changed. Of those the > > list [2] > > contains 9 to look at. > > > > I beg your pardon, but the list is vast due to including any > > "Type=oneshot" as well. > > And from the summary you gave I don't see why those are included as well. > > Looking at the first in the list that probably everyone has installed I see: > > a) > > /lib/systemd/system/alsa-restore.service there are no associated .path > > files, only > > ConditionPathExists in the unit itself - are those also affected? > > b) > > Looking slightly further /lib/systemd/system/apt-daily.service even > > has no associated > > .path nor any *Exist* statement. > > > > My question would now be - are those files of type (a) or (b) all also > > affected in > > some way or is the "critical list" actually much shorter? I was wondering > > if you > > could help to clarify before everyone that feels responsible for a package > > with > > a file in that list is diving into and re-understanding the case. > > > > Thanks in advance, > > Christian > > > > > An archive search[2] (thanks Seth!) was done of services which are > > > Type=oneshot or utilize a PathExists or PathExistsGlob. Briefly scanning > > > the list the following packages should probably be looked at: > > > > > > mandos-client > > > ostree > > > python-diskimage-builder > > > ubuntu-report > > > > > > [1] http://launchpad.net/bugs/1891657 > > > [2] https://paste.ubuntu.com/p/k5Gj7rQ9FX/ > > > > > > Cheers, > > > -- > > > Brian Murray > > > > > > -- > > > ubuntu-devel mailing list > > > ubuntu-devel@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > > > > > -- > > Christian Ehrhardt > > Staff Engineer, Ubuntu Server > > Canonical Ltd > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Regards, > > Dimitri. > > -- > Regards, > > Dimitri. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd PathExists triggers
Conditions* are unaffected at all, and are unrelated to the issue at hand whatsoever. On Thu, 1 Oct 2020 at 08:33, Christian Ehrhardt wrote: > > On Wed, Sep 30, 2020 at 7:43 PM Brian Murray wrote: > > > > Recently there was a systemd change regarding PathExists for > > systemd.path units that made systemd behave the way it was documented to > > work. The effect being that if the PathExists or PathExistsGlob > > condition is met the service is continually started which may not be the > > behavior some packages expect as it didn't used to work that way. > > > > As an example apport's autoreport service uses PathExistsGlob to check > > for a .crash file and then calls whoopsie-upload-all which used to run > > once when the .crash file appeared. As of Groovy whoopsie-upload-all was > > called continuously thereby causing systemd to use 100% of your CPU[1]. > > > > While this is resolved for apport's case, the Foundation's team thought > > it was worth mentioning as other package's services may also be > > impacted. > > Thanks Brian for your warning! > I see in your list some .path files e.g. the aforementioned > apport-autoreport.path > that I understand if using a PathExist* will have changed. Of those the list > [2] > contains 9 to look at. > > I beg your pardon, but the list is vast due to including any > "Type=oneshot" as well. > And from the summary you gave I don't see why those are included as well. > Looking at the first in the list that probably everyone has installed I see: > a) > /lib/systemd/system/alsa-restore.service there are no associated .path > files, only > ConditionPathExists in the unit itself - are those also affected? > b) > Looking slightly further /lib/systemd/system/apt-daily.service even > has no associated > .path nor any *Exist* statement. > > My question would now be - are those files of type (a) or (b) all also > affected in > some way or is the "critical list" actually much shorter? I was wondering if > you > could help to clarify before everyone that feels responsible for a package > with > a file in that list is diving into and re-understanding the case. > > Thanks in advance, > Christian > > > An archive search[2] (thanks Seth!) was done of services which are > > Type=oneshot or utilize a PathExists or PathExistsGlob. Briefly scanning > > the list the following packages should probably be looked at: > > > > mandos-client > > ostree > > python-diskimage-builder > > ubuntu-report > > > > [1] http://launchpad.net/bugs/1891657 > > [2] https://paste.ubuntu.com/p/k5Gj7rQ9FX/ > > > > Cheers, > > -- > > Brian Murray > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Regards, Dimitri. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Second Groovy Gorilla test rebuild
On Tue, Sep 29, 2020 at 11:07 AM Christian Ehrhardt wrote: > > On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher wrote: > > > > Hey Matthias, > > > > Le 28/09/2020 à 18:07, Matthias Klose a écrit : > > > Some build failures on ppc64el and s390x are caused by a buildd issue, > > > and will > > > be retried soonish. Please ignore these where you see a ftbfs just on > > > those > > > architectures, but successes on the other architectures. > > > > There seems to be some flakyness on arm as well, are those going to be > > retried or should that be requested by e.g pinging you? > > > > Some examples > > > > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz > > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz > > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz > > Adding the same armhf dependency issue on these: > htop: > https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz > openvpn: > https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz > I see that Laney already filed a bug about that with IS. > > Furthermore some armhf issues are due to > https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435 > php7.4: > https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz > > When doing an initial triage of some errors I found three sets of > recurring issues: > 1. rpc includes like "rpc/rpc.h: No such file" > 2. better null checking like " -Werror=nonnull" or "directive argument is > null" > 3. linker shows "multiple definitions of" Just as FYI to save you some debugging, common issue #3 is due to gcc now defaulting to -fno-common Most of the time that is due to missing "extern" declarations and the fix is to add them. This even is the first entry on [1] Porting to GCC 10 page. But there is one more case which is less clear than missing "extern", Defines that are meant to be linked together like the following also trigger it: #define __shared __asm__ ( "_shared_bss" ) __aligned The fix here is to add back -fcommon for such. [1]: https://gcc.gnu.org/gcc-10/porting_to.html > #2 likely comes down to fixing code or disabling the warning for now. > But for #1 and #3 I think there is a general change and every affected > package likely will need the similar fix. > So if someone already debugged those it would be great to let the others know. > > > > Cheers, > > Sebastien Bacher > > > > > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd PathExists triggers
On Wed, Sep 30, 2020 at 7:43 PM Brian Murray wrote: > > Recently there was a systemd change regarding PathExists for > systemd.path units that made systemd behave the way it was documented to > work. The effect being that if the PathExists or PathExistsGlob > condition is met the service is continually started which may not be the > behavior some packages expect as it didn't used to work that way. > > As an example apport's autoreport service uses PathExistsGlob to check > for a .crash file and then calls whoopsie-upload-all which used to run > once when the .crash file appeared. As of Groovy whoopsie-upload-all was > called continuously thereby causing systemd to use 100% of your CPU[1]. > > While this is resolved for apport's case, the Foundation's team thought > it was worth mentioning as other package's services may also be > impacted. Thanks Brian for your warning! I see in your list some .path files e.g. the aforementioned apport-autoreport.path that I understand if using a PathExist* will have changed. Of those the list [2] contains 9 to look at. I beg your pardon, but the list is vast due to including any "Type=oneshot" as well. And from the summary you gave I don't see why those are included as well. Looking at the first in the list that probably everyone has installed I see: a) /lib/systemd/system/alsa-restore.service there are no associated .path files, only ConditionPathExists in the unit itself - are those also affected? b) Looking slightly further /lib/systemd/system/apt-daily.service even has no associated .path nor any *Exist* statement. My question would now be - are those files of type (a) or (b) all also affected in some way or is the "critical list" actually much shorter? I was wondering if you could help to clarify before everyone that feels responsible for a package with a file in that list is diving into and re-understanding the case. Thanks in advance, Christian > An archive search[2] (thanks Seth!) was done of services which are > Type=oneshot or utilize a PathExists or PathExistsGlob. Briefly scanning > the list the following packages should probably be looked at: > > mandos-client > ostree > python-diskimage-builder > ubuntu-report > > [1] http://launchpad.net/bugs/1891657 > [2] https://paste.ubuntu.com/p/k5Gj7rQ9FX/ > > Cheers, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
