[mickledore,2/2] rootfs-postcommands.bbclass: add post func remove_unused_dnf_log_lock

From: Changqing Li <changqing.li@windriver.com>

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.

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
 meta/classes-recipe/rootfs-postcommands.bbclass | 7 +++++++
 1 file changed, 7 insertions(+)

Is this also a problem in master, or is it mickledore specific?

Steve

On Thu, Jun 29, 2023 at 10:32 PM Changqing Li
<changqing.li@eng.windriver.com> wrote:
>
> From: Changqing Li <changqing.li@windriver.com>
>
> 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.
>
> Signed-off-by: Changqing Li <changqing.li@windriver.com>
> ---
>  meta/classes-recipe/rootfs-postcommands.bbclass | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass b/meta/classes-recipe/rootfs-postcommands.bbclass
> index 690fa976aa..7538c8b0b5 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
> @@ -276,6 +278,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
> --
> 2.35.5
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#183686): https://lists.openembedded.org/g/openembedded-core/message/183686
> Mute This Topic: https://lists.openembedded.org/mt/99869175/3620601
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Fri, 2023-06-30 at 04:21 -1000, Steve Sakoman wrote:
> Is this also a problem in master, or is it mickledore specific?

The same patches have been proposed for master with an "instant"
backport requested. I really don't like this model of development as I
have my doubts about how extensively they've been tested in one or the
other.

I'm also not convinced the patches explain the issue properly or why
things should be fixed as proposed. I think at the very least the
commit messages need to better explain the issues.

Cheers,

Richard

On Fri, Jun 30, 2023 at 4:57 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Fri, 2023-06-30 at 04:21 -1000, Steve Sakoman wrote:
> > Is this also a problem in master, or is it mickledore specific?
>
> The same patches have been proposed for master with an "instant"
> backport requested. I really don't like this model of development as I
> have my doubts about how extensively they've been tested in one or the
> other.

I typically don't do "instant" backports.  If a patch is proposed for
both master and a stable branch I wait till it is accepted into
master. Then I give it a week or two before backporting to see if any
issues develop in master -- if I remember in the midst of all the
other patch wrangling for multiple stable branches!

I much prefer that people submit to master first, then when it is
accepted send a backport patch for the appropriate stable branches.
Sending all the branches at once just increases the risk that the
backports get forgotten!

Steve


> I'm also not convinced the patches explain the issue properly or why
> things should be fixed as proposed. I think at the very least the
> commit messages need to better explain the issues.
>
> Cheers,
>
> Richard