Creating sub-processes using 100% CPU when content is added #165

philnse · 2021-06-28T11:50:29Z

After hours of research regarding my problem I desperatly end up posting here as I just can't figure out how to solve the issue.
I'm using rar2fs with an instance of plex. For the last ten days, rar2fs was running as expected: One instance per mount. After adding two packed episodes overnight I ended up with a 100% CPU load for the mount that is handling the series section. This is an issue I had several times in the past. It seems to be the same issue adressed in in #11

If I remember correctly the suspected reason for it was the plex media server wanting to add files to the mounted but still rar'd files. I figure it has something to do with chapter images that are generated by plex using the transcoder, as no files are saved in the original content folder but the plex media server's library I'm having a hard time to reproduce the error.
Could it be that some kind of cache is piled with data when generating those chapter images and rar2fs crashes? I've attatched an excerpt of my webmin to clarify:

Please let me know if you need any logs. I'm happy to provide them.

//EDIT: I forgot to mention what I tried to solve it by now:
run as root
run as regular user
--seek-length=0, --seek-length=1
--no-smp
Killing exceeding/crashed instances of rar2fs resulting in loosing the mounted content

Regards

My system is running:

Ubuntu 18.04.5
rar2fs v1.29.5-gita393a68 (DLL version 8) Copyright (C) 2009 Hans Beckerus
FUSE library version: 2.9.7
fusermount version: 2.9.7
UNRAR 6.02 beta 1 freeware
Plex Media Server Version 1.23.4.4712

hasse69 · 2021-06-28T19:15:57Z

Sorry to hear this old problem (if the same) seems to persist. Not heard any reports of this in a very long time.

What I need from you to even have the slightest chance to find the root cause is a gdb stack dump from a process that is stuck at 100% load. You would attach gdb to the pid and then dump the stack using the 'bt' command. You might need to rebuild rar2fs using '--enable-debug' in case the stack trace lacks any readable symbols and run the non-stripped binary from the 'src' directory. Thus not the one installed by 'make install'.

hasse69 · 2021-06-28T20:08:11Z

If you wish to test some other version I think you need to go back 4-5 years to v1.23.1. This is when pipes were replaced with conditional variables. It is the only thing I can think of that would perhaps cause a regression like this.

philnse · 2021-06-29T09:25:37Z

Thank you so much for the quick answer! As I'm having the issues after starting to update to newer versions of rar2fs as soon as possible I'll try your suggeestion of using the older version first. I'm kind of overwhelmed by your first comment as I'm not exactly sure what you're askin me to do! :)

I'll get back after some testing with the older version.

Thanks for this great software!

Regards

philnse · 2021-06-29T13:19:03Z

So I tried to install the version you mentioned and ended up with an error as in #85. After applying the patch and make gets to ./unrar I get this error:

(Sorry for the Screenshot, couldn't handle to post it properly in code.)

I guess it has something to do with the unrar version? Tried 6.0.7 and 5.5.6 for compiling while 5.5.0 is installed on the system.

I'm happy to try the things you said to do with the most recent version of rar2fs, as it seems to have some fiddling involved anyway. If you just could clarifiy what to do exactly I'm happy to do so.

Regards

hasse69 · 2021-06-29T19:32:19Z

What version did you use before you hit this problem?

philnse · 2021-06-29T20:00:26Z

I was using v1.29.5.

hasse69 · 2021-06-29T21:18:29Z

But I was under the impression you hit this problem when moving to 1.29.5 so what version did you upgrade from?

philnse · 2021-06-30T08:01:33Z

I tried to downgrade from 1.29.5 to 1.23.1 and ended up with those errors.

So currently I'm still using 1.29.5 with unrar 5.50 because installing 1.23.1 didn't work. After remounting with 1.29.5 and unrar 5.50 everything is working right now. It's kind of hard for me to reproduce the CPU load failure as it could take days for it to occur again. Maybe you could explain what you meant with:

What I need from you to even have the slightest chance to find the root cause is a gdb stack dump from a process that is stuck at 100% load. You would attach gdb to the pid and then dump the stack using the 'bt' command. You might need to rebuild rar2fs using '--enable-debug' in case the stack trace lacks any readable symbols and run the non-stripped binary from the 'src' directory. Thus not the one installed by 'make install'.

I'm happy to do this as soon as the CPU load issue comes up again! I could try to figure it out by myself with stackoverflow, but that could take ages! ;)

hasse69 · 2021-06-30T08:24:30Z

Ok my only comment was that when did you start seeing this issue? You moved to 1.29.5 at some point right? So before that what version were you using since you did not report this problem until now?

I will get back to you about details on how to attach gdb to a running process and dump the stack.

philnse · 2021-06-30T08:47:35Z

Ahh, sorry I didn't get that. I figured it might have something to do with my server config so I tried other stuff before. rar2fs worked flawlessly for years and wouldn't have thought it mighty break like this.

Sadly I don't know exatcly. I would guess at least since 1.29.0

hasse69 · 2021-07-03T05:55:45Z

Easiest way to attach gdb would be

gdb -p `pidof your_running_program_name`

However since rar2fs spawn many processes/threads the best way is to use the 'ps' or 'top' command to find the exact process id that is using a lot of CPU, and then

gdb -p <pid>

Once in gdb you will get a prompt 'gdb>' and and if input cannot be given do CTRL-C to interrupt it and then run the gdb 'bt' command.

In addition to this an strace might be useful. So in the same manner run the Linux 'strace' command and log output to some file

strace -p <pid> > strace.txt

Note that strace will not terminate since the process is more than likely stuck in a loop so just let strace run for a few seconds and then terminate it using CTRL-C.

Have you been able to reproduce the issue yet? If you manage to find an easy way to do that going back to some previous version like 1.29.4 and confirm it now works, if not step back a few more versions and so on. It would provide valuable input for me to understand what code delta we are dealing with here as well.

And sorry for the late reply, I have been rather busy at work recently and have not had a single moment of spare time.

philnse · 2021-07-03T10:29:48Z

Absolutely no problem! I would never expect quick answers anyway. It's free software you're maintaining in your free time. I totally understand it doesn't have highest priority.

I fell back one major version and now using version 1.28. The plan is to check if everything is working here and slowly work my way up to a version which is not. I have processes running since July 1st, added content and neither had sub-procceses nor high CPU load. So I guess I'll let it run for a week or until problems occur.

After that I'll use the commands you provided with a newer version which is causing problems.

Thanks again and have a nice weekend!

philnse · 2021-07-03T16:50:07Z

So it seems like the problem persists in v 1.28 aswell. I have one process with one sub-process so far (14075 and 14078) using 100% of CPU Here's the output of gdb:

Attaching to process 14075
[New LWP 14077]
[New LWP 14078]
[New LWP 14079]
[New LWP 29427]
[New LWP 2850]
[New LWP 4000]
[New LWP 7034]
[New LWP 7037]
[New LWP 7044]
[New LWP 7049]
[New LWP 7052]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f2af45627a0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffc0fc6c7a0, remaining=remaining@entry=0x7ffc0fc6c7a0)
at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.

and the output of strace running a couple of seconds:

strace -p 14075 > strace.txt
strace: Process 14075 attached
restart_syscall(<... resuming interrupted nanosleep ...>) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc0fc6c7a0) = 0
nanosleep({tv_sec=1, tv_nsec=0}, ^Cstrace: Process 14075 detached
<detached ...>

I guess it means I have to recompile using --enable-debug?

hasse69 · 2021-07-03T22:27:22Z

Yes I think you should recompile using --enable-debug. But gdb output looks a bit strange. Did you really interrupt using CTRL-C? I don't see the output from bt command.

philnse · 2021-07-05T09:17:58Z

Here's the output using the bt command. Not allot more information given. 'Top' now shows a cpu load of 250% for this process because of all of these sub processes. I'll recompile later with --enable-debug. Could you explain how to to that when not using 'make install'?

Attaching to process 14049
[New LWP 14050]
[New LWP 14051]
[New LWP 14052]
[New LWP 29414]
[New LWP 29804]
[New LWP 29832]
[New LWP 29883]
[New LWP 30602]
[New LWP 30623]
[New LWP 30630]
[New LWP 6463]
[New LWP 1838]
[New LWP 20226]
[New LWP 5452]
[New LWP 17786]
[New LWP 23038]
[New LWP 28384]
[New LWP 28518]
[New LWP 1268]
[New LWP 1270]
[New LWP 1272]
[New LWP 1274]
[New LWP 1276]
[New LWP 1278]
[New LWP 1280]
[New LWP 1282]
[New LWP 1284]
[New LWP 1286]
[New LWP 1288]
[New LWP 1290]
[New LWP 1292]
[New LWP 1294]
[New LWP 1296]
[New LWP 1298]
[New LWP 1300]
[New LWP 1302]
[New LWP 1304]
[New LWP 1307]
[New LWP 1309]
[New LWP 1313]
[New LWP 1315]
[New LWP 1318]
[New LWP 1330]
[New LWP 1332]
[New LWP 1335]
[New LWP 1338]
[New LWP 1340]
[New LWP 1342]
[New LWP 1344]
[New LWP 1346]
[New LWP 1351]
[New LWP 1354]
[New LWP 1357]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f6dde7247a0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffd4d654160, remaining=remaining@entry=0x7ffd4d654160) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28      ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) bt
#0  0x00007f6dde7247a0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffd4d654160, remaining=remaining@entry=0x7ffd4d654160)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x00007f6dde72467a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#2  0x000055bd80ca7824 in work (args=0x7ffd4d6541f0) at rar2fs.c:5070
#3  main (argc=<optimized out>, argv=<optimized out>) at rar2fs.c:5355
(gdb) Quit

hasse69 · 2021-07-05T12:42:15Z

No the problem is that what you see in gdb is the main thread, that is simply sleeping causing 0 CPU. In gdb you need to list the threads (info threads) and change to them one by one using t and do bt. I thought gdb was more clever than this but apparently not.

To rebuild using --enable-debug you need to reconfigure project using the ./configure script and then do make, a new binary with all symbols intact will be placed under the src directory.

hasse69 · 2021-07-05T13:59:20Z

Also, you might have attached to the wrong pid. A process that spawns additional threads and/or child processes will all show the same parent pid but different child pids. To check this use

top -bHc -n 1

The PID that is now presented in the leftmost column is what you should attach to and strace.

philnse · 2021-07-05T15:08:38Z

I hope I recompiled correctly with ./configure --enable-debug && make && make install

I killed all processes and remounted with the recompiled version. With your notes about gdb I'm hopefully able to provide some useful information next time!

hasse69 · 2021-07-05T17:10:03Z

Well the problem is that make install will strip the binary.

philnse · 2021-07-05T18:08:24Z

Thats what I found on stackoverflow. Well, as I said before, consider me a newbie.

hasse69 · 2021-07-05T18:17:49Z

No problem, just skip make install and copy the binary from src directory to where ever you want it.

philnse · 2021-07-05T20:24:22Z

So I recompiled with ./configure --enable-debug && make and copied the just compiled binary from src where the old one was (in my case /user/local/bin). I'll get back to you as soon as I have some information!

hasse69 · 2021-07-09T20:58:48Z

Btw, you mentioned issue #11 and I can see also issue #64 has been discussing this.
In both cases the removal of the specific support for RAR in RAR resolved the issue as far as I can tell.
So, my guess is that this is something that has not been observed (or) reported before.

philnse · 2021-07-10T10:23:31Z

So this issues adressed in #11 and #64 are fixed with newer versions as they are from 2015 and 2017? Couldn't figure out what might be wrong with my RAR out of those posts.

Haven't had a lockup since my last post. When I replaced the binary five days ago I also noticed another old instance of rar2fs in /bin/ which I deleted. Could that maybe have been a problem, too?

hasse69 · 2021-07-10T10:37:13Z

Not saying it is the same issue, but it might be relevant for further troubleshooting. The issues listed all had the same common problem with RAR files inside another RAR file. That support was removed long ago and stacking of mounts is replacing that functionality.
Wether your old binary in /bin would cause a problem or not is hard to tell but should not matter unless you do not explicitly call rar2fs in its location (eg /usr/bin/rar2fs) and completely rely on your PATH configuration and /bin sits before your other bin folder(s).

hasse69 · 2021-07-10T11:15:58Z

If you would like to push it I would try a complete PMS re-indexing. That would put rar2fs and your system under a major stress test.

philnse · 2021-07-10T14:24:20Z

I did that by updating the metadata for three libraries and by analyzing them and readding one test library and creating all thumbnails. So far all corresponding processes work as they should and never exceed 0,5% CPU load. They have their subprocesses, but I figure that is normal with workload like that?

hasse69 · 2021-07-10T16:05:58Z

Yes I would say it is normal and expected behavior. Let's not close this issue yet and allow it to run a few days more. I am a bit surprised though that it would suddenly just work? It is the same version for which you saw the issue, right?

philnse · 2021-07-10T21:55:07Z

So it seems to be the rar within rar issue. I found one process by now which seems to be locked up.
The directory has another rar in it. So I guess you where right! I don't know why it has taken so long...

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f17ecd4e0f4 in __GI___pthread_mutex_lock (mutex=0x7f17edb72990 <_rtld_global+2352>) at ../nptl/pthread_mutex_lock.c:115
#2  0x00007f17ecab8cfb in __GI___dl_iterate_phdr (callback=0x7f17ecf747f0, data=0x7f17eb070f10) at dl-iteratephdr.c:40
#3  0x00007f17ecf75aa1 in _Unwind_Find_FDE () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#4  0x00007f17ecf72183 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#5  0x00007f17ecf73360 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#6  0x00007f17ecf7385e in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#7  0x00007f17ed415d47 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x000055e3287f5205 in ErrorHandler::Throw(RAR_EXIT) ()
#9  0x000055e3287f4ac1 in ComprDataIO::UnpWrite(unsigned char*, unsigned long) ()
#10 0x000055e3287ffa44 in Unpack::UnpWriteData(unsigned char*, unsigned long) ()
#11 0x000055e32880012c in Unpack::UnpWriteBuf30() ()
#12 0x000055e3287fb0cf in CmdExtract::ExtractCurrentFile(Archive&, unsigned long, bool&) ()
#13 0x000055e32880eb3c in ProcessFile(void*, int, char*, char*, wchar_t*, wchar_t*) ()
#14 0x000055e3287e02f8 in extract_rar (
    arch=0x7f17e00b3c40 "..."..., file=0x7f17e00b37d0 "...", arg=0x7) at rar2fs.c:1986
#15 0x000055e3287dd75d in popen_ (entry_p=0x7f17e00b3b40, cpid=0x7f17eb07dabc) at rar2fs.c:748
#16 0x000055e3287e5a29 in rar2_open (
    path=0x7f17e0139190 "...", fi=0x7f17eb07dce0) at rar2fs.c:3875
#17 0x00007f17ed717a40 in fuse_fs_open () from /lib/x86_64-linux-gnu/libfuse.so.2
#18 0x00007f17ed717b22 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#19 0x00007f17ed721f9c in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#20 0x00007f17ed7216c1 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#21 0x00007f17ed71de68 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#22 0x00007f17ecd4b6db in start_thread (arg=0x7f17eb07e700) at pthread_create.c:463
#23 0x00007f17eca7471f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

hasse69 · 2021-07-11T05:10:47Z

What version of libunrar do you use? Looks like an exception in thrown but not picked up and then it hangs.

Also do you know which archive this is? In that case can you provide me a link to where I might be able to download it.
You can send me send the link in private if you wish.

So you use stacked mounts to reach the second level of RAR contents, right?

hasse69 · 2022-04-08T17:21:18Z

And no trace of any stuck processen with 100% load?

milesbenson · 2022-04-08T17:22:53Z

All fine so far :)

hasse69 · 2022-04-09T10:57:07Z

It sounds like the v4 patch could be a candidate to push to master? But I would of course prefer some additional feedback from other users that also have experienced the original sub-process issue before doing so. But the patch does not seem to make it worse at least. @philnse any chance you could give the v4 patch a try?

m-gupta · 2022-04-11T17:45:38Z

patch165v4_b2.patch.txt also works for us in ChromeOS.

hasse69 · 2022-04-11T18:03:26Z

@m-gupta Interesting, since that patch does nothing related to the C++ exception issues I faced. Then I really do not understand what is the issue here since the part of the code that is now changed has been working exactly the same for years.

Anyway, please confirm that the clean v4 patch works because the b2 patch is not a candidate to be pushed to master.

m-gupta · 2022-04-11T18:16:07Z

issue165v4.patch.txt also works if that is the clean one.

I have no idea why this fixes the problem we saw except that it does.

newkarn · 2022-04-14T13:20:28Z

Updating metadata (scanning through folders) in plex is much faster with issue165v4.patch.txt for me. This is compared to issue165v3.patch.txt Thanks!
Edit: I have not made any benchmarks. But it is noticeable.

hmodes · 2022-04-17T17:04:49Z

Chiming in that I've been running issue165v4.patch.txt for a week and it has solved the plex issue for me as well. Thanks!

hasse69 · 2022-04-18T07:14:10Z

Chiming in that I've been running issue165v4.patch.txt for a week and it has solved the plex issue for me as well. Thanks!

I think it would be appropriate now that the patch is merged to master. I have received no indications that the situation has become worse by applying it and the option to revert if it does is still there.

Under some conditions the reader thread responsible for carrying data from the child process to the I/O buffer may fail to terminate at close and file system thread gets blocked waiting for join to complete. Terminate the reader thread using a control message rather then using the brute force call to pthread_cancel(). Additional updates made in this patch to increase robustness include: - perform dry-run extraction outside of child process and before it is spawned Note that the majority of the changes done as part of this patch only affects extraction of compressed (-m1 and above) and/or encrypted archives. Resolves-issue: #165 Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>

hasse69 · 2022-04-18T07:35:04Z

A patch has now been pushed to master. But I will leave this issue open for a while to hopefully receive some additional feedback that master is now stable before closing this.

poltergaiist · 2022-04-22T06:35:55Z

A patch has now been pushed to master. But I will leave this issue open for a while to hopefully receive some additional feedback that master is now stable before closing this.

Hi,
been running since push no problems at all.

Thank you for your dedication!

hasse69 · 2022-04-24T11:35:49Z

@milesbenson out of curiosity, would it be possible for you to try out the below patch on top of master/HEAD?

iob.patch.txt

milesbenson · 2022-04-24T12:33:57Z

Checked on a smaller rclone mount, all fine when cache was fully populated - fast scanning.

poltergaiist · 2022-04-26T05:07:59Z

Getting a lot of Transport endpoint is not connected at the moment...

hasse69 · 2022-04-26T07:02:30Z

Well, good call to leave this soaking for a while then I guess. But we need more input. Can only assume there is a crash in rar2fs and then some sort of signature/trace is needed to follow it up.

You did not apply the last patch I posted by any chance? That was only something I wanted to test to see if it had any negative impact since it is supposed to improve the performance when multiple files are being extracted at the same time.

If this crash is now a result of the last patch pushed to master then I guess it again needs to be reverted.

poltergaiist · 2022-04-26T16:04:31Z

Well, good call to leave this soaking for a while then I guess. But we need more input. Can only assume there is a crash in rar2fs and then some sort of signature/trace is needed to follow it up.

You did not apply the last patch I posted by any chance? That was only something I wanted to test to see if it had any negative impact since it is supposed to improve the performance when multiple files are being extracted at the same time.

If this crash is now a result of the last patch pushed to master then I guess it again needs to be reverted.

Hi!
No I was running 165v3. Now master is crashing 3rd time already today.

I've might have done some errors, re-runned the rar2fs/unrar installations, I'll get back to you.

/BR

hasse69 · 2022-04-26T21:15:01Z

And for what it is worth, never use 165v3, we already know that is severely broken. Instead use master/HEAD for any testing.

hmodes · 2022-04-26T21:46:03Z

FWIW I have not had any issues so far on issue165v4.patch.txt - updating to master now and will let that bake to double-check

hasse69 · 2022-04-28T16:46:58Z

@Tattarn any updates here? Still experiencing problems?

poltergaiist · 2022-04-28T16:55:29Z

@Tattarn any updates here? Still experiencing problems?

No problem! Everything has been running smooth with master 2+ days. I somehow broke it by using an too old unrar I had lying around. Compiled with 6.0.3 and has been working perfect since!

hmodes · 2022-04-29T11:58:17Z

Stable on master here as well since updating from also-stable patch v4

hasse69 · 2022-04-29T15:18:44Z

Thanks all for the feedback/support and patience. I believe we finally reached the point in which this issue can be closed.

milesbenson · 2022-05-06T11:11:37Z

I just ran into the issue that scanning in Plex was slow again. Checked ls -R on the mount and could see same slow behaviour, so cache seems to have dropped. Mounting with rw,allow_other,warmup=10 --seek-length=1
Any options when mounting how long a dir cache shall be persistent? Or why did the cache not remain? I mounted on Apr18 and have added some folders meanwhile.

But: No stuck processes so all fine

Edit: NVM, just found #170 so it happened due to adding folders. I will run ls -R through cron from time to time

skkii · 2022-05-06T18:36:46Z

Thanks all for the feedback/support and patience. I believe we finally reached the point in which this issue can be closed.

Indeed. Just for the records: running latest patch since a few months under heavy usage without any issues. Thanks @hasse69 !

niklasholm · 2022-07-31T03:42:14Z

@hasse69 Thanks for all your hard work, much appreciated! Just curious why this fix (and others) aren't part of a new patch release yet?

hasse69 · 2022-07-31T09:57:15Z

It is a pending task indeed.

hasse69 added Priority-High and removed Priority-Medium labels Apr 18, 2022

hasse69 closed this as completed Apr 29, 2022

Creating sub-processes using 100% CPU when content is added #165

Creating sub-processes using 100% CPU when content is added #165

Comments

philnse commented Jun 28, 2021 • edited Loading

hasse69 commented Jun 28, 2021

hasse69 commented Jun 28, 2021

philnse commented Jun 29, 2021

philnse commented Jun 29, 2021 • edited Loading

hasse69 commented Jun 29, 2021 • edited Loading

philnse commented Jun 29, 2021

hasse69 commented Jun 29, 2021

philnse commented Jun 30, 2021 • edited Loading

hasse69 commented Jun 30, 2021 • edited Loading

philnse commented Jun 30, 2021

hasse69 commented Jul 3, 2021 • edited Loading

philnse commented Jul 3, 2021

philnse commented Jul 3, 2021

hasse69 commented Jul 3, 2021

philnse commented Jul 5, 2021 • edited Loading

hasse69 commented Jul 5, 2021

hasse69 commented Jul 5, 2021 • edited Loading

philnse commented Jul 5, 2021 • edited Loading

hasse69 commented Jul 5, 2021

philnse commented Jul 5, 2021

hasse69 commented Jul 5, 2021

philnse commented Jul 5, 2021

hasse69 commented Jul 9, 2021

philnse commented Jul 10, 2021

hasse69 commented Jul 10, 2021

hasse69 commented Jul 10, 2021 • edited Loading

philnse commented Jul 10, 2021

hasse69 commented Jul 10, 2021

philnse commented Jul 10, 2021

hasse69 commented Jul 11, 2021 • edited Loading

hasse69 commented Apr 8, 2022

milesbenson commented Apr 8, 2022

hasse69 commented Apr 9, 2022 • edited Loading

m-gupta commented Apr 11, 2022

hasse69 commented Apr 11, 2022

m-gupta commented Apr 11, 2022

newkarn commented Apr 14, 2022 • edited Loading

hmodes commented Apr 17, 2022

hasse69 commented Apr 18, 2022

hasse69 commented Apr 18, 2022

poltergaiist commented Apr 22, 2022

hasse69 commented Apr 24, 2022

milesbenson commented Apr 24, 2022

poltergaiist commented Apr 26, 2022

hasse69 commented Apr 26, 2022 • edited Loading

poltergaiist commented Apr 26, 2022 • edited Loading

hasse69 commented Apr 26, 2022

hmodes commented Apr 26, 2022

hasse69 commented Apr 28, 2022

poltergaiist commented Apr 28, 2022

hmodes commented Apr 29, 2022

hasse69 commented Apr 29, 2022

milesbenson commented May 6, 2022 • edited Loading

skkii commented May 6, 2022

niklasholm commented Jul 31, 2022

hasse69 commented Jul 31, 2022

philnse commented Jun 28, 2021 •

edited

Loading

philnse commented Jun 29, 2021 •

edited

Loading

hasse69 commented Jun 29, 2021 •

edited

Loading

philnse commented Jun 30, 2021 •

edited

Loading

hasse69 commented Jun 30, 2021 •

edited

Loading

hasse69 commented Jul 3, 2021 •

edited

Loading

philnse commented Jul 5, 2021 •

edited

Loading

hasse69 commented Jul 5, 2021 •

edited

Loading

philnse commented Jul 5, 2021 •

edited

Loading

hasse69 commented Jul 10, 2021 •

edited

Loading

hasse69 commented Jul 11, 2021 •

edited

Loading

hasse69 commented Apr 9, 2022 •

edited

Loading

newkarn commented Apr 14, 2022 •

edited

Loading

hasse69 commented Apr 26, 2022 •

edited

Loading

poltergaiist commented Apr 26, 2022 •

edited

Loading

milesbenson commented May 6, 2022 •

edited

Loading