Linux fopen() mistery. Help required.

[kalbi]

Hello!

I'm having problems with fopen() call in Linux.

I have shared library (created by myself) that implements some file operations:
Code:

int lib_func(char* file_name) {
...
  fd = fopen(file_name, "r");
  if(!fd) {... exit with error ...}
...
  do something useful using fd
...
  fclose(fd);
...
}

Also I have two programs (pr1 and pr2) that use that library and they call lib_func(): lib_func("/dir/dir/file");

Here is the mystery:
- if I run pr1 from command line, lib_func() is called successfully and file is accessed as required;
- if I run pr2 as daemon, lib_func() is called but fopen() fails with ERRNO=2 (No such file or directory).
How can I fix it to run with pr2?

What I have checked so far:
1. I start pr1 and pr2 strictly in different times (no simultaneous running).
2. File in question exists (I can view it, copy it, delete it from shell).
3. Path to file is absolute.
4. No compile warnings/errors.
5. pr2 is in userspace.
6. Both processes are running from root user and have rights for the file access (777).
7. SELinux is in permissive mode (no effect on system operation).
8. No other process is blocking the file.
Update:
9. Changing to open() system call (instead of fopen()) has no effect. Still, file cannot be opened.

Any ideas?

[dijetlo]

is pr1 closing the file cleanly? Are you following programming practices and checking for the file open/closed pointers at the end of each file operation?
It sounds like your PR1 is locking the file while it's in residence in the memory and your part two can't get a hook in it. Have you tried runng part two without calling PR1?

[kalbi]

is pr1 closing the file cleanly? Are you following programming practices and checking for the file open/closed pointers at the end of each file operation?

pr1 is closing cleanly. Actually, pr1 is just test program to check why pr2 does not work with that file.

It sounds like your PR1 is locking the file while it's in residence in the memory and your part two can't get a hook in it. Have you tried runng part two without calling PR1?

Sure, I've tried different combinations. Since pr1 was written just for debugging of pr2, pr1 is not executed in real situations.

[gerard4143]

Could you post your code....

[dijetlo]

pr1 is closing cleanly. Actually, pr1 is just test program to check why pr2 does not work with that file.

So your script when running as a service can't access the file but while running as an executable it can?

Sure, I've tried different combinations. Since pr1 was written just for debugging of pr2, pr1 is not executed in real situations.

It sounds like the problem may be with the permissions the service inherits.
Or we could venture down the Avenue offered by our esteemed associate and you could post the code.
The path forks here.

[kalbi]

So your script when running as a service can't access the file but while running as an executable it can?

Kind of. The service is started from rc.d script.
But other app can access that file from command line.

I can try to put that test app into the script and check if it works.

It sounds like the problem may be with the permissions the service inherits.
Or we could venture down the Avenue offered by our esteemed associate and you could post the code.
The path forks here.

OK. Tomorrow I will check permissions of the script.
Also I will post code of library function tomorrow.

[kalbi]

Issue solved!
Problem was in composing the argument char* file_name for library call in daemon and test function.
Both of them allocated memory dynamically (malloc) but allocated one byte more than required. As a result, an extra byte was:
- \0 for pr1 and everything worked normally as it is string terminator;
- decimal 16 for pr2 and pr2 failed. That spare symbol is not printed - that confused me.
Only byte-by-byte comparison of file names showed the problem.

dijetlo, thank you for your time to help me.

[dijetlo]

You shoulda listened to Gerard...still my pleasure and thanks for explaining the final solution.