JabRef version 4.3.1 on Ubuntu 18.04
When JabRef is started without enough remaining inotify instances, it will die silently (for the user).
Steps to reproduce the behavior:
- Exit JabRef with a bib file open.
- In Ubuntu, set the max_inotify_instances too low
echo 1 > /proc/sys/fs/inotify/max_user_instances
- Start JabRef
- JabRef does not start. Only the logs show an error, but not the root cause.
The root cause in my scenario is, that the file cannot be watched by the DefaultFileUpdateMonitor, because there are not enough inotify instances left.
The DefaultFileUpdateMonitorrealizes this, but only logs it on the debug level. As this exception affects user experience, it should be made more prominent.
I will provide a first pull request shortly, which at least logs the exception on the error level. but IMO the user should at least be informed to look at the logs.
Log File
13:39:09.336 [AWT-EventQueue-0] INFO org.jabref.logic.importer.OpenDatabase - Opening: /home/someuser/references.bib
File: grouptree.fxml not found, attempting with camel case
File: grouptree.css not found, attempting with camel case
13:39:10.718 [AWT-EventQueue-0] ERROR org.jabref.FallbackExceptionHandler - Uncaught exception occurred in Thread[AWT-EventQueue-0,6,main]
java.lang.NullPointerException: null
at sun.nio.fs.UnixPath.register(UnixPath.java:893) ~[?:1.8.0_201]
at sun.nio.fs.AbstractPath.register(AbstractPath.java:104) ~[?:1.8.0_201]
at org.jabref.gui.util.DefaultFileUpdateMonitor.addListenerForFile(DefaultFileUpdateMonitor.java:73) ~[jabref-4.3.1.jar:?]
at org.jabref.gui.collab.DatabaseChangeMonitor.lambda$new$0(DatabaseChangeMonitor.java:40) ~[jabref-4.3.1.jar:?]
at java.util.Optional.ifPresent(Optional.java:159) ~[?:1.8.0_201]
at org.jabref.gui.collab.DatabaseChangeMonitor.<init>(DatabaseChangeMonitor.java:38) ~[jabref-4.3.1.jar:?]
at org.jabref.gui.BasePanel.<init>(BasePanel.java:241) ~[jabref-4.3.1.jar:?]
at org.jabref.gui.JabRefFrame.addTab(JabRefFrame.java:1604) ~[jabref-4.3.1.jar:?]
at org.jabref.gui.JabRefFrame.addParserResult(JabRefFrame.java:1304) ~[jabref-4.3.1.jar:?]
at org.jabref.JabRefGUI.openWindow(JabRefGUI.java:138) ~[jabref-4.3.1.jar:?]
at org.jabref.JabRefGUI.<init>(JabRefGUI.java:67) ~[jabref-4.3.1.jar:?]
at org.jabref.JabRefMain.lambda$start$1(JabRefMain.java:128) ~[jabref-4.3.1.jar:?]
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) ~[?:1.8.0_201]
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) ~[?:1.8.0_201]
at java.awt.EventQueue.access$500(EventQueue.java:97) ~[?:1.8.0_201]
at java.awt.EventQueue$3.run(EventQueue.java:709) ~[?:1.8.0_201]
at java.awt.EventQueue$3.run(EventQueue.java:703) ~[?:1.8.0_201]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_201]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) ~[?:1.8.0_201]
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) ~[?:1.8.0_201]
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) [?:1.8.0_201]
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) [?:1.8.0_201]
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) [?:1.8.0_201]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) [?:1.8.0_201]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) [?:1.8.0_201]
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) [?:1.8.0_201]
JabRef version 4.3.1 on Ubuntu 18.04
When JabRef is started without enough remaining inotify instances, it will die silently (for the user).
Steps to reproduce the behavior:
echo 1 > /proc/sys/fs/inotify/max_user_instancesThe root cause in my scenario is, that the file cannot be watched by the
DefaultFileUpdateMonitor, because there are not enough inotify instances left.The
DefaultFileUpdateMonitorrealizes this, but only logs it on the debug level. As this exception affects user experience, it should be made more prominent.I will provide a first pull request shortly, which at least logs the exception on the error level. but IMO the user should at least be informed to look at the logs.
Log File