996056 - In some cases, Firefox detaches itself from its parent process on launch

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[André Reinald]

Attachment: Screen Shot 2014-04-14 at 18.35.07.png

On launch, Firefox behaves like a daemon: it forks-execs itself then terminates. The child process, left without parent, is reattached to the main launchd process (pid=1, uid=0).

It's the only Mac Application to do so, all others are childs of the user's launchd process. This has subtle side effects, like Firefox not appearing in the default "Energy" view in Activity Monitor.

Comment 1

[André Reinald]

Attachment: Screen Shot 2014-04-14 at 18.35.40.png

The 1st screenshot was taken in the default Energy view mode. Firefox does not appear there.
The 2nd screenshot shows Firefox in a different view mode.

Comment 2

[André Reinald]

Attachment: Screen Shot 2014-04-14 at 18.39.39.png

Screenshot shows processes hierarchically. Firefox's parent process is the root launchd. While it's user is, of course, me.

Comment 3

[André Reinald]

Attachment: Screen Shot 2014-04-14 at 18.42.34.png

Note that all other apps belong to the user's instance of launchd.

Comment 4

[André Reinald]

As far as I could investigate the issue, it seems related to setting the user's profile. As soon as it's set (either automatically or after prompting the user), the "bad things" happen (fork-exec-exit).

While I can understand the necessity of relaunching Firefox, there are specific APIs on Mac to do just that the right way (Launch Services). I believe the relevant fork-exec happens in uxprocess.c But before I do any further investigation or risk any changes, I'd appreciate some feedback on the issue.

PS: if I remember well some OS internals dealing with IPC, this Firefox peculiarity may cause some other strange behaviors, so it may be worth trying to mimic normal Mac Apps on this side too.

Comment 5

[André Reinald]

Josh, it seems you're the last to have touched LaunchChildMac() (maybe even written it?) so I'm asking for your advice on this issue.

Comment 6

[Josh Aas]

Steven Michaud is a good person to have look into this.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

When André and I talked on IRC yesterday, I told him I don't think the side-effects of Firefox's current behavior (as described above) are particularly damaging or important -- for example bug 931521.

But here's another possible side effect that's rather more important:

For some time (the last few years?) it's been impossible to run Firefox (or Thunderbird) from inside gdb (or lldb) on the Mac.  You can't do "gdb firefox-bin" and then "run" -- if you do that you crash.  Instead you have to launch Firefox first (either from the command line or by double-clicking on it), then attach to the Firefox process by doing "gdb firefox [firefoxpid]".

This hasn't been true for as long as Mac Firefox has had the "double launch".  But even the prior behavior was sub-optimal:  You could "run" Firefox from inside gdb.  But if it performed a double start, after that Firefox would be running outside of gdb.

I don't think either of these behaviors has ever been reported as a bug.  I live (or lived) with both on a daily basis,  but I've always thought of them as something I just had to put up with.  But properly speaking both are bugs -- or at least the current behavior is.

I'll look for a bug that covers the current behavior.  If I don't find one I'll open one myself and (tentatively) make it depend on this bug.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Actually the problem I described in comment #7 is completely unrelated -- it happens even without a Firefox relaunch.  So it can't possibly be fixed by changing how we relaunch Firefox.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #4)

> I believe the relevant fork-exec happens in uxprocess.c

Not so.  On the Mac it happens here, in LaunchChildMac(), which uses posix_spawnp():
https://hg.mozilla.org/mozilla-central/annotate/45ba19361b97/toolkit/xre/MacLaunchHelper.mm#l38

LaunchChildMac() is called from here:
https://hg.mozilla.org/mozilla-central/annotate/45ba19361b97/toolkit/xre/nsAppRunner.cpp#l1642

(Also, "uxprocess.c" should be "uxproces.c".)

> While I can understand the necessity of relaunching Firefox, there
> are specific APIs on Mac to do just that the right way (Launch
> Services).

Which ones?

Comment 10

[André Reinald]

(In reply to Steven Michaud from comment #8)
> Actually the problem I described in comment #7 is completely unrelated -- it
> happens even without a Firefox relaunch.  So it can't possibly be fixed by
> changing how we relaunch Firefox.

$ lldb NightlyDebug.app/Contents/MacOS/firefox

Works fine for me, no crash. But, as expected, the debugged process stops after the spawn (in my case I have the profile selector waiting for my click to proceed), and the spawned firefox doesn't run in lldb. Still all messages are output to the console, which can be misleading.

Using Launch Services instead of spawn will not solve that issue, but will ensure firefox remains a child process of the user's launchd, like all other Mac apps. One of the benefits will be, of course, to solve bug 931521.

Comment 11

[André Reinald]

(In reply to Steven Michaud from comment #9)
> (In reply to comment #4)
> > While I can understand the necessity of relaunching Firefox, there
> > are specific APIs on Mac to do just that the right way (Launch
> > Services).
> 
> Which ones?

OSStatus LSOpenApplication (
   const LSApplicationParameters *appParams,
   ProcessSerialNumber *outPSN
);

Comment 12

[André Reinald]

(In reply to Steven Michaud from comment #7)
> This hasn't been true for as long as Mac Firefox has had the "double
> launch".  But even the prior behavior was sub-optimal:  You could "run"
> Firefox from inside gdb.  But if it performed a double start, after that
> Firefox would be running outside of gdb.
> 
> I don't think either of these behaviors has ever been reported as a bug.  I
> live (or lived) with both on a daily basis,  but I've always thought of them
> as something I just had to put up with.  But properly speaking both are bugs
> -- or at least the current behavior is.
> 
> I'll look for a bug that covers the current behavior.  If I don't find one
> I'll open one myself and (tentatively) make it depend on this bug.

One way to avoid the double restart (and hence the detaching from the debugger) is to launch FF with -P, like this:

./NightlyDebug.app/Contents/MacOS/firefox -P <profile>

$ pstree -p 34254
-+= 00001 root /sbin/launchd
 \-+= 00142 andre /sbin/launchd
   \-+= 00154 andre /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_24582
     \-+= 00194 root login -pfl andre /bin/bash -c exec -la bash /bin/bash
       \-+= 00197 andre -bash
         \--= 34254 andre ./NightlyDebug.app/Contents/MacOS/firefox -P debuguser

Comment 13

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #10)

> $ lldb NightlyDebug.app/Contents/MacOS/firefox
>
> Works fine for me, no crash.

Apparently the crashes only happen with non-debug builds.  Which is bizarre since only non-debug m-c nightlies don't have their symbols stripped :-(

Definitely a bug, but not related to this one.

Comment 14

[André Reinald]

I think it would be best to completely avoid the "double launch" which would also fix this bug, but I think it would have more implications than I can think of, including on platforms I don't master.

What I plan to do here is keep the "double launch" but make sure the second FF is run closer to the conditions of other Mac applications, which for instance include being child of the user's launchd.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> I think it would be best to completely avoid the "double launch"

I don't think that's an option.  Digging around a few days ago looking
for its origins, I discovered that it's deeply embedded in the tree,
on all platforms, and would be very difficult to remove.

> What I plan to do here is keep the "double launch" but make sure the
> second FF is run closer to the conditions of other Mac applications,
> which for instance include being child of the user's launchd.

That's worth pursuing, but only if it doesn't break *anything* else.

Comment 16

[André Reinald]

(In reply to Steven Michaud from comment #15)
> > What I plan to do here is keep the "double launch" but make sure the
> > second FF is run closer to the conditions of other Mac applications,
> > which for instance include being child of the user's launchd.
> 
> That's worth pursuing, but only if it doesn't break *anything* else.

One thing I can think of is that it would detach output from the terminal after relaunch. If I remember well, output is redirected to the console log in this case (but that's old memories). And anyway, a normal user would not launch FF from the terminal in the first place.

For those interested in having the output in the terminal, using the -P option does the trick.

Comment 17

[André Reinald]

Attachment: bugzilla-996056-1.patch

WIP:
1. the good: as expected, this patch fixes the parent process issue, and all related anomalies.
2. the bad: visually in the Dock, things happen like on updates, a 2nd instance of FF appears, then the 1st instance disappears (or stops running). This is similar to what happens on updates.

Next step: solve n°2.

Comment 18

[André Reinald]

For now I implemented an ugly hack to avoid 2. above : launch a helper executable (currently a shell script) which will wait for the 1st FF to stop (a few seconds) before it launches it again with the -P option (using /usr/bin/open). The same dock icon is then used, and 1. is still ok.

Performance wise, this hack delays the whole launch by a few seconds, which I don't think is acceptable.

Comment 19

[André Reinald]

There is another visible and more annoying side effect of FF not being child of the user launchd : it's not restarted automatically when a user reopens his session. All other apps (including our own Thunderbird) are.

The only solution I can think of for now is find a way to avoid the double launch whenever it's possible, which I believe are the vast majority of cases, and use the above trick only when needed.

Comment 20

[André Reinald]

Investigation shows that this double launch only occurs when:
- the profile manager is displayed (so the user selects which profile to run),
- after an update.

In cases where the last profile is automatically used and there is no update (I don't have figures to evaluate how often that happens), FF is not re-launched.

Because the double launch only occurs in some cases and not others, and then the process hierarchy is messed up, the behavior from the user perspective will be inconsistent (see comment 19 and description).

Comment 21

[noitidart]

Related video demonstrating the detachment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1130806

Comment 22

[noitidart]

(In reply to André Reinald from comment #12)
> (In reply to Steven Michaud from comment #7)
> > This hasn't been true for as long as Mac Firefox has had the "double
> > launch".  But even the prior behavior was sub-optimal:  You could "run"
> > Firefox from inside gdb.  But if it performed a double start, after that
> > Firefox would be running outside of gdb.
> > 
> > I don't think either of these behaviors has ever been reported as a bug.  I
> > live (or lived) with both on a daily basis,  but I've always thought of them
> > as something I just had to put up with.  But properly speaking both are bugs
> > -- or at least the current behavior is.
> > 
> > I'll look for a bug that covers the current behavior.  If I don't find one
> > I'll open one myself and (tentatively) make it depend on this bug.
> 
> One way to avoid the double restart (and hence the detaching from the
> debugger) is to launch FF with -P, like this:
> 
> ./NightlyDebug.app/Contents/MacOS/firefox -P <profile>
> 
> $ pstree -p 34254
> -+= 00001 root /sbin/launchd
>  \-+= 00142 andre /sbin/launchd
>    \-+= 00154 andre
> /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_24582
>      \-+= 00194 root login -pfl andre /bin/bash -c exec -la bash /bin/bash
>        \-+= 00197 andre -bash
>          \--= 34254 andre ./NightlyDebug.app/Contents/MacOS/firefox -P
> debuguser

Ah this is why I am getting a second icon. Because the shortcuts I create (in my last comment linking to video) launch firefox with `-profile "path to profile" -no-remote` command line arguments. So it doesn't double restart. Anyway to make it do a double restart even if launched with these command line arguments? I can think of one way: ill observer restart and then set a pref value to 1, then on start if that pref value exists at 1 i delete that pref and restart again. Would that be ok?

Comment 23

[noitidart]

If you guys would like to make a firefox launcher into a profile, copy paste this snippet in this comment here: https://gist.github.com/Noitidart/bac41811fe797e1a0041#comment-1391048

That will then launch firefox into that specific profile. It works great, on restart of computer it launches back that same profile, etc etc. I just need to make it to the double restart.

Comment 24

[noitidart]

Hi Andre would you have time to chat on irc about my issue. I explained it here with a video: https://ask.mozilla.org/question/1445/osx-ensure-double-start-restart-even-with-profile-command-line-args/

I am creating shortcuts to different firefox profiles (for addon profilist) so i can set custom badged icons and so it restarts into the proper profile on computer restart, keeping in dock, etc. But my issue is, due to single start i am getting a duplicated dock icon.

Comment 25

[André Reinald]

I answered in the Ask Mozilla post. In short, don't rely on a double start!

Comment 26

[noitidart]

Thanks very much Andre! I'll check out ask.m.o now :)

Comment 27

[Stephen A Pohl [:spohl]]

Per bug 639707 comment 14, Apple changed the launchd architecture in macOS 10.11 and this bug no longer applies.