$ firefox & [2] 24794 $ top $ ps PID TT STAT TIME COMMAND 16819 p1 Z 0:00.00 (firefox) 61237 p1 Z 0:00.00 (firefox) 32024 p1 Ssp 0:00.01 ksh 8876 p1 I 0:00.19 firefox 24794 p1 S 0:04.79 firefox 373 p1 R+p/0 0:00.00 ps $ kill -9 16819 $ ps PID TT STAT TIME COMMAND 61237 p1 Z 0:00.00 (firefox) 32024 p1 Ssp 0:00.01 ksh 24794 p1 I 0:04.79 firefox 28606 p1 R+p/1 0:00.00 ps [1] - Done firefox $ kill -9 61237 $ ps PID TT STAT TIME COMMAND 61237 p1 Z 0:00.00 (firefox) 32024 p1 Ssp 0:00.01 ksh 24794 p1 I 0:04.79 firefox 91733 p1 R+p/1 0:00.00 ps $ kill -9 61237 ksh: kill: 61237: No such process $ ps PID TT STAT TIME COMMAND 32024 p1 Ssp 0:00.01 ksh 24794 p1 D 0:06.13 firefox 17741 p1 S 0:00.00 dbus-launch --autolaunch=d3a4785d28139dbad41abb225a91d3af --binary-syntax --close-stderr 46916 p1 R+p/0 0:00.00 ps
On Sun, Apr 15, 2018 at 10:58 PM, Z Ero <zerotetrat...@gmail.com> wrote: > 6.2 AMD64, firefox 58. > > If firefox crashes (which happens rarely) sometimes I find it does not > start back up again. It seems to become a zombie or something. It > starts then goes directly to suspend. Why? Any work around known? > > I suspect it has something to do with dbus waiting for something or > firefox waiting for something from dbus. > > I have found killing my multiple attempts at starting firefox > eventually produces a dialogue window saying "firefox is already > running but not responding." Well... Then when I kill the process that > started the dialogue window it firefox finally starts. > > But this behaviour is strange and the solution would not be intuitive > to many less technical users (e.g. if one was using OpenBSD + Firefox > as a platform for a thinclient / web browser + think client based > application). Maybe firefox eventually starts on its own (after 5 > minutes) but I have never had the patience to wait around to try > that...in any case that would be unacceptable for a general user. > > Does any one else experience this? > > Is there any solution / work around? > > Thanks.
