mesh
is there any concern about keeping Destination objects around in memory?
mesh
I guess the keys have to be kept around to de/crypt the incoming and outgoing data
mesh
though techniques like bleepingcomputer.com/news/security/openssh-to-keep-private-keys-encrypted-at-rest-in-ram are interesting
zlatinb
it's very hard for me to test with embedded router unless it's the latest stable from mavencentral, so I'll try to work around for now
zzz
still don't completely understand though
zzz
but I decided the fix was worthwhile in any case
zzz
the clock has to be an hour off and then get fixed, all in a race, for that to happen
zlatinb
hmmm doubt it
zzz
yeah thats why its a headscratcher
zlatinb
but I see another problem - why is GracefulShutdown waiting indefinitely if the shutdown is not graceful?
zzz
I think that's just to shift the shutdown to another thread so the console will return after the POST when the user hits the button
zlatinb
yeah I have a problem with that - the Graceful ShutdownHook thread never exits so neither does the jvm
zzz
because you set killVMOnEnd to false?
zlatinb
no, haven't touched that
zlatinb
(didn't know it existed tbh)
zzz
what are you calling to shut it down?
zlatinb
Router.rebuildNewIdentity calls Router.finalShutdown
zzz
finalShutdown() calls Runtime.exit()
zzz
unless killVMOnEnd is false
zlatinb
right, and that launches the hooks, but the hooks wait()'s indefinitely
obscuratus
I've also been intermittently seeing the routers spontaneously rebuilding identities on startup while testing the latest releases on my testing network.
obscuratus
Seems to happen more often when the system is busy or congested.
zzz
the logs should tell you why
obscuratus
Similar errors as listed above by zlatinb. Invalid store attempt, and thinks it is unreachable.
zzz
interesting
obscuratus
I was just about to restart a few routers. Let me see if I can reproduce it.
zzz
zlatinb, at the top of rebuildNewIdentity() we remove the shutdown hook
zlatinb
jstack disagrees :)
zlatinb
that's the gracefulShutdownDetectory actually
zlatinb
hold on this could be completely unrelated
zlatinb
oh, just reproduced it
zlatinb
outside of muwire
zlatinb
are you sure the RI gets "touched" before the Republisher runs?
zlatinb
cause it seems like if i2p has been down for more than an hour it will happen all the time
zlatinb
on a firewalled machine at least
obscuratus
I don't have a reliable reproducer. I was just assuming I was seeing these because I was using builds with SSU2.
zlatinb
no, I now realize it's been happening many times since I firewalled my system
zlatinb
I use runPlain and if the router has been down for a while I always have to run it twice
zlatinb
it's just that today I decided to look at the logs
zlatinb
running with a wrapper would hide it from you
zlatinb
should be easy to test, change ROUTER_INFO_EXPIRATION_INTRODUCED in KademliaNetworkDatabaseFacade to something small then shut down i2p and wait that long
obscuratus
I've noticed that when I shut down a router that thinks it's in a firewalled state, it saves that information to router.config.
obscuratus
Or, at least for IPv6
dr|z3d
zzz: Clock skift ?
dr|z3d
> log.logAlways(Log.WARN, "Clock skift, rebuilding router info: " + DataHelper.formatDuration(diff));