| Message ID | 20230630091451.3331563-2-changqing.li@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [master,1/2] dnf: only write the log lock to root for native dnf | expand |
On Fri, 30 Jun 2023 at 11:14, Changqing Li <changqing.li@eng.windriver.com> wrote: > Remove log_lock.pid which maybe created during do_rootfs. In commit > [dnf: only write the log lock to root for native dnf], > native dnf changed to write log lock to root, and target dnf still > use /var/log, so log_lock.pid need to be removed post do_rootfs. This is not making clear why the file needs to be removed. What problems occur if it is left in place? Is it supposed to be added, then removed by dnf during do_rootfs, and if this doesn't happen, is that a problem with dnf that needs to be fixed, rather than removing the file manually after the fact? Alex
On 30 Jun 2023, at 16:07, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > > On Fri, 30 Jun 2023 at 11:14, Changqing Li > <changqing.li@eng.windriver.com> wrote: >> Remove log_lock.pid which maybe created during do_rootfs. In commit >> [dnf: only write the log lock to root for native dnf], >> native dnf changed to write log lock to root, and target dnf still >> use /var/log, so log_lock.pid need to be removed post do_rootfs. > > This is not making clear why the file needs to be removed. What > problems occur if it is left in place? Is it supposed to be added, > then removed by dnf during do_rootfs, and if this doesn't happen, is > that a problem with dnf that needs to be fixed, rather than removing > the file manually after the fact? Absolutely. If the dnf image creation is leaving lock files then we fix the dnf image creation. Does dnf leave a daemon hanging around? Does it leave lock files when it shouldn’t? Either way, this should be in dnf or the image creation code itself, not a generic rootfs postcommand. Ross
On 7/4/23 19:11, Ross Burton wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On 30 Jun 2023, at 16:07, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: >> On Fri, 30 Jun 2023 at 11:14, Changqing Li >> <changqing.li@eng.windriver.com> wrote: >>> Remove log_lock.pid which maybe created during do_rootfs. In commit >>> [dnf: only write the log lock to root for native dnf], >>> native dnf changed to write log lock to root, and target dnf still >>> use /var/log, so log_lock.pid need to be removed post do_rootfs. >> This is not making clear why the file needs to be removed. What >> problems occur if it is left in place? Is it supposed to be added, >> then removed by dnf during do_rootfs, and if this doesn't happen, is >> that a problem with dnf that needs to be fixed, rather than removing >> the file manually after the fact? > Absolutely. If the dnf image creation is leaving lock files then we fix the dnf image creation. Does dnf leave a daemon hanging around? Does it leave lock files when it shouldn’t? Either way, this should be in dnf or the image creation code itself, not a generic rootfs postcommand. Alex and Ross, There is no dnf daemon hanging around, you are right, seems like an dnf bug, I will report this to dnf upstream. And there is no functional problem if this file is not removed, only it may confuse user there is an useless file that is generated during do_rootfs, it should not exit in rootfs. //Changqing > > Ross > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#183827): https://lists.openembedded.org/g/openembedded-core/message/183827 > Mute This Topic: https://lists.openembedded.org/mt/99869451/3616873 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [changqing.li@eng.windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- >
This merged to master and it should not have happened. I'm sending a revert. Alex On Tue, 11 Jul 2023 at 10:34, Changqing Li <changqing.li@eng.windriver.com> wrote: > > > On 7/4/23 19:11, Ross Burton wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > On 30 Jun 2023, at 16:07, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > >> On Fri, 30 Jun 2023 at 11:14, Changqing Li > >> <changqing.li@eng.windriver.com> wrote: > >>> Remove log_lock.pid which maybe created during do_rootfs. In commit > >>> [dnf: only write the log lock to root for native dnf], > >>> native dnf changed to write log lock to root, and target dnf still > >>> use /var/log, so log_lock.pid need to be removed post do_rootfs. > >> This is not making clear why the file needs to be removed. What > >> problems occur if it is left in place? Is it supposed to be added, > >> then removed by dnf during do_rootfs, and if this doesn't happen, is > >> that a problem with dnf that needs to be fixed, rather than removing > >> the file manually after the fact? > > Absolutely. If the dnf image creation is leaving lock files then we fix the dnf image creation. Does dnf leave a daemon hanging around? Does it leave lock files when it shouldn’t? Either way, this should be in dnf or the image creation code itself, not a generic rootfs postcommand. > > Alex and Ross, There is no dnf daemon hanging around, you are right, > seems like an dnf bug, I will report this to dnf upstream. > > And there is no functional problem if this file is not removed, only it > may confuse user there is an useless file that is generated during > do_rootfs, it should not exit in rootfs. > > > //Changqing > > > > > Ross > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#184123): https://lists.openembedded.org/g/openembedded-core/message/184123 > Mute This Topic: https://lists.openembedded.org/mt/99869451/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 7/18/23 04:22, Alexander Kanavin wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > This merged to master and it should not have happened. I'm sending a revert. > > Alex Hi, Alex I know that following patch already reverted. https://git.openembedded.org/openembedded-core/commit/?id=49bad18012a4079f0dbfe6c541a46ec508940f28 But after review it again, I think maybe it is still needed. dnf works like this, it will create log file /var/log/log_lock.pid, and this lock file is designed to by removed after reboot, refer following link. https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf But following patch for fixing oe specific issue break above dnf design about removing lock file. https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66 So I add this patch https://git.openembedded.org/openembedded-core/commit/?id=406a72a9a47c2735b7e18cefc682b1df00d5a9aa to remove the lock file in rootfs. Since for dnf-native, it will not have reboot process, so it is better to remove it at post process of rootfs, to make an clean rootfs. Regards //Changqing > > > On Tue, 11 Jul 2023 at 10:34, Changqing Li > <changqing.li@eng.windriver.com> wrote: >> >> On 7/4/23 19:11, Ross Burton wrote: >>> CAUTION: This email comes from a non Wind River email account! >>> Do not click links or open attachments unless you recognize the sender and know the content is safe. >>> >>> On 30 Jun 2023, at 16:07, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: >>>> On Fri, 30 Jun 2023 at 11:14, Changqing Li >>>> <changqing.li@eng.windriver.com> wrote: >>>>> Remove log_lock.pid which maybe created during do_rootfs. In commit >>>>> [dnf: only write the log lock to root for native dnf], >>>>> native dnf changed to write log lock to root, and target dnf still >>>>> use /var/log, so log_lock.pid need to be removed post do_rootfs. >>>> This is not making clear why the file needs to be removed. What >>>> problems occur if it is left in place? Is it supposed to be added, >>>> then removed by dnf during do_rootfs, and if this doesn't happen, is >>>> that a problem with dnf that needs to be fixed, rather than removing >>>> the file manually after the fact? >>> Absolutely. If the dnf image creation is leaving lock files then we fix the dnf image creation. Does dnf leave a daemon hanging around? Does it leave lock files when it shouldn’t? Either way, this should be in dnf or the image creation code itself, not a generic rootfs postcommand. >> Alex and Ross, There is no dnf daemon hanging around, you are right, >> seems like an dnf bug, I will report this to dnf upstream. >> >> And there is no functional problem if this file is not removed, only it >> may confuse user there is an useless file that is generated during >> do_rootfs, it should not exit in rootfs. >> >> >> //Changqing >> >>> Ross >>> >>> >>> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#184123): https://lists.openembedded.org/g/openembedded-core/message/184123 >> Mute This Topic: https://lists.openembedded.org/mt/99869451/1686489 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Tue, 5 Dec 2023 at 06:46, Changqing Li <changqing.li@eng.windriver.com> wrote: > So I add this patch > https://git.openembedded.org/openembedded-core/commit/?id=406a72a9a47c2735b7e18cefc682b1df00d5a9aa > to remove the lock file in rootfs. > > Since for dnf-native, it will not have reboot process, so it is better > to remove it at post process of rootfs, to make an clean rootfs. The review comments that led to the revert are still valid, and this message does not address them. The concern was that the removal via rootfs postprocess is too late. If dnf leaves lock files around, they should be removed just after the dnf execution. Alex
On 12/5/23 17:55, Alexander Kanavin wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Tue, 5 Dec 2023 at 06:46, Changqing Li > <changqing.li@eng.windriver.com> wrote: > >> So I add this patch >> https://git.openembedded.org/openembedded-core/commit/?id=406a72a9a47c2735b7e18cefc682b1df00d5a9aa >> to remove the lock file in rootfs. >> >> Since for dnf-native, it will not have reboot process, so it is better >> to remove it at post process of rootfs, to make an clean rootfs. > The review comments that led to the revert are still valid, and this > message does not address them. The concern was that the removal via > rootfs postprocess is too late. If dnf leaves lock files around, they > should be removed just after the dnf execution. Hi, Alex Thanks. Agree that the lock file should be removed after dnf execution. This is a bug of dnf. I had raise a bug upstream in Jul: https://github.com/rpm-software-management/dnf/issues/1963. This patch more like an workaround before dnf fix this issue, and this log_lock.pid in rootfs has no function impact, just a dirty file in rootfs. Regards Sandy > Alex
On Wed, 6 Dec 2023 at 03:39, Changqing Li <changqing.li@eng.windriver.com> wrote: > The review comments that led to the revert are still valid, and this > message does not address them. The concern was that the removal via > rootfs postprocess is too late. If dnf leaves lock files around, they > should be removed just after the dnf execution. > Thanks. Agree that the lock file should be removed after dnf execution. This is a bug of dnf. I had raise a bug upstream in Jul: > > https://github.com/rpm-software-management/dnf/issues/1963. Looks like it's not something upstream is going to fix quickly - low priority, no comments. > This patch more like an workaround before dnf fix this issue, and this log_lock.pid in rootfs > > has no function impact, just a dirty file in rootfs. If you can rework the patch so that the stale files are removed immediately after running dnf, I think no one is going to object. The location is somewhere in meta/lib/oe/package_manager/rpm/. Alex
diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass b/meta/classes-recipe/rootfs-postcommands.bbclass index 4492c9c0aa..53b241413e 100644 --- a/meta/classes-recipe/rootfs-postcommands.bbclass +++ b/meta/classes-recipe/rootfs-postcommands.bbclass @@ -49,6 +49,8 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;' ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", "overlayfs", "overlayfs_qa_check; overlayfs_postprocess;", "", d)}' +ROOTFS_POSTPROCESS_COMMAND += 'remove_unused_dnf_log_lock;' + inherit image-artifact-names # Sort the user and group entries in /etc by ID in order to make the content @@ -361,6 +363,11 @@ empty_var_volatile () { fi } +remove_unused_dnf_log_lock() { + if [ -e ${IMAGE_ROOTFS}/log_lock.pid ]; then + rm -rf ${IMAGE_ROOTFS}/log_lock.pid + fi +} # Turn any symbolic /sbin/init link into a file remove_init_link () { if [ -h ${IMAGE_ROOTFS}/sbin/init ]; then