[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118916#comment-17118916
]
Radim Rehurek commented on TIKA-3103:
-
We do use Linux, so your option 1) would work.
We ended up implementing something similar to your option 2) on our end. We
periodically look for tesseract processes and set RLIMIT on them, to kill any
orphans.
This is a hack of course, but seems to do the job, for the time being.
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs are critical for us. What's the best way to avoid them?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113295#comment-17113295
]
Tim Allison commented on TIKA-3103:
---
I can think of two ways to ensure that tesseract shutsdown if the parent dies.
1) only on linux, kick off tesseract with {{timeout}}
2) spawn a child java process to monitor it, which means we'd spawn two
processes (prob happens w timeout too?)
It looks from the source code like we could do a bit more to make sure that
tesseract is killed if the parent process dies.
Can anyone think of better options?
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs are critical for us. What's the best way to avoid them?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112635#comment-17112635
]
Tim Allison commented on TIKA-3103:
---
>Maybe it's something to do with concurrency in the Tika server instead?
I test it regularly with around 8 concurrent requests. That shouldn't be a
problem. I don't often work with tesseract, tho...
> I'm not sure. Where do I find out?
Both the child and parent should log when there's a restart.
I agree about expected behavior. From an implementation standpoint, though, if
the child process is killed, even if we add a shutdown hook to kill tesseract,
there's no guarantee that it will be executed.
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs are critical for us. What's the best way to avoid them?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112356#comment-17112356
]
Radim Rehurek commented on TIKA-3103:
-
I take it back. There are still Tesseract processes that have been up for 4+
minutes, even with `tika-config.xml` and `X-Tika-OCRTimeout` set to 30:
!Screen Shot 2020-05-20 at 17.30.04.png!
I don't understand how this works.
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
> Attachments: Screen Shot 2020-05-20 at 17.28.45.png, Screen Shot
> 2020-05-20 at 17.30.04.png
>
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs are critical for us. What's the best way to avoid them?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112301#comment-17112301
]
Radim Rehurek commented on TIKA-3103:
-
FYI, in case anyone hits this in the future: setting the 'X-Tika-OCRTimeout'
request header also works.
This seems preferable to tika-config.xml because more flexible.
So we have a workaround now but let me keep this ticket open. I don't think the
above should be the "default" behaviour; as a user I expect the Tika child to
clean up after itself, even when it's killed via a timeout.
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs are critical for us. What's the best way to avoid them?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112161#comment-17112161
]
Radim Rehurek commented on TIKA-3103:
-
I confirm reducing the `timeout` Tesseract parameter to 30 fixed the `/tmp`
mess. There's only one Tika file now, which seems expected:
{{root@d989fb760c24:/tmp# ll}}
{{-rw--- 1 root root 16 May 20 12:52
tika-server-child-process-mmap-135988666400898895}}
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> should have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs I critical for us. What's the best way to avoid these issues?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112157#comment-17112157
]
Radim Rehurek commented on TIKA-3103:
-
Thanks for the quick response Tim.
> {{apache-tika-12291680472524021463.tmp}} looks like temp files that Tika
>creates. Can you tell which file type these are?
The input files are all XLSM and PDF. Not sure which relates to
`{{apache-tika-12291680472524021463` in particular.}}
> {{TIKA_streamstore_11144988934311367241.tmp}} does not look like a temp file
>from Tika.
I believe it is. Seems like a duplicate of
https://issues.apache.org/jira/browse/TIKA-2903
> On the zombie processes, in looking at the source code, we do have a timeout
> on tesseract at least, but, right, that won't trigger if the java process
> dies.
Aha. So the child timeout (default: two minutes) must be longer than the
Tesseract timeout (also two minutes by default) to avoid zombies. I reduced the
`org.apache.tika.parser.ocr.TesseractOCRParser.timeout` to 30 in
`tika-config.xml`, to prevent race conditions. Let's see if that helps.
> How often are you getting restarts of the child process?
I'm not sure. Where do I find out?
> Finally, to confirm, you do want tesseract to run, right?
Correct.
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> should have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs I critical for us. What's the best way to avoid these issues?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112071#comment-17112071
]
Tim Allison commented on TIKA-3103:
---
When you see that tesseract is orphaned, did the child process restart?
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> should have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs I critical for us. What's the best way to avoid these issues?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TIKA-3103) Tesseract fails to respect timeouts and clean up after itself
[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112067#comment-17112067
]
Tim Allison commented on TIKA-3103:
---
In reverse order,
{{apache-tika-12291680472524021463.tmp}} look like temp files that Tika
creates. Can you tell which file type these are? Is there a specific parser
that is failing to clean up after itself?
{{TIKA_streamstore_11144988934311367241.tmp}} does not look like a temp file
from Tika. Are you sure your application is cleaning these up?
On the zombie processes, in looking at the source code, we do have a timeout on
tesseract at least, but, right, that won't trigger if the java process dies.
We do not have timeouts on the Python processing. Do you know if you have the
python image fixers installed? Are you triggering these, by chance?
How often are you getting restarts of the child process?
> Tesseract fails to respect timeouts and clean up after itself
> -
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
>Affects Versions: 1.24.1
>Reporter: Radim Rehurek
>Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /opt/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
>
> Two undersirable things happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> should have finished.
> These processes show in _top_ as "tesseract" (OCR) and consume all CPU cores
> at 100%.
> They eventually die (or finish?) but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{…}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs I critical for us. What's the best way to avoid these issues?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
