You can hack zim to stop listening for filesystem signals. If that
makes the problem go away, you can at least confirm the root cause.
To do so edit "zim/fs.py" -- this will be e.g. in /usr/lib/python/zim
- depends on your install locations.
In this file near the top there is a section:
-------------
try:
import gobject
import gio
if not gio.File.trash:
gio = None
except ImportError:
pass
--------------
If you remove this section, zim stops using file system monitors.
Hope this helps,
Jaap
On Mon, Nov 17, 2014 at 4:34 PM, mario@tiscali <mbezzi@xxxxxxxxxx
<mailto:mbezzi@xxxxxxxxxx>> wrote:
Jaap thank you for taking the time to look into this.
I also have the feeling that this has to do with filesystem's
change notifications.
While zim became a very important part of my everyday's actvity,
there are days worse than others, and today is one of these: I
have been editing files in zim's tree (not necessarily zim's
pages, rather files attached to zim's pages) quite a lot (and no
FTP!), and here we go:
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
I am continuosly running the following command to keep track of
what's going on:
$ while true; do exec ps -u mario -To comm | sort | uniq -c | sort
-n| tail;ps -u mario_bezzi -To
pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm|wc
-l;sleep 10; done
and this is the result (showing only the major contributors:
5 nautilus
5 totem
7 gnome-keyring-d
8 spicec
12 taskldr
23 dropbox
... ...
629 zim
1017 Total
Which means that at the moment zim is using 629 threads driving
the total very close to the limit (1024), and from time to time to
the limit, which causes the fork failure.
This is RHEL 6.5 with current maintenance. I would like to help
gathering diagnostics if I only knew how.
Hints?
Thanks again,
mario
On 11/05/2014 08:13 AM, Jaap Karssenberg wrote:
Hi Mario,
Just checked it on my own system. Just running one notebook in
stand-alone mode I get only 2 threads, the main thread + one for
the thumbnails in the attachment browser. When running with
background daemon I get ~5 threads (they show up as "python" in
the list, not "zim" so not sure exactly which belong to zim and
which don't). I think this is because we use the
"multiprocessing" library, which uses a few threads per process
for process communication.
So nothing weird there, although more extensive testing would
probably be needed to be sure I can not duplicate your result.
As to what may be causing it, somehow the ftp process must be
pinging the zim process. Maybe the filesystem starts notifying
zim of file changes? Should normally not happen if the ftp
transfer goes to a different folder, but not sure what could be
happenign on that layer. Just a wild theory.
Regards,
Jaap
On Sat, Oct 25, 2014 at 11:36 AM, mario@tiscali
<mbezzi@xxxxxxxxxx <mailto:mbezzi@xxxxxxxxxx>> wrote:
Hi Jaap,
just a quick update: After recycling zim-wiki the number
of threads stayed in the 11 ballpark for quite a long time.
It suddenly started climbing while I was running a completely
unrelated ftp file transfer. Stopped climbing when the ftp
ended, restarted climbing when I purposedly ran another ftp.
It is now at 227!
Can't even imagine the relationship between zim-wiki and my
ftp activity, but I wanted to share what I saw so far.
Thank you,
mario
On 10/24/2014 07:09 PM, mario@tiscali wrote:
Jaap,
thanks for your kind reply.
To just get the number of active threads issue the following
command: ps -eT|grep zim|wc -l
For a detailed list use: ps -fT -C zim
By the way: After a quit/start and couple of page views
zim-wiki sits at 11 threads. I will keep it under control.
Long and probably not nicely formatted command output follows:
..snip..
