Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Redundant systemd instance makes WAM and homescreen crash

Description

[update: see comment #comment-20920]

When I start a halibut/master image with agl-html5-framework, I can see the homescreen crash after some seconds.

I can see two crashes:

{{$ coredumpctl }}
TIME PID UID GID SIG COREFILE EXE
Sat 2019-06-29 08:29:46 UTC 1120 0 0 5 present /usr/bin/WebAppMgr
Sat 2019-06-29 08:30:22 UTC 1280 0 0 6 present /var/local/lib/afm/applications/homescreen/0.1/bin/HomeScreen

This is the sequence of events in the log:

Jun 29 08:29:46 intel-corei7-64 systemd-coredump[1187]: Process 1120 (WebAppMgr) of user 0 dumped core.
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: WebAppMgr.service: Service RestartSec=50s expired, scheduling restart.
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: WebAppMgr.service: Scheduled restart job, restart counter is at 1.
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: Stopped "WebAppMgr is responsible for running web apps and manage their lifecycle".
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: Started "WebAppMgr is responsible for running web apps and manage their lifecycle".
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[int main(int, const char**)] ### Starting /usr/bin/WebAppMgr
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[virtual int WebRuntimeAGL::run(int, const char**)] WebRuntimeAGL::run
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[virtual int WebRuntimeAGL::run(int, const char**)] WebRuntimeAGL - creating SharedBrowserProcessRuntime
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[int WamSocketLockFile::openLockFile()] Failed to open lock file descriptor
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[bool WamSocketLockFile::createAndLock()] Failed to lock file -1
Jun 29 08:30:18 intel-corei7-64 WebAppMgr[1408]: ## (DEBUG)[virtual int SharedBrowserProcessRuntime::run(int, const char**)] Trying to start shared browser process but process is already running
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: WebAppMgr.service: Main process exited, code=exited, status=255/n/a
Jun 29 08:30:18 intel-corei7-64 systemd[1119]: WebAppMgr.service: Failed with result 'exit-code'.
Jun 29 08:30:22 intel-corei7-64 systemd-coredump[1363]: Process 1280 (HomeScreen) of user 0 dumped core.

Reproduced in Minnowboard, but likely to affect other platforms

Environment

None

Activity

Walt Miner 
July 30, 2019 at 9:38 PM

Close for HH 8.0.0 release

Jacobo Aragunde Pérez 
July 29, 2019 at 9:15 PM

Jacobo Aragunde Pérez 
July 26, 2019 at 10:57 AM

Thanks for your help! Let me report the issues you mentioned as new tickets.

Stephane Desneux 
July 25, 2019 at 5:28 PM

I also sent a PR to add permissions in all demo apps: https://github.com/jaragunde/wam-demo-applications/pull/1

This is needed to obtain runtime permissions for display and audio.

Also note that currently, the youtube app starts but we hit some security issues related to pipewire. I assume this is expected given the current state of AGL.

Stephane Desneux 
July 25, 2019 at 4:51 PM

I pushed the review #21977 that changes the way WebAppMgr service is started.

With this change, I can run the webapp 'falling-block' correctly (after adding the required permissions in config.xml - see commit msg in #21977).

While investigating on how WAM is started, we saw some issues with the wam socket used to communicate between instances:

  1. the socket 'wamsocket' is created in /tmp but there may be multiple WAM instances (one for each user). So there will be a conflict. Path should be changed to /run/user/$UID/wamsocket for example

  2. when creating the socket, the main WAM service also creates a wamsocket.lock file. That's ok. But when we start a webapp, the UI is launched with /usr/bin/web-runtime, which is a client instance of WebAppMgr. For whatever reason, this client instance probably tries to create the socket too but this is not possible due to smack labels => we get a security audit message in the log and an error from client WAM complaining about the wamsocket.lock that can't be created. We think there's some logic issue here and this deserves some deeper investigation.

IMO, the 2 issues above deserve separate tickets for resolution. Opinions?

Fixed

Details

Assignee

Reporter

Fix versions

Labels

Contract ID

Affects versions

Priority

Created June 29, 2019 at 10:04 AM
Updated September 19, 2019 at 12:07 PM
Resolved July 29, 2019 at 9:15 PM

Flag notifications