0
Under review

Ubooquity crashes regularly

Tobias Andersson 3 years ago updated by Michael Menzie 2 years ago 23

20160919 23:32:00 [pool-1-thread-16] WARN com.ubooquity.e.e - Interrupted while sending response (perhaps the client stopped the download) - java.net.SocketException - Software caused connection abort: socket write error


Gets about 30 of these and then it crashes. Every 48 hours.

Running it on Win 10 with allocated 1024 RAM. Works flawlessly otherwise.

Not running a scan or anything when it happens. And the program is still responsive. It's just not able to be reached from any of my units. Not until I restart the program.

I've reported a bug lately (Too many open files creates a crash) where I explain my suspicions about a very similar problem; in short, I think there is a file-descriptor leak: ubooquity doesn't seem to close the files properly after reading them (mainly, the thumbnails), so after a long period of usage, ubooquity exeed its OS-defined allocation, and this causes the web-server to crash...

it's very possible those two bugs are the same.

I'll if I can force a scheduled restart on my system (it's a synology NAS, I'm not quite sure how I can do that at the moment)

I think I'm experiencing the same thing, though I'm not seeing anything in the log file that would indicate what's happening. The Java applet runs and seems okay, but Ubooquity is not accessible on localhost:2202 or anywhere else for that matter. Closing and reopening Ubooquity does the trick, but it does happen fairly frequently, maybe every other day or so.


Not sure what additional info I can provide to help reproduce the issue...

It's always behaved like this for me. I always assumed it was because my collection was so large. About 50k+ comics. Even loaded a remote desktop app on my tablet so I could bounce it when it hangs.

I have nowhere near that number of items in the db... Either way it doesn't sound like something that is supposed to happen.

I've encountered similar issues several times.

I can see similar logs in ubooquity:

20160929 08:43:52 [pool-1-thread-20]  WARN com.ubooquity.e.e - Interrupted while sending response (perhaps the 
client stopped the download) - java.net.SocketException - Broken pipe

When the crash happens, the ubooquity process itself looks OK from command line: it's still running (on my synology NAS), java is still OK, it's only the web interface that becomes unresponsive: I get "timed out" error pages when this happens

I suspect there is something wrong within the embedded web server that ubooquity uses: it doesn't handle well parallel requests. For example, when I load a new page [I've set my pages to display 24 items] it loads the first 20 items extremely fast, but for some reason, the last 4 items take forever to load. This is systematic: the first 20 are fast, the remaining 4 are extremely slow.

I suspect the embedded-web server doesn't handle web parallel request, or has limited capacity... but when I reload new pages too fast either to refresh those last 4 item, or to go the next page, the number of items that the server doesn't send accumulates, and after a while, this crashes the web server. This would explain why ubooquity still operates, but we don't see pages anymore: the web server (and only it) has crashed.

It would be nice if ubooquity could detect when the web server crash so it can relaunch it; at least ubooquity could dump a file that our operating system could detect and use to trigger a restart of ubooquity

I just can't figure out why 20 is OK and 24 is bad. Anyway: for now, I changed my settings to 20 items per page, and hopefully, I won't be getting those errors

Hmm, I think this might be a separate issue. For me, nothing was loading on the webpage, no matter how long I waited.

+1

Hi,

i've had the same problems on windows server 2012 R2 with the newest java. My current workaround is to restart the server periodially with my batch script:


:loop
start "Ubooquity" C:\ProgramData\Oracle\Java\javapath\java.exe -jar "C:\Program Files\Ubooquity\Ubooquity.jar"
timeout /t 43200 >null
FOR /F "skip=1" %%a IN ('wmic process Where "CommandLine Like '%%Ubooquity.jar%%'" get ProcessId') DO (
FOR /F "delims=" %%b IN ("%%a") DO taskkill /f /pid %%b
)
timeout /t 7 >null
goto loop


This script starts a server, waits 12 hours (43200 seconds), then kills everything that sounds like Ubooquity.jar and begins again.

Just had to go and restart it again; might have to cook up something equivalent to that but for OSX. Again, there's literally nothing in the log that indicates anything is wrong.

I'm running it in 2012 R2 as a service, so it's just as easy for me to create a scheduled task to bounce the service.

Uhm Scott that's very much cooler than my batchscript - please give me a hint: how did you install Ubooquity as a service?

+1

I've got a piece of freeware called ServiceEx.exe. You create an ini file with command line parameters and it creates a service with the name of the ini. For example, my ubooquity ini looks like:


[ServiceEx]
ServiceExeFullPath = "C:\ProgramData\Oracle\Java\javapath\java.exe"
; program arguments to be sent to executable
options =-jar e:\Ubooquity\Ubooquity.jar --webadmin --headless --workdir e:\Ubooquity
; can program interact with desktop [true | false] (default: true)
desktop = false
; start type (valid values: Auto Manual Disabled) (default: auto)
Start=Auto
; start the service upon installation [true | false] (default: no)
StartNow=true

This creates a ubooquity service that is set to automatic and then starts it. Once the service has been created, you're off to the races. The command line basically has two switches. serviceex.exe install <filename.ini> or serviceex.exe remove <filename.ini>. Great little piece of freeware for a windows admin, but it can be a little tough to track down.


Heyya,

i had no luck with serviceex (says it was 16 bit; didnt find any other version), but i used "nssm" to create a service and now it works great. Thanks for the idea!

Posting this in the hopes that it will help others running into similar issues...


After Ubooquity has been running for some time, both the main Ubooquity page and the admin page hang while loading. Turning off automatic scans and scanning on startup dont help. When I log into the (Windows 10) server I need to shut down Ubooquity and restart it for the pages to load normally again.


I tried using nssm and was able to create a service using the following configuration (change the arguments paths to suit your environment):


Path=

C:\ProgramData\Oracle\Java\javapath\java.exe

Startup Directory=

C:\ProgramData\Oracle\Java\javapath

Arguments=

-jar c:\Ubooquity\Ubooquity.jar --webadmin --headless --workdir c:\Ubooquity

i tried this and it is not working for me at all.i have NSSM and my ubooquity is in c:\ubooquity and i have the path, startup directory, and arguments just like you have them it does not work.the service says its started but in the logs there is nologs entries showing it started. and the web pages "library/admin" are not reachable. i am on ubooquity version 2.1.1

got it solved. --webadmin is no longer a usable term. it alone is what was the issue. after running ubboquity with the --help command i saw that it was now --remoteadmin. so after i  changed the arguments in my NSSM service to -jar c:\Ubooquity\Ubooquity.jar --remoteadmin --headless --workdir c:\Ubooquity it runs fine now

thank you

+1
Under review

All the problems you describe should of course not happen.


The next version of Ubooquity will replace the old internal server (NanoHTTPD) with something more robust: Jetty.

I hope the problem where Ubooquity is still running but fails to answer requests will be solved by this change.


I hope to release it before the end of 2016 (Jetty is already integrated by there are other feature I want to include).


Exciting! Can you give us a sneak peek at what else is coming in the next version? :)

+3
  • complete rewrite of the web administration interface (and removal of the desktop UI): maintaining two interfaces was taking too much time
  • server side bookmarks to allow device switching in the middle of a book
  • OPDS feed improvement
  • other small improvements and hopefully better performances
+1

Thanks a lot for working hard on this fantastic piece of program!

Thank you! Keep up the excellent work!

Tom's still working on v2.0. Please be patient. :)

+1

I was having similar problems where Ubooquity would crash on a nearly daily basis.  However from at least 2.0 and forward I haven't noticed any issues with it.  Just wanted to mention it in case others had the same experience.  Seems a lot more stable now.  Thanks again for all of your hard work Tom!