After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552254 - blocks when file descriptors of stdout/stderr get closed
blocks when file descriptors of stdout/stderr get closed
Status: RESOLVED INCOMPLETE
Product: conduit
Classification: Other
Component: core
0.3.x
Other All
: Normal enhancement
: ---
Assigned To: conduit-maint@gnome.bugs
conduit-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2008-09-14 17:10 UTC by José Carlos García Sogo
Modified: 2009-06-23 10:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description José Carlos García Sogo 2008-09-14 17:10:39 UTC
Please describe the problem:
From Debian BTS bug #487619

Package: conduit
Version: 0.3.10-1
Severity: important


If you going to start conduit from shell and send it to background (so
either with CTRL+Z or start it with "conduit &" and close the shell
afterwards), conduit will block and does not continue to work (it even
can't get closed without kill).

After a discussion with one of the developers on IRC he guess it's the
python logging module which makes the problem here.

So conduit will work when started from menu or via session auto-start
but for those of us which sometimes start conduit manually, it's
currently necessary to keep the shell open or redirect the
file-descriptors of stdout/stderr to a file (so "conduit 2>&1
>/tmp/conduit.log").

Cheers,
Andreas


Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 John Carr 2008-09-14 18:12:23 UTC
For me, Conduit freezes when I Ctrl+Z. This also occurs with f-spot and rhythmbox and gedit. When I discussed with OP on IRC, i believe Tomboy also had this problem. Isn't Ctrl+Z "stop"... Can you please confirm whether GUI applications are meant to work in this situation? (a casual fg resumes normal operation).

When I close my terminal, any applications i started from the terminal also close. So I can't reproduce...

GNOME Do or Alt+F2 might be better workarounds than launching conduit from terminal.
Comment 2 José Carlos García Sogo 2008-09-14 19:14:10 UTC
When reporter says CTRL+Z, I think he means 'CTRL+Z && bg', which does the same than 'conduit &'. Once a process is sent to background, it is detached from terminal, and the process should not finish when terminal is closed. For a command line application it can be a problem (or not, think about daemons) as it loses output, but that is not for a GUI.

Launching conduit from terminal is a good option given the amount of debugging info it prints on stdout. GnomeDO or Alt+F2 is not an option if you want that. Anyway, it should not block when it is in bakground and terminal is closed. It should go on working, till the GUI window is closed, though a stdout/stderr is not available for printing.
Comment 3 John Stowers 2009-01-23 04:17:37 UTC
I just tried this and it worked fine. I was able to CTRL+Z && bg to send it to background.

Can you confirm this bug still exists and that I have understood correctly?
Comment 4 Tobias Mueller 2009-06-23 10:38:23 UTC
Jose, I am closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!