I am developing a backup utility and I am getting the error:
Too many open files in system
after it runs for a while. The error is returned by stat().
Since I am not actually opening any files (fopen()), my question is if any of the following functions (which I am using) take up a file descriptor, and if so, what can I do to release it?
getwd()
chdir()
mkdir()
stat()
time()
The functions you listed are safe; none of them return anything that you could "close".
To find out more, run the command lsof -p + PID of your backup process. That will give you a list of files which the process has opened which in turn will give you an idea what is going on.
See: lsof manual page.
Related
In AIX,
is there any command or way to verify, before unmounting a file system, is there any open files from that file system?
Or any method to verify if the filesystem is busy before attempting an unmount operation in AIX?
I verified fuser and lsof commands. lsof is not a native command and fuser does not report all open files on the file system.
Are you sure about this "fuser does not report all open files"?
According to the man page, it should:
"The fuser command lists the process numbers of local processes that use
the local or remote files specified by the File parameter. For block
special devices, the command lists the processes that use any file on
that device."
I have a win32 program that I've supported for years. I just noticed that on W7 if it attempts to open/write/close a file directly in C:/, the system calls do not complain but the file is not created. I'm sure this has something to do with W7 security, but shouldn't the system calls return -1 to let the program know its not gonna work?
It gets worse... After I realized that the system calls were not failing I figured I'd test for the presence of the file after the close() but that even succeeded! The file does not show up in explorer, but stat(c:/filename) says its there.
This path is set by the program user, so how can I detect that the file operation is not successful if every system call I try tells me it was successful?
The accesses got redirected to a private folder by UAC data redirection.
That is a compatibility feature, giving programs pretend write access to the Windows directory and the system drive root, without compromising the system.
I was wondering how to set or find the local log files on your computer in Linux. I was reading the GNU C guide on syslog, and when you open a log, you declare the log your going to write to. In the examples they have LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, etc.. How do you set these, or where are they located? I was also wondering where LOG_SYSLOG is located? When i was looking under /var/log, i didn't see anything that looked like a system log. I cannot seem to find much online about the log files themselves. Only how to use the syslog functions.
in linux (I'm running ubuntu 14.04)
the log files are (by default) in /var/log/
one of those files is 'syslog'
if the system has been up for a while
there will also be files named similar to:
'syslog.#.gz' which is a zipped file of the prior syslog(s)
I want to create a project to lock file and folders in ubuntu by face detection through opencv using C language. Can you please let me know it is possible and how can i do it.
Can't help you with the opencv part, but "lock file and folders" could mean a few things:
You want to change permissions of files so that a given user/group can/cannot
access them. If this is the case, you want the chmod function.
See man 2 chmod. Seems like this is probably what you're after?
Usually, "file locking" on Linux refers to a means to prevent other processes from accessing a file without changing permissions via either:
Mandatory file locking via lockf (or fcntl).
Advisory file locking via flock.
If file locking is what you're after, here are the "see also" documents referred to by the man pages on lockf and/or flock:
https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
https://www.kernel.org/doc/Documentation/filesystems/locks.txt
Note: Others have indicated you might want to use the C++ API for opencv. All of these functions should work just fine from C++ too.
How to make an application to prevent itself from launching from the command line?
I have a binary which should be launched by a daemon; but when somebody tries to launch the binary from command line, I should error out stating "cannot be launched from command line".
Tried googling but in vain.
PS. http://www.daniweb.com/software-development/c/threads/449682/stop-launching-from-command-line
I wanted to check if there are better ways than those mentioned in the link..
I am not sure there is a bullet proof answer (to how to prevent a program to be started from command line). You could consider
testing with isatty(3) that STDIN_FILENO (i.e. 0) is not a tty
try to open /dev/tty (it should fail) see tty(4)
testing with getsid(2) that your are not in the same session than your parent, or starting a new session with setsid(2)
calling yourself daemon(3)
And I am not sure that you always want to reject being started from a terminal. For debugging, you surely want to be able to be started from a terminal. I actually would just warn, not quit, if started from a terminal.
And you probably want to install your program outside of standard paths, maybe in some libexec/ or sbin/ directory.
See also capabilities(7), pty(7), termios(3)
For the record, testing with isatty(3) only works if you are writing that binary files yourself. The method would fail if you are trying to prevent people from starting a third-party binary files.
Generally speaking, to prevent people from starting the specific program(s) from command line, the *nix way is to chown the binary file(s) to be owned by the daemon that launches it, and also to be of owned by the group say no_command_line. Then chmod 705 binary_executables, and put all those people not allowed to run the binary_executables from command line in the group no_command_line.
HTH