| 2018-10-02 23:13:01 |
Joshua R. Poulson |
bug |
|
|
added bug |
| 2018-10-02 23:13:11 |
Joshua R. Poulson |
systemd (Ubuntu): status |
New |
Confirmed |
|
| 2018-10-04 03:10:39 |
Eric Desrochers |
tags |
|
sts |
|
| 2018-10-04 03:10:45 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-10-04 03:10:45 |
Eric Desrochers |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2018-10-04 03:10:57 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2018-10-04 03:12:37 |
Eric Desrochers |
systemd (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2018-10-04 03:14:35 |
Eric Desrochers |
description |
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04. |
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
[Other Informations]
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic |
|
| 2018-10-04 03:14:39 |
Eric Desrochers |
systemd (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2018-10-04 03:16:12 |
Eric Desrochers |
systemd (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2018-10-04 03:30:29 |
Eric Desrochers |
bug |
|
|
added subscriber David Coronel |
| 2018-11-30 13:07:12 |
Eric Desrochers |
description |
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
[Other Informations]
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic |
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
[Other Informations]
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic |
|
| 2018-12-11 22:24:48 |
Eric Desrochers |
attachment added |
|
systemd-lp1795764-xenial.debdiff https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795764/+attachment/5221471/+files/systemd-lp1795764-xenial.debdiff |
|
| 2018-12-11 23:16:52 |
Eric Desrochers |
description |
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
[Other Informations]
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-11 23:17:56 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-11 23:17:59 |
Eric Desrochers |
systemd (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2018-12-11 23:18:02 |
Eric Desrochers |
systemd (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-12-11 23:18:59 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-11 23:19:47 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-11 23:22:04 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
65d36b495
03b8cfede
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 01:51:20 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest-abc.mount loaded inactive dead /root/bind-test/abc
root-bind\x2dtest.mount loaded active mounted /root/bind-test
Expected outcome (w/ the fix) :
# cd /root
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
root-bind\x2dtest.mount loaded active mounted /root/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 13:32:39 |
Łukasz Zemczak |
systemd (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-12-13 13:32:40 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-12-13 13:32:41 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-12-13 13:32:45 |
Łukasz Zemczak |
tags |
sts |
sts verification-needed verification-needed-xenial |
|
| 2018-12-13 16:51:00 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
ERROR
ERROR
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 16:52:10 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
ERROR
ERROR
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
ERROR
ERROR
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 16:52:45 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
ERROR
ERROR
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 16:54:20 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 17:01:54 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 17:13:21 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 17:15:10 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-13 17:16:43 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 00:15:16 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for umockdev (i386): test log
*
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No ADT test has been reported since 21.5 ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 00:16:46 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No ADT test has been reported since 21.5 ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No ADT test has been reported since 21.5 ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some ADT report elsewhere, the only data available I have is if the ADT tests were "failling" or "passing" on 21.5.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 00:21:15 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No ADT test has been reported since 21.5 ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some ADT report elsewhere, the only data available I have is if the ADT tests were "failling" or "passing" on 21.5.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 00:32:15 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:27:19 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:31:46 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:40:48 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/proposed2.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:41:48 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/proposed2.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:51:10 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but it is really worth it to retry them until success if it works fine outside the Ubuntu infra ? That seems counterproductive IMHO.
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:52:37 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but it is really worth it to retry them until success if it works fine outside the Ubuntu infra ? That seems counterproductive IMHO.
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ?
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 15:56:41 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ?
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ? (See attachment: autopkgtest_result.txt for the whole ADT log)
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-17 16:00:01 |
Eric Desrochers |
attachment added |
|
autopkgtest_result.txt https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795764/+attachment/5223032/+files/autopkgtest_result.txt |
|
| 2018-12-17 16:10:57 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Unless security team has some autopkgtests reports elsewhere, the only data available I have (to compare) is if the autopkgtests were "failling" or "passing" when 21.5 has been pushed. Since then quite a few release has been uploaded with no autopkgtests report.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ? (See attachment: autopkgtest_result.txt for the whole ADT log)
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ? (See attachment: autopkgtest_result.txt for the whole ADT log)
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2018-12-19 13:29:57 |
Eric Desrochers |
description |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ? (See attachment: autopkgtest_result.txt for the whole ADT log)
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
[Impact]
kubernetes loaded inactive dead transient mount points grows
https://github.com/kubernetes/kubernetes/issues/57345
[Test Case]
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
Expected outcome (w/ the fix) :
# cd /tmp
# mkdir -p bind-test/abc
# mount --bind bind-test bind-test
# mount -t tmpfs tmpfs bind-test/abc
# umount bind-test/abc
# systemctl list-units --all | grep bind-test
tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test
[Regression Potential]
This is a adapted version of 2 upstream fixes as the original upstream commit has been made on top on 2 functions mount_setup_new_unit() & mount_setup_existing_unit() that not yet exist systemd 229. It is easily adaptable because the current function mount_setup_unit() is dealing with both of at the moment instead of being individually separate in two distinct function.
It is an adaptation of commits :
[65d36b495] core: Fix edge case when processing /proc/self/mountinfo
[03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()
This patch changes mount_setup_unit() to prevent the just_mounted mount setup flag from being overwritten if it is set to true. This will allow all mount units created from /proc/self/mountinfo entries to be initialised properly.
Additionally, the patch got the blessing of 'xnox' who looked at it and mention it looks fine to him.
[Pending SRU]
Note: No autopkgtests has been reported since systemd (21.5) ... between 21.5 and now (21.11) everything released has been about security fixes :
systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
systemd (229-4ubuntu21.10) xenial-security; urgency=medium
systemd (229-4ubuntu21.9) xenial-security; urgency=medium
systemd (229-4ubuntu21.8) xenial-security; urgency=medium
systemd (229-4ubuntu21.6) xenial-security; urgency=medium
systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU
Note: I don't know the level of adoption of Netplan in Xenial, but I suspect it is low as Netplan replaced ifupdown as the default configuration utility starting with Ubuntu 17.10 Artful only AFAIK.
* Regression in autopkgtest for nplan (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz
Error:
modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
I don't think having wifi module is relevant in s390x anyway, so most likely the module is not there on purpose for kernel w/ s390x architecture.
* Regression in autopkgtest for nplan (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz
Error: (Ran on autopkgtest Ubuntu infra)
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_bridge_priority (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL
Justification:
The test are "passing" if ran manually in my own HW :
autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
.....
Setting up systemd (229-4ubuntu21.11) ...
Setting up nplan (0.32~16.04.6) ...
Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
....
test_dhcp6 (__main__.TestNetworkManager) ... ok
test_bridge_priority (__main__.TestNetworkManager) ... ok
test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok
I *think* that these test may eventually works, but is it really worth it to retry them until success if it works fine outside the Ubuntu infra w/ the same proposed packages ? (See attachment: autopkgtest_result.txt for the whole ADT log)
* Regression in autopkgtest for nplan (armhf): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz
Error:
Traceback (most recent call last):
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
command()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
r = f(c, ce)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
caller.hook_wait_reboot()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
wait_booted()
File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
stdout=stdout, stderr=subprocess.PIPE)
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
(out, err) = sp.communicate(instr)
File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
stderr = self.stderr.read()
File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
raise Timeout()
VirtSubproc.Timeout
Justification:
It is a recurrent failure since "systemd/229-4ubuntu21.3".
Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
Since then quite a few SRU has been approved so I'm not too worry here.
* Regression in autopkgtest for systemd (s390x): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz
Error:
FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
* Regression in autopkgtest for snapd (i386): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz
Error:
2018-12-13 21:28:16 Failed tasks: 1
- autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
error: unsuccessful run
Justification:
This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.
*
*
[Other Info]
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345
systemd v237 has this fix, but we'd like to have it fixed in 16.04.
It only affect systemd for Xenial, later release already has the fix:
$ git describe --contains 65d36b495
v237~140
==> systemd | 229-4ubuntu21.4 | xenial-updates
systemd | 237-3ubuntu10.3 | bionic-updates
systemd | 239-7ubuntu9 | cosmic
[Original Description]
From the PR:
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
One line fix in https://github.com/systemd/systemd/pull/7811/files
Referenced issue: https://github.com/systemd/systemd/issues/7798
Related kubernetes issue: https://github.com/kubernetes/kubernetes/issues/57345 |
|
| 2019-01-14 18:41:30 |
Eric Desrochers |
cve linked |
|
2018-16864 |
|
| 2019-01-14 18:41:30 |
Eric Desrochers |
cve linked |
|
2018-16865 |
|
| 2019-01-14 18:41:30 |
Eric Desrochers |
cve linked |
|
2018-16866 |
|
| 2019-01-14 18:41:30 |
Eric Desrochers |
cve linked |
|
2018-6954 |
|
| 2019-01-14 18:41:39 |
Eric Desrochers |
systemd (Ubuntu Xenial): status |
Fix Committed |
In Progress |
|
| 2019-02-19 15:12:21 |
Eric Desrochers |
systemd (Ubuntu Xenial): assignee |
Eric Desrochers (slashd) |
Dimitri John Ledkov (xnox) |
|
| 2019-02-28 17:10:46 |
Eric Desrochers |
systemd (Ubuntu Xenial): assignee |
Dimitri John Ledkov (xnox) |
Eric Desrochers (slashd) |
|
| 2019-03-02 00:39:25 |
Steve Langasek |
systemd (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-03-04 00:12:28 |
Eric Desrochers |
tags |
sts verification-needed verification-needed-xenial |
sts verification-done-xenial verification-needed |
|
| 2019-03-04 00:12:35 |
Eric Desrochers |
tags |
sts verification-done-xenial verification-needed |
sts verification-done verification-done-xenial |
|
| 2019-03-10 02:53:01 |
Mathew Hodson |
systemd (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-03-11 18:40:23 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-03-11 18:40:27 |
Launchpad Janitor |
systemd (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
