$ ./bitcoind -daemon=1 Bitcoin server starting $ ./bitcoind -daemon=1 Bitcoin server starting < ??? $ ./bitcoind -daemon=0 Error: Cannot obtain a lock on data directory /home/gmaxwell/.bitcoin. Bitcoin Core is probably already running.
I assume we’re daemonizing early enough to eat the error output… maybe it would be possible to daemonize later? errors like the fact that it’s not starting would be useful.
The most straightforward solution would be to make sure that all messages that go to stderr/stdout also go to the log.
Demonizing later would need imply splitting up AppInit2, which is risky (threads being created before/after fork, network sockets, etc), and in many cases the standard output may simply be ignored anyhow.
Demonizing later would need imply splitting up AppInit2
Although for this specific message it would be easy, as it is the first thing after basic sanity checks and parameter interaction.
Although for this specific message it would be easy, as it is the first thing after basic sanity checks and parameter interaction.
You could say this was an underestimation. This is the code responsibile for the datadir locking:
0 static boost::interprocess::file_lock lock(pathLockFile.string().c_str());
1 if (!lock.try_lock()) {
2 return InitError(strprintf(_("Cannot obtain a lock on data directory %s. %s is probably already running."), strDataDir, _(PACKAGE_NAME)));
3 }
If this is done before forking, then one side of the fork will release the lock on exit, the other side will try to hold on to it until exit. So effectively the lock is released immediately. This seems inherent in the boost::interprocess::file_lock implementation: changing the pointer lifespan of the object does not affect this behavior. Apparently the lock is not inherited on forking.
Labels
Linux/Unix