Hi Ross,
You're right, it's better to patch systemd to allow timeout override.
I'll send out a patch to systemd.
Best Regards,
Chen Qi
On 07/11/2018 06:38 PM, Burton, Ross wrote:
The problem is that when the system is loaded, systemctl calls may be
too slow and they will time out. This patch simply changes *one* of
the many systemctl calls to use busctl directly, leaving many other
calls as a potential failure point.
Surely a better solution would be to patch in a way to override the
timeout, so we can pass that in all calls.
Ross
On 11 July 2018 at 06:46, ChenQi <qi.c...@windriver.com> wrote:
ping
Is there some problem with this patch?
Recently when I'm doing testimage test for systemd upgrade, the 'systemctl
list-unit-files' command in this test case revealed a 'segment fault' error
on musl qemuarm.
So I'd suggest to keep 'systemctl list-unit-files' command and use 'busctl'
as a fallback in case of timeout.
Best Regards,
Chen Qi
On 07/04/2018 06:05 PM, ChenQi wrote:
ping
On 06/26/2018 09:48 AM, ChenQi wrote:
On 06/25/2018 09:40 PM, Burton, Ross wrote:
The busctl invocation will only rarely be called so is very prone to
bitrot, maybe it should just always use busctl?
Personally I think that there should be a way for VM time to be
independent of host time to avoid this sort of problem...
Ross
Hi Ross,
I now realize that I didn't include enough information in the commit
message.
In fact, for qemuarm, this problem always appeared.
Compared to other qemu bsps (e.g. qemux86-64), qemuarm is running much
slower.
I've now updated the commit the message to include this qemuarm info, and
also updated the remote branch.
git://git.pokylinux.org/poky-contrib ChenQi/systemd-bus-timeout
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/systemd-bus-timeout
If you think we should still use `busctl' directly, I can send out a new
patch. Either way is OK to me.
Best Regards,
Chen Qi
On 25 June 2018 at 10:33, Chen Qi <qi.c...@windriver.com> wrote:
I've encountered the following error when doing testimage.
RESULTS - systemd.SystemdBasicTests.test_systemd_list - Testcase
551: FAILED
After investigation, I found that it's not functionality issue. It's
just that the qemu was not running fast enough. And it resulted 'time
out'
problem when using `systemctl list-unit-files'.
The correctness could be verified by using 'busctl' directly.
e.g.
busctl --timeout=240 call org.freedesktop.systemd1 \
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager \
ListUnitFilesByPatterns asas 0 0
Checking the source codes, I can see that the timeout is 25s. I don't
think we should patch systemd's source codes just for such a simple
runtime test case.
So instead, I change the test case to use 'busctl' directly if
'systemctl list-unit-files' gets a timeout error.
Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
meta/lib/oeqa/runtime/cases/systemd.py | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/runtime/cases/systemd.py
b/meta/lib/oeqa/runtime/cases/systemd.py
index db69384..b4f1025 100644
--- a/meta/lib/oeqa/runtime/cases/systemd.py
+++ b/meta/lib/oeqa/runtime/cases/systemd.py
@@ -81,7 +81,19 @@ class SystemdBasicTests(SystemdTest):
@OETestID(551)
@OETestDepends(['systemd.SystemdBasicTests.test_systemd_basic'])
def test_systemd_list(self):
- self.systemctl('list-unit-files')
+ command = 'systemctl list-unit-files'
+ status, output = self.target.run(command)
+ message = '\n'.join([command, output])
+ match = re.search('Connection timed out', output)
+ if match:
+ # it's possible that qemu is running slow
+ # use busctl to check the results with timeout set to 240s
+ command = 'busctl --timeout=240 call
org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.systemd1.Manager ListUnitFilesByPatterns asas 0 0'
+ status, output = self.target.run(command)
+ message = '\n'.join([command, output])
+ self.assertEqual(status, 0, message)
+ else:
+ self.assertEqual(status, 0, message)
@OETestID(550)
@OETestDepends(['systemd.SystemdBasicTests.test_systemd_basic'])
--
1.9.1
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
