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...@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....@lists.openembedded.org> wrote:
On Fri, 30 Jun 2023 at 11:14, Changqing Li
<changqing...@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 (#191793): 
https://lists.openembedded.org/g/openembedded-core/message/191793
Mute This Topic: https://lists.openembedded.org/mt/99869451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to