Question

I’m having a strange issue that I think I have a workaround for, but I’m trying to do a root cause analysis on.

I’ve been developing an application that runs on an embedded version of Ubuntu 10.04 LTS. When the application starts up, it reads in a config file off of an SD card, initializes a few classes, starts a logger which writes to the SD card, and then proceeds with it’s operation. During development, it has been running fine when I start it manually through an SSH terminal.

I’ve recently been experimenting with having the application start automatically when the OS starts up. I have a script in init.d which does just that. However, I noticed that no log files are being generated now. I figured out it’s not a problem with the SD card not being available because the config file gets read properly on startup, but an error is thrown when I attempt to open the log file for writing using fopen.

// Open the file
mLogFile = fopen(filename, "wb");
if(mLogFile == NULL)
{
    printf("Error opening Log File [%d].\n", lnRetval);
    return -1; //File couldn't be opened
}

I assumed it was just a permissions problem, but I can’t understand why it doesn’t work when I automatically start the software versus running it manually in a terminal. Furthermore, I can’t understand why the config file gets read in properly but this file can’t be opened.

The only difference I could see was that the config file reading is done using fstreams, while the logger is using C file I/O. So I experimented by placing the following code directly before the fopen call above (/home/root/etc is where the SD card is mounted).

std::ofstream out("/home/root/etc/log/testlog.log");
out << "I can write using fstreams.\n";
out.close();

That worked and generated the file when started through init.d. Now I’m completely stumped. Why does ofstream work and not fopen? Is there something fundamentally I’m missing?

Thanks in advance.

Answer 1

Your question does not provide enough information to answer, but the general approach to problems like this should be to run the program (in both forms) under strace and compare the sequence of syscalls made. That should quickly reveal what’s happening differently. I suspect you’ll just find the contents of filename are invalid…