C++ Ubuntu not releasing lock on lock file when terminated

Question

I have a C++ script, which checks whether any action has to be done and if so it starts the right processor C++ script. However, since it runs every x minutes it also checks whether the processor isn't still running using lock files.

I use the following function to acquire the lock:

int LockFile(string FileNameToLock) {
    FileNameToLock += ".lock";
    int fd = open(FileNameToLock.c_str(), O_RDWR | O_CREAT, 0666);
    int rc = flock(fd, LOCK_EX | LOCK_NB);
    if (rc || rc == -1) {
        cout << errno << endl;
        cout << strerror(errno) << endl;
        return -1;
        }
    return fd;
    }

The code that is being executed:

[...]
if (LockFile(ExecuteFileName, Extra) == -1) {
    cout << "Already running!" << endl; //MAIN IS ALREADY RUNNING
    //RETURNS ME Resource temporarily unavailable when processor is running from an earlier run
    exit(EXIT_SUCCESS);
    }
if (StartProcessor) { //PSEUDO
    int LockFileProcessor = LockFile("Processor");
    if (LockFileProcessor != -1) {
        string Command = "nohup setsid ./Processor"; //NOHUP CREATES ZOMBIE?
        Command += IntToString(result->getInt("Klantnummer"));
        Command += " > /dev/null 2>&1 &"; //DISCARD OUTPUT
        system(Command.c_str());
        //STARTS PROCESSOR (AS ZOMBIE?)
        }
    }

The first run works well, however when the main script runs again, the lock file returns -1, which means an error occurred (only when the processor is still running). The errno is 11 which results in the error message: Resource temporarily unavailable. Note that this only happens when the (zombie) processor is still running. (However, the main script has already terminated, which should close the file handle?)

For some reason, the zombie keeps the file handle to the lock file of the main script open???

I have no idea where to look for this problem.

SOLVED: see my answer

Answer 1

No, 11 is EAGAIN/EWOULDBLOCK which simply means that you cannot acquire the lock because the resource is already locked (see the documentation). You received that error (instead of blocking behaviour) due to LOCK_NB flag.

EDIT: After some discussion it seems that the problem is due to flock() locks being preserved when subprocessing. To avoid this issue I recommend not using flock() for the lifetime but instead touch-and-delete-at-exit strategy:

1. If file.lock exists then exit
2. Otherwise create file.lock and start processing
3. Delete file.lock at exit.

Of course there's a race condition here. In order to make it safe you would need another file with flock:

1. flock(common.flock)
2. If file.lock exists then exit
3. Otherwise create file.lock
4. Unlock flock(common.flock)
5. Start processing
6. Delete file.lock at exit

But this only matters if you expect simultaneous calls to main. If you don't (you said that a cron starts the process every 10min, no race here) then stick to the first version.

Side note: here's a simple implementation of such (non-synchronized) file lock:

#include <string>
#include <fstream>
#include <stdexcept>
#include <cstdio>

// for sleep only
#include <chrono>
#include <thread>

class FileLock {
    public:
        FileLock(const std::string& path) : path { path } {
            if (std::ifstream{ path }) {
                // You may want to use a custom exception here
                throw std::runtime_error("Already locked.");
            }
            std::ofstream file{ path };
        };

        ~FileLock() {
            std::remove(path.c_str());
        };

    private:
        std::string path;
};

int main() {
    // This will throw std::runtime_error if test.xxx exists
    FileLock fl { "./test.xxx" };
    std::this_thread::sleep_for(std::chrono::seconds { 5 });
    // RAII: no need to delete anything here
    return 0;
};

Requires C++11. Note that this implementation is not race-condition-safe, i.e. you generally need to flock() the constructor but in this situation it probably be fine (i.e. when you don't start main in parallel).

Answer 2

I solved this issue, since the system and fork commands seem to pass on the flock, by saving the command to execute in a vector. Unlock the lock file right before looping the Commands vector and execute each command. This leaves the main with a very tiny gap of running while not locked, but for now it seems to work great. This also supports ungraceful terminations.

[...]
if (LockFile(ExecuteFileName, Extra) == -1) {
    cout << "Already running!" << endl; //MAIN IS ALREADY RUNNING
    //RETURNS ME Resource temporarily unavailable when processor is running from an earlier run
    exit(EXIT_SUCCESS);
    }
vector<string> Commands;
if (StartProcessor) { //PSEUDO
    int LockFileProcessor = LockFile("Processor");
    if (LockFileProcessor != -1) {
        string Command = "nohup setsid ./Processor"; //NOHUP CREATES ZOMBIE
        Command += IntToString(result->getInt("Klantnummer"));
        Command += " > /dev/null 2>&1 &"; //DISCARD OUTPUT
        Commands.push_back(Command);
        }
    }
//UNLOCK MAIN
if (UnlockFile(LockFileMain)) {
    for(auto const& Command: Commands) {
        system(Command.c_str());
        }
    }