Closed chreekat closed 7 years ago
Silentcast creates a bash script named ffcom
. When ffcom
is running on your system, it should mean the ffmpeg
is running in the background, recording your screen. Silencast checks to see how many instances of ffcom
are already running. If greater than 1, it gives this error message. From a terminal, try
pgrep -f ffcom
to see process numbers for what's running with ffcom
in its full process name
and
pkill -f ffcom
to stop running all processes with ffcom
in the full process name, or you can directly kill
each process number reported from pgrep
.
You may also have the python script running a couple of times that's supposed to show the stop icon in the systray. If that icon is not showing, you may not realize Silentcast is still running. There was a bug that I fixed with the most recent release that seth/silencast ppa may not be up to date with, where that icon doesn't show up in the systray sometimes. To see if that python script is running and trying to display a stop icon that you don't see, try
pgrep -f unity_indicator.py
and stop those process same as above.
I will followup with Seth Johnson about putting the latest release in his repo. It fixes a couple of other issues as well.
Yep, sorry. I'm working on it. Just did a fresh install and all my files are scattered among my backups still. Now that ubuntu has moved away from avconv and back to ffmpeg I might be able to automate the packaging so this won't happen again.
On Thu, Dec 15, 2016 at 10:38 AM, Colin Keenan notifications@github.com wrote:
Silentcast creates a bash script named ffcom. When ffcom is running on your system, it should mean the ffmpeg is running in the background, recording your screen. Silencast checks to see how many instances of ffcom are already running. If greater than 1, it gives this error message. From a terminal, try
pgrep -f ffcom to see process numbers for what's running with ffcom in its full process name
and
pkill -f ffcom to stop running all processes with ffcom in the full process name, or you can directly kill each process number reported from pgrep.
You may also have the python script running a couple of times that's supposed to show the stop icon in the systray. If that icon is not showing, you may not realize Silentcast is still running. There was a bug that I fixed with the most recent release that seth/silencast ppa may not be up to date with, where that icon doesn't show up in the systray sometimes. To see if that python script is running and trying to display a stop icon that you don't see, try
pgrep -f unity_indicator.py and stop those process same as above.
I will followup with Seth Johnson about putting the latest release in his repo. It fixes a couple of other issues as well.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/colinkeenan/silentcast/issues/34#issuecomment-267405798, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOKWG7bxRBlCRUJ2_M_CWUJ0nHZmAhJks5rIYkUgaJpZM4LOSZH .
--
Seth Johnson
I'll wait for an updated PPA, but fwiw none of those subprocesses were/are running, and I got the recording-in-recording warning on the very first invocation!
Ok, so there is something wrong here. I will leave this bug open.
I'm not sure if this is the problem, but on branch "next" of silentcast, I have changed the code that counts instances of ffcom from pgrep -f ffcom | wc -l
to pgrep -f ffcom | wc -w
. The difference is wc -l
counts newlines while wc -w
counts words. Since pgrep
outputs a single process number per line, the two counts should be the same. If somehow, a single newline is spuriously output by pgrep, then that would cause this issue. For example echo "\n" | wc -l
reports 2 while echo "\n" | wc -w
reports 0.
If you want to test it if that's the problem for me, you could simply edit /usr/bin/silentcast
and change line 51
from
ffcoms_running=`pgrep -f ffcom | wc -l`
to
ffcoms_running=`pgrep -f ffcom | wc -w`
Oh, that explains it. I have a custom pgrep in ~/bin.
A fix for this would be to constrain PATH at the top of the script, maybe?
Out of curiosity, what does your ~/bin/pgrep
do?
It calls ps
on the resulting PIDs (if they exist)! :D
#!/bin/bash
things=$(/usr/bin/pgrep $@)
if [ -n "$things" ]; then
ps $things
fi
The reason your script causes the silentcast error on first use is that when used with the -f
option of pgrep, your script reports it's own running instance, producing 2 newlines and 13 words even when there's no process with that in their name running other than your pgrep itself.
I don't think I should restrict the path since I should be able to count on pgrep
working properly. Instead, I think you should rename your's to pgreps
or something. Also, it seems like a good idea for you to fix your script to not report itself when -f
is used.
I've decided to change the "w" back to an "l" in the branch "next".
Well then consider this a new bug report... setting an explicit PATH (or using absolute paths) is good practice, since it means a malicious PATH can't pwn a user. :)
Ok, what would you suggest I add to the top of the script?
tbh I'm not finding any corroboration of my claim in /usr/bin... I can't remember where I learned what it is I think I know.
Anyway, what I'm thinking of is e.g.
PATH=/bin:/usr/bin:whatever-else-you-need-like-/sbin
export PATH
I may have seen a lot of this in linuxfromscratch, which needed to run lots of scripts a root.
Ok, in branch "next", I have added
export PATH=/usr/bin
to the top of the silentcast script. That seems to be all I need for the path. I would like you to try adding that to the top of /usr/bin/silentcast and see if everything works.
Thanks for pointing this out.
For me on Ubuntu 14.04, I had to use the following:
export PATH=/bin:/usr/bin
df, grep, rm, and sleep are all found in /bin.
Everything worked after that!
On Thu, Dec 15, 2016 at 5:21 PM, Colin Keenan notifications@github.com wrote:
/usr/bin/silentcast
Thanks for the quick feedback. I will add /bin. I wasn't sure if that was needed, and couldn't tell because Arch Linux just symlinks /bin to /usr/bin.
Makes sense. Thanks a lot!
On Thu, Dec 15, 2016 at 5:33 PM, Colin Keenan notifications@github.com wrote:
Thanks for the quick feedback. I will add /bin. I wasn't sure if that was needed, and couldn't tell because Arch Linux just symlinks /bin to /usr/bin.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/colinkeenan/silentcast/issues/34#issuecomment-267494558, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg3qlKhMIClmF7wrCI7cwleKTdWujW8ks5rIeqCgaJpZM4LOSZH .
@chreekat updates are out for the PPA. Yakkety is currently published, Xenial, Trusty, and Precise are building now.
I'm on Ubuntu 14.04 LTS. I installed silentcast via the sethj/silentcast ppa. When I try to run it, I am warned that I am "already doing a recording of a recording".
I did not install Topicons, but then I don't think I'm using Gnome. Or is Unity Gnome? I stopped paying attention to these things a long time ago.
Anyway, the error message is still incorrect. :)