[master 2/2] Use exec instead of system to run metacity

David Shea dshea at redhat.com
Thu Jul 31 13:51:46 UTC 2014


On 07/31/2014 09:09 AM, Vratislav Podzimek wrote:
> On Thu, 2014-07-31 at 08:48 -0400, David Shea wrote:
>> On 07/31/2014 05:11 AM, Vratislav Podzimek wrote:
>>> On Wed, 2014-07-30 at 17:00 -0400, David Shea wrote:
>>>> This way we don't up with a second process named "anaconda" that's
>>>> actually a middleman for the window manager.
>>>> ---
>>>>    anaconda | 11 +++++------
>>>>    1 file changed, 5 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/anaconda b/anaconda
>>>> index 4d4676e..6ff4a89 100755
>>>> --- a/anaconda
>>>> +++ b/anaconda
>>>> @@ -269,14 +269,13 @@ def startMetacityWM():
>>>>            # after this point the method should never return (or throw an exception
>>>>            # outside)
>>>>            try:
>>>> -            returncode = iutil.execWithRedirect('metacity', ["--display", ":1", "--sm-disable"])
>>>> -        except BaseException as e:
>>>> +            os.execlp("metacity", "metacity", "--display", ":1", "--sm-disable")
>>>> +        except BaseException:
>>> I know you didn't come up with with it, but do we really need to catch
>>> all BaseException-inherited exceptions here? I mean, it shouldn't throw
>>> an expception outside, but if it raises anything else from OSError, it's
>>> a bug we should fix, right? I'm probably thinking too much in the
>>> context of the recent "at the edge with RAM" context, but I've seen
>>> various failures we hide in case something like ENOMEM starts happening.
>>>
>> Yeah, raising anything other than OSError would be weird and something
>> to fix, but I think the idea behind catching BaseException is so that
>> odd errors are logged somewhere instead of just printed to the screen
>> and forgotten. Of course this means I shouldn't have removed the part
>> where we actually log the exception, but I don't see catching it in this
>> case as harmful. If we catch it, we log an error and immediately exit.
>> If we don't catch it, python prints a backtrace to the console and
>> exits. If we run this code after sys.excepthook has already been
>> installed and don't catch BaseException, then something bad will
>> probably happen.
> So shouldn't we at least restore the original excepthook in the child
> process?
>

Yeah, probably. Maybe an iutil function that does a fork/exec plus all 
this extra stuff would be nice. I think I'll save this commit for the 
signal handling batch and work on making that part of it a bit nicer.


More information about the anaconda-patches mailing list