- This topic has 42 replies, 11 voices, and was last updated Jan 4-7:27 pm by BobC.
-
Posts
-
Brian Masinick
BobC, if you know the name of the procedure, process, or program, then you can use the ps command to find out what processes are running.
ps a shows the processes you are running.
ps ax shows all the processes and the commands being performed.
ps alx shows all processes, commands, priority, time, etc.
There are other options available for the ps command that can be done to get specific details about running processes.
Is that helpful to you?
--
Brian MasinickAnonymous
“the kill didn’t work”
BobC, try it like this:moo=$(yad --text=$"Data is being written to devices.\nPlease wait...") & pid1="$!"FWIW, by running htop while that “Please wait…” yad dialog is displayed, you can see the separate processes. For a better visualization, “sudo apt install psmisc” and use the pstree command while that dialog is displayed.
BobC
Yes, thanks for explaining. Its coming back with a different process number that is 1 lower than the window that remains on the screen, but I suppose that its off by 1 is just a function of not many other things running. I ran it in a terminal by itself…
$ moo=$(yad --text=$"Data is being written to devices.\nPlease wait...") & pid1="$!" [1] 29533 bobc@xps15:~/testing $ ps -ef | grep yad bobc 29534 29533 0 14:36 pts/1 00:00:00 /bin/bash /usr/local/bin/yad --text=Data is being written to devices.\nPlease wait... bobc 29535 29534 0 14:36 pts/1 00:00:00 /usr/bin/yad --text=Data is being written to devices.\nPlease wait... bobc 29557 29076 0 14:36 pts/1 00:00:00 grep yadSo, it came back with 29533, but if I read the results correctly, 29533 was the parent of 29534, which was the parent of 29535. This explains why the author’s kill 29533 didn’t work, but it doesn’t tell me why or a way to get the correct pid to kill which I think is 29535 because if I kill 29534, 29535 is left hanging…
If it can’t be identified and killed correctly, I suppose the kill statement should be removed.
Again, with safemode FALSE as my code has it set, the box never pops up and therefore there is no need to kill it later, but as always, I’m curious for a better way…
Brian Masinick
Yeah, it looks like the original author was incorrectly attempting to kill the PPID (the parent of the current process) rather than the desired process. Moreover, the real question is whether he intended to kill the bash command that initiates the yad process or whether the proper thing is to kill the process that actually presents the message – that is, the yad command itself.
If you have access to the code fragment that runs this code, perhaps the “real intent” can be deduced. Otherwise, I do think that you’re still on the right track here. It’s the PID, not the PPID that needs to be used, so the logic in the code needs to be altered accordingly.
--
Brian MasinickBrian Masinick
Sorry, skidoo seems to have a better handle on what’s happening; his suggestions are right on.
--
Brian MasinickWhat looks odd to me is that it looks like multiple processes got kicked off running yad, and neither is the one that was returned. I suspect the same thing happened when it ran in background, and we do get a process Id back, but not the one of the process we need to kill.
Yes, its beyond me, too.
So, I see others must have had the same problem killing yad windows…
The answer they found was to use pkill
pkill -f "yad --title="Yad-window kill demo""I didn’t try it, yet…
PS: pkill is included in procps package
PSS: so this worked from the terminal command line (I’m not on the same PC at the moment), so should also work in the script to be displayed while sync is running…
pkill -f "yad --text=Data is being written to devices."- This reply was modified 3 years, 4 months ago by BobC.
- This reply was modified 3 years, 4 months ago by BobC.
^— typofix and the spamfilter ate the post
BobC, if you revise the line in the script to exactly this and retest it should achieve the desired result.
moo=$(yad --text=$"Data is being written to devices.\nPlease wait...")& sleep 1 & pid1="$!"Delving into “WHY” the original did not work as expected could turn into a long and speculative conversation. Differences in bash behavior ~~ non-interactive shell spawned from within a script, vs commandstring entered via (interactive shell) the terminal emulator command prompt ~~ can lead to confusing “sometimes works, sometimes not” outcomes. What implicit bash shopts, under debian, exist for one vs the other? I’m not motivated to chase down that detail at the moment.
https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.htmlWithin the comments of the recent “bobHelpnotes” script, I mentioned (addressing this identical problem) the necessity of injecting a sleep command prior to attempting to read $! and, similarly, sleep(ing) prior to attempting to open a file which has been freshly created via the touch command. No, I don’t care to speculate why, on a 12-core ramdrive-resident test system, I should have to fuss with waiting for newly-created file descriptors.
strace -eclone unplugdrive.shthe yad executable is a process.
The option “–text” (or –info or yadda) passed to yad instructs it to spawn a windowed process.
Said differently, the yad executable instructs libgtk to spawn a dialog instance (the windowed process).
.
man yad
–kill-parent is available as an option, is not the default behavior (and usually would not be desirable).
The yad executable — the process unhelpfully targeted by the errant script — at launch, it exports YAD_PID into its runtime enviroment… and lingers, waits for all of its spawned (and effectively detached) processes to finish before exiting. This grants us esoteric functionality, in terms of ability to craft MDI gui applications and have the child windows able to talk between each other… and ability to reparent individual, or multiple, child windows during runtime use of the application. Each child process of the yad executable is, essentially, “detached”. Quotation marks because that is an inexact description ~~ not identical to “nohup”, not “backgrounded”, and not exactly “disown(ed)”.others must have had the same problem killing yad windows
$( yad blah bla blah )
^——- Until ours becomes a PerfectWrold, I’ll recommend ALWAYS launching yad in a subshell.
Unless you do so, bad (runaway, difficult to kill) booboos can wreck havoc in the parent runtime environment.Skidoo, thanks 🙂
Yes, sometimes the why part isn’t worth the effort. I will try your sleep solution when I boot that machine on Linux again. I have to use it for Win 10 tasks unfortunately. I have seen timing issues like that on other systems before as well.
PPC
Bob,
I tested over the week-end. this script runs great! Just perfect, congratulations, I hope anticapitalista makes this improved version available over the general antix repo, so anyone can use it!I remember the days when I helped you out with yad scripts 🙂
One other veryyy small thing that could be changed is the calendar that pops up when you left click the time on icewm toolbar. anticapitalista choose to use a simple yad-calendar, but I suggested, and use myself a different version.
To test it, you don’t even have to install anything… Just edit the “~/.icewm/preferences” file and append this to its end:ClockCommand='yad --calendar --mouse --close-on-unfocus --undecorated --skip-taskbar --button="!/usr/share/icons/papirus-antix/22x22/actions/adjustrgb.png":set_time-and_date.sh --button="!/usr/share/icons/papirus-antix/22x22/actions/dialog-close.png":1'I hope the forum does not mangle the code (before every option following “yad” there’s a double minus character).
What this changes: the calendar pops up in an undecorated window that seems “integrated” on the toolbar. If you click the time again, no new calendar window will pop up (I saw a reviewer on YouTube doing this, trying to close the calendar…). It also has a close button on the lower right and a button that takes the user directly to the set time and date script! (I liked this on old windows versions, avoided the trouble of having to go to the control panel to set the date…)-P.
PPC, I don’t actually know much about yad, compared to you, but the unplugflashdrive seemed like a lot of clicking to me as well. I think most users would expect it to work in a manner similar to windows where you tell it to dismount a drive and if there is a problem you get an error, and otherwise it says when it’s ok to remove it.
The one thing I tried and failed at was to get it to give an error sound if the result was an error. Nobody asked for that, but the error vs no error windows look similar, and it might save someone problems if it would help them notice there was an issue. Perhaps it would be good enough if there were red visual cues on the error screen.
I have found it best to just put code in zip files if it can’t be copy/pasted without trouble.
I will give your calendar a try. Thanks for testing the flashdrive code.
PPC, I have attached a fresher version of “my just do it” version of the unplug code without the popup issues, see attached. PS: I tested your Yad Calendar improvement, and the only problem I had was wondering about the icon choice to change the date/time.
Skidoo, I tried the sleep first as you coded it, but it still got the wrong pid to kill, I think. I had it echo out the process list and pid it was going to kill, see pic. Here is that section of the code used:
# Obtain confirmation to proceed with unmounting if [ "$safemode" = "TRUE" ]; then yad --text=$"About to unmount:\n$summarylist\nPlease confirm you wish to proceed." if [ $? = "1" ];then yad --text=$"Nothing has been unmounted.\nAborting as requested with no action taken." exit 1 else # Ensure everything is written to storage then unmount yad --text=$"Data is being written to devices.\nPlease wait..."& sleep 1 & pid1="$!" fi fi ps -ef | grep "yad" echo "pid1= $pid1" sync if [ "$safemode" = "TRUE" ]; then kill $pid1 fi count=${#mountpointlist[@]} echo count is $count- This reply was modified 3 years, 4 months ago by BobC. Reason: added test results on PPC's yad calendar
Attachments:
- You must be logged in to reply to this topic.
