Thunor,
I am new to this thread and have not yet examined the pages since 31. I think I need your help to understand and resolve what appears to be an unexpected way of exiting from a dialog.
I am integrating Frisbee into the mainstream puppy configuration, somewhat successfully. I saw this problem during testing with the recent betas of Precise pup 5.4.1 but cannot re-create the situation now. In 5.4.1 I see no problem, because the Frisbee dialog window always exits as expected, returning control to the script that invoked gtkdialog3. (We are starting Frisbee by way of the "connect wizard's" "Wired or wireless LAN" option.)
However, peebee and others see the "exit" (via the "Exit" button) failing the first time the dialog is used. Subsequent uses of the Frisbee script exit normally. When I was seeing that problem, I could repeat it if I chose another network tool, exited it, then chose Frisbee again. Furthermore, when Frisbee exits normally, another dialog appears to allow the user to try another tool. When the exit process malfunctions, that dialog does not appear, implying that not only did gtkdialog not return to its caller, it also bypassed the caller's caller. That behavior suggests that something actually kills the process running the dialogs.
To gather what evidence I could, I added trace logging before and after the invocation of gtkdialog3, Here is the code at the end of the Frisbee script, showing the definition of the "exit" button, the added logging and the code that is expected to execute following the use of gtldialog3:
Code: Select all
export MAIN_DIALOG="
. . .
<button tooltip-text="Exit">
<input file stock="gtk-quit"></input>
<label>Exit</label>
<action type="exit">Exit-NOW</action>
</button>
</hbox>
</vbox>
</notebook>
</window>
"
echo "$$ $0 Executing gtldialog3 MAIN_DIALOG" >> /tmp/udevtrace-modem.log #DEBUG
RETVALS=`gtkdialog3 --program=MAIN_DIALOG --center`
echo "$$ $0 Resumed after gtldialog3 MAIN_DIALOG" >> /tmp/udevtrace-modem.log #DEBUG
rm -f /tmp/Pwireless* 2>/dev/null
eval $RETVALS
if [[ "$EXIT" == "RESTART" ]] ; then
/etc/init.d/10-frisbee stop
/etc/init.d/10-frisbee #121031 omit 'start' argument to run even if Frisbee not set as default.
exec Frisbee
elif [[ "$EXIT" == "Exit-NOW" ]] ; then #121108...
if [[ "$(pidof frisbee_tray)" == "" ]] ; then
[[ "$(pidof network_tray)" != "" ]] && killall network_tray
/usr/sbin/frisbee-tray&
fi
fi
Here are the trace results:
Expected trace (from my version of precise pup 5.4.1):
Code: Select all
30590 /usr/local/bin/Frisbee Executing gtldialog3 MAIN_DIALOG
30590 /usr/local/bin/Frisbee Resumed after gtldialog3 MAIN_DIALOG
Peebee's trace on first use in session:
Code: Select all
10427 /usr/local/bin/Frisbee Executing gtldialog3 MAIN_DIALOG
As a second experiment, peebee ran Frisbee from the command line and saw it hang. I ran the same test and saw Frisbee return to the command prompt, as one would expect. That is consistent with his seeing a problem whereas I do not get it, even though we have installed the same set of packages to implement the integrated Frisbee.
peebee wrote:Don't know if this helps... but I tried running Frisbee from a terminal on Precise - messages are below....
but when I clicked Exit having setup a wifi connection, Frisbee did not finish - the terminal did not return to the # prompt and I had to type cntrl-c to make Frisbee finish.
There weren't any messages created when this happened.
Code: Select all
# Frisbee
/usr/local/bin/Frisbee: line 14: 11306 Terminated gtkdialog-splash -placement center -bg orange -text "Preparing network interfaces for Frisbee"
dhcpcd[11396]: version 5.2.9 starting
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
dhcpcd[11396]: forking to background
dhcpcd[11396]: forked to background, child pid 11426
killall: frisbee_tray: no process killed
OK
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
killall: wpa_supplicant: no process killed
killall: frisbee_tray: no process killed
ioctl[SIOCSIWAP]: Device or resource busy
[1]+ Done reset-wpa
When I ran the test, I received almost-similar messages - rerwin's normal/successful run from command line (with no connections available):
Code: Select all
# Frisbee
/usr/local/bin/Frisbee: line 14: 4656 Terminated gtkdialog-splash -placement center -bg orange -text "Preparing network interfaces for Frisbee"
dhcpcd[4770]: version 5.2.9 starting
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
dhcpcd[4770]: forking to background
dhcpcd[4770]: forked to background, child pid 4810
cat: /tmp/wpa_supplicant.log: No such file or directory
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
killall: frisbee_tray: no process killed
OK
#
1. Is there a way to add some debug/troubleshooting logging to gtkdialog to help identify where things go awry? Or is there already someplace to find diagnostic info from gtkdialog?
2. Because this seems, to me, to be a case where a data item is tested but is not the expected data, thus producing random results, could you examine the gtkdialog code that handles the "exit" process to look for a possible bug of that sort?
3. And, of course, please share any other thoughts you might have about this apparent malfunction, particularly if you have already addressed this problem in your releases after precise's gtkdialog version 0.8.0.
For reference, I attach the complete Frisbee script in case it holds other clues. Thank you for whatever you can do to help me troubleshoot this issue.
Richard