Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Linux java shutdown io bug  (Read 1676 times)
0 Members and 1 Guest are viewing this topic.
Offline i30817

Junior Member





« Posted 2012-07-21 23:49:32 »

I've come to suspect there is some kind of shutdown bug at the interface with the operating system on openjdk and shutdownhooks

To be clear i'm not talking about problems from the jdk (there is a hilarious one where if you try to serialize a File that came from a JFileChooser in a shutdownhook it will throw a exception because JFileChooser 'files' are a fake flyweight object that depends on a shutdown hook of the jdk to not leak memory)

I'm talking about the jvm exiting - naturally, by escaping the main or run of all threads - before the buffers are committed to disk - a outputstream.flush() is NOT the same as a disk sync.

When i tried to get the file descriptor of the corresponding fileoutputstream and force the issue with the sync method during shutdown, sometimes i would get a SyncFailedException.

I only really suspect this because actually getting information after a certain point in the shutdown turns impossible - all 'unflushed' 'unsynced' log files start to go nowhere - found this by repeated experimentation and comparing the point where the log stopped making sense - it just disappeared sometimes late in the shutdown

I suspect the shutdown init.d or upstart or systemd or whatever protocol is turning off the discs before the application shutdown hooks flush the data, therefore missing the final 'sync'.
I also suspect the one sure fire way to prevent this (i already optimized what i have to write to disk by performing amortized writes) is to have a init.d|somethingelse script before umount preventing the normal shutdown sequence from going on if it detects the process still in operation and force a sync in the application at the written files in the shutdownhook.



I'm unhappy with this turn of events and i'd like to rant to whoever designed init.d
And oh, i'd like systemd to do better if it can
Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2012-07-22 01:03:03 »

It sounds to me like some dependencies are screwed up ... nothing should be deactivating the devices until all filesystems on it are unmounted, and those shouldn't unmount until every process is finished.

I don't think SysVInit can even control devices like that, but upstart and systemd can.  What distribution are you using?
Offline i30817

Junior Member





« Reply #2 - Posted 2012-07-22 01:17:33 »

Ubuntu whatever the latest.


Here is the 'guilty' code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
    public static void writeObjects(Path objectLocation, Serializable... obj) throws IOException {
        FileOutputStream st = new FileOutputStream(objectLocation.toFile());
        try (ObjectOutputStream s = new ObjectOutputStream(new BufferedOutputStream(st, 20000))) {
            for (Serializable a : obj) {
                s.writeObject(a);
            }
            s.flush();
           
            int counter = 0;
            while (counter++ < 5) {
                try {
                    st.getFD().sync();
                    break;
                } catch (SyncFailedException e) {
                }
            }
        }
    }

I added the sync and changed from Files.newOutputStream to fileoutputstream recently, not even sure if it helps (i know syncfailedexception happens sometimes because 'paradoxically' i was able to sometimes write the exception to the log i deleted since, if i tried the sync)

Also the the jvm is not being SIGKILL'ed (or halt'ed) - it's far too little time, i looked at the killing code in the init.d scripts in sendsigs and it has a 10 seconds maximum tolerance by checking for processes every second. Long before that happens the shutdown is progressing and the jvm dies a natural death.

I would expect umounting would flush the goddamned operating system buffers to disk.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline i30817

Junior Member





« Reply #3 - Posted 2012-07-22 01:29:18 »

Actually they have a sync just before

I don't know man... this sucks, it's a bug i know it.
edit: the code displayed had a sync BEFORE sending SIGTERM, ie: the signal that starts the shutdownhooks.

umounting is in another place than sendsigs

edit2: actually, cat /etc/init.d/umountfs | grep sync
gives nothing and the actual command seems to be
fstab-decode umount -f -r -d $REG_MTPTS


actually pretty suspicious of the force, but i don't really know anything about umount
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (29 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (39 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (36 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!