New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 699777 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

session_manager leaves signals blocked when spawning Chrome

Project Member Reported by jamescook@chromium.org, Mar 8 2017

Issue description

Platform 9346.0, chrome 59.0.3036.0

While debugging  issue 699143  (a problem with sign out on chrome --mash) I noticed that the chrome process starts up with a signal handler mask installed. (See man 2 sigprocmask). In particular the mask was blocking SIGTERM.

Child processes inherit this signal mask from their parents. Chrome must be inheriting it from session_manager. It seems like a bug that session_manager launches processes with a signal blocked.

This normally doesn't cause problems for chrome because ContentMainRunnerImpl::Initialize() calls a function SetupSignalHandlers() that happens to wipe the mask. However, chrome --mash doesn't use content, so we were not resetting the mask.

It's not obvious where the signal mask is coming from. session_manager spawns children in child_job.cc ForkAndExec but there's nothing there about blocking signals:

https://cs.corp.google.com/chromeos_public/src/platform2/login_manager/child_job.cc?type=cs

 
For the record the blocked signals are SIGHUP, SIGINT and SIGTERM.

JAMES MashMain sig 1 blocked 1
JAMES MashMain sig 2 blocked 1
JAMES MashMain sig 3 blocked 0
JAMES MashMain sig 4 blocked 0
JAMES MashMain sig 5 blocked 0
JAMES MashMain sig 6 blocked 0
JAMES MashMain sig 7 blocked 0
JAMES MashMain sig 8 blocked 0
JAMES MashMain sig 9 blocked 0
JAMES MashMain sig 10 blocked 0
JAMES MashMain sig 11 blocked 0
JAMES MashMain sig 12 blocked 0
JAMES MashMain sig 13 blocked 0
JAMES MashMain sig 14 blocked 0
JAMES MashMain sig 15 blocked 1

Comment 2 by derat@chromium.org, Mar 8 2017

Owner: derat@chromium.org
Status: Assigned (was: Untriaged)
Hmm. Those are quite suspiciously the same signals that session_manager_service.cc installs handlers for:

const int kSignals[] = {SIGTERM, SIGINT, SIGHUP};

I think I see the problem. SessionManagerService::SetUpHandlers() calls sigaction() to set SIGUSR1 and SIGALRM to SIG_IGN, but it also uses libbrillo's AsynchronousSignalHandler to install handlers for SIGTERM, SIGINT, and SIGHUP.

ChildJobInterface::Subprocess::ForkAndExec() calls SessionManagerService::RevertHandlers() before execve() in the forked process, but RevertHandlers() is a static method -- it sets SIGUSR1 and SIGALRM back to SIG_DFL, but it doesn't destroy the AsynchronousSignalHandler, so the other three signals still have handlers.

I think that ChildJobInterface either needs to destroy AsynchronousSignalHandler or manually clear the handlers.
Project Member

Comment 3 by bugdroid1@chromium.org, Mar 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/043b638699e0d9854aa53dfc0eeac1f8b7be16b4

commit 043b638699e0d9854aa53dfc0eeac1f8b7be16b4
Author: jamescook <jamescook@chromium.org>
Date: Thu Mar 09 00:11:28 2017

chromeos/mash: Reset signal handler mask on chrome --mash startup

This fixes an issue where the system tray "sign out" item does not cleanly
sign out of the session.

chrome inherits its signal handler masks from the parent process. These
masks are not guaranteed to be in any particular state, so they need to be
cleared on startup. Otherwise the SIGTERM signal is blocked, so the signal
handler doesn't run, so session_manager cannot cleanly shut down chrome.

For non-mash chrome this is done as part of content main initialization,
but mash chrome doesn't run that code.

BUG= 699143 , 699777 
TEST=System tray > Sign out takes you back to login screen promptly.
Also, "stop ui" on device, look at /var/log/messages, see signal 15 being
sent and chrome immediately exiting (and no signal 6 sent to kill it).

Review-Url: https://codereview.chromium.org/2731283008
Cr-Commit-Position: refs/heads/master@{#455603}

[modify] https://crrev.com/043b638699e0d9854aa53dfc0eeac1f8b7be16b4/chrome/app/mash/mash_runner.cc

Comment 4 by derat@chromium.org, Apr 10 2017

Components: OS>Systems
Labels: Hotlist-GoodFirstBug
Status: Available (was: Assigned)
Summary: session_manager leaves signals blocked when spawning Chrome (was: chromeos: session_manager leaves signals blocked when spawning chrome)
This would be a good bug for someone wanting to get some familiarity with the session_manager code (which I've inherited). #2 describes what seems to be going on; the fix is likely to be pretty small.

Comment 5 by sjg@chromium.org, Apr 14 2017

Owner: jclinton@chromium.org
Status: Started (was: Available)
Starting on this early next week.
Cc: jln@chromium.org
 Issue 493161  has been merged into this issue.
Project Member

Comment 9 by bugdroid1@chromium.org, Apr 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/d8494036ddaa76cb3149529db2cd8144593dd4f5

commit d8494036ddaa76cb3149529db2cd8144593dd4f5
Author: Jason D. Clinton <jclinton@chromium.org>
Date: Sat Apr 22 04:57:51 2017

login: Clear session_manager signal handlers and masks after child fork

See linked bug: processes spawned by session_manager have their handlers
set to the state of session_manager at the time of fork() which includes
some handlers that have been installed by Brillo. This sets everything
to POSIX safe defaults.

BUG= chromium:699777 
TEST=Build and deploy image to Peppy, sent masked signals to child
processes of session_manager, no signals were blocked.

Change-Id: I27aff4b6928a61897ee56285788378c3436dd531
Reviewed-on: https://chromium-review.googlesource.com/479466
Commit-Ready: Jason Clinton <jclinton@chromium.org>
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/d8494036ddaa76cb3149529db2cd8144593dd4f5/login_manager/child_job.cc
[modify] https://crrev.com/d8494036ddaa76cb3149529db2cd8144593dd4f5/login_manager/session_manager_service.cc
[modify] https://crrev.com/d8494036ddaa76cb3149529db2cd8144593dd4f5/login_manager/session_manager_service.h

Status: Fixed (was: Started)

Comment 11 by dchan@google.com, May 30 2017

Labels: VerifyIn-60

Comment 12 by sjg@google.com, Jul 5 2017

Labels: Team-BLD
Labels: VerifyIn-61

Comment 14 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment