Force sugar-runner.desktop to use Terminal

[srevinsaju]

This is related to #4

sugar-runner fails on Run Command because it cannot be executed along with nohup. However, keeping a running terminal open allows to run sugar-runner. This might be caused due to the incompatibility of the Xephyr and other X libs to create nohup background processes. Most Run commands use nohup to start the process. However, as an alternative, the sugar-runner.desktop can be fixed to allow the running from the GUI icon

[srevinsaju]

@quozl @chimosky

[quozl]

I don't like having to show a terminal without good reason. I don't agree with the reason given. You're missing telling us something, but I don't know what. Or you've found a workaround rather than the best solution.

In @icarito's traceback, the dbus.SessionBus() call fails with connection refused.

The failure occurs here; https://github.com/sugarlabs/sugar/blob/master/src/jarabe/view/service.py#L51

It means there is no D-Bus session bus, either because the daemon has not been started, or the critical environment variable DBUS_SESSION_BUS_ADDRESS has been lost before Sugar is run.

You should already have a D-Bus session bus, and you can check that by looking for dbus-daemon processes before clicking on the icon, or by testing from Python;

>>> import dbus
>>> x = dbus.SessionBus()
>>> x
<dbus._dbus.SessionBus (session) at 0x7f4c1c2e3350>
>>> █

Now sugar-runner:scripts/xinitrc starts another session bus and replaces the environment variable before calling /usr/bin/sugar. The environment variable and the session bus is for Sugar only, not your existing desktop session.

Therefore, when Sugar calls dbus.SessionBus it should be using the new value of the environment variable to reach the new session bus process.

You can diagnose this by adding code to Sugar to print the environment variable or run a shell command to list the dbus-daemon processes.

You can also diagnose by using strace to follow each process to termination.

Incidentally, it isn't clear what stops the new session bus, and you could end up with many of them.

Please do read man dbus-launch, as there's a new autolaunch feature that wasn't around (if I recall correctly) back in the dark ages when sugar-runner was written.

Also, as you've found starting in a Terminal works better, you might find out why; perhaps the stdin, stdout, or stderr streams are being used or relied upon when they should not. dbus-launch has a --close-stderr option which reminded me of this.

[srevinsaju]

Thanks. I needed your help for this. This is actually a workaround for the current problem. The problem can be recreated as such

nohup sugar-runner

Fails on terminal

But

sugar-runner

Works on terminal.

Using nohup redirects output to nohup.out in the cd.

The only workaround I found is to create another script (maybe sugar-runner-subprocess) which may use subprocess.Popen to launch another process running sugar-runner. Doing as such removes the need to add the Terminal attribute and that would also make it easier to run it from the run command.

I found that the run command uses nohup to launch a new background running process and that causes Xephyr to fail as such

[srevinsaju]

Thanks for the information on the DBus thing. I got some clues on how to fix this better. But I will need your assistance while manipulating DBUS again. :)

[quozl]

We don't appear to have agreed. Re-reading your pull request, I think you haven't described the problem you are trying to fix. Please phrase it as (a) what you try to do, (b) what you expected to observe, (c) what you observed instead. I expected this in the commit message.

The other warning sign for me is your wording in the opening comment which suggests doubt and speculation.

nohup is almost never really needed, as the process execution environment changed since it was first written. There's a lot of old documentation out there, and people easily gravitate toward trying to fix problems using nohup that are better fixed by understanding and fixing the cause.

[srevinsaju]

(a) Trying to fix #4 (b) sugar-runner should start if launched from the desktop file / from the Run Command (c) It doesn't start because of the dbus error (probably)

The other warning sign for me is your wording in the opening comment which suggests doubt and speculation.

Will change that, once I am close to fixing the bug (in the right way, than a workaround)

nohup is almost never really needed, as the process execution environment changed since it was first written. There's a lot of old documentation out there, and people easily gravitate toward trying to fix problems using nohup that are better fixed by understanding and fixing the cause.

Either nohup or running the command in the background by using the &, for example

python -m http.server 8000 &

fails when the command is sugar-runner You can try it out by

sugar-runner &

and see if that works. `

sugar-runner

works for sure. It might be the absence of stdin which causes the problem, (as I redirected both the stderr and stdout to log files), but the actual code does not have any stdin requirement as such. Executing sugar-runner with the Terminal flag as positive opens the terminal, and fixes the issue. (which is a workaround, and not the right fix as you have suggested). I might actually need to fix what is broken than the workaround. I did not know the stuff you had told in comment https://github.com/sugarlabs/sugar-runner/pull/6#issuecomment-611787172, so, keeping that in mind, I will try to find a better fix.

PS: Seems like this mode of conversation is not apt for me. I would like to talk in live with you to fix these bugs. Maybe, my messages become less comprehensive. :facepalm:. Sorry about that.

[srevinsaju]

This fails on the terminal, might help you to get some observation / inference

touch dummy
cat dummy | sugar-runner > ~/log.log

but this doesn't

sugar-runner

[quozl]

Most important thing is to find out why "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket" occurs. That's the heart of https://github.com/sugarlabs/sugar-runner/issues/4. Until you can explain why nohup or running with a terminal changes the outcome, you haven't progressed in solving the problem. nohup is built from open source code; perhaps there is something that it does that should be included in sugar-runner.

Looking at nohup.c, there are several things that it does, but it isn't obvious to me which of those would have an effect on the ability of the D-Bus client in Sugar to contact the D-Bus session daemon started by sugar-runner.

Other things that nohup.c does that you could try (you - 'cause I don't need sugar-runner myself, and, as I said before, I made a very careful decision years ago to abandon maintaining and releasing it) include;

• redirecting stdin,
• redirecting stdout,
• redirecting stderr,
• binding file descriptors with dup2,
• handle the SIGHUP signal by ignoring it.

Here's the source code. nohup.c.txt

[chimosky]

Closing as sugar-runner now works fine, tested by James Simmons.