Can batch or Windows cmd file create or release mutex, without custom exe?
Similar questions (like this) tell only to write custom c exe.
Can I work with mutex from bare batch script, or only with use a some Windows standard utils?
UPD
I do not need the single instance bat, I need to work with mutex to send the message to already exist parent-process with known mutex. Temp file is not an answer.
UPD 2
Parent program have the mutex (I use the hMutex:=CreateMutex( nil, TRUE, 'VCSClient2r123r123refqwe' ); in program startups, to prevent the multiple instances of parent program.
Parent program run svn.exe diff "some_modified_file" --diff-cmd "diff.bat" --force
diff.bat should send some messages to parent program. Because mutex is already exist and mutex name are fixed, I want to use it to send info from diff.bat to parent process.
Related
While daemonizing my program in C using code "stolen" from this webpage upon initialisation the daemon creates a lockfile which stores the process pid thusly:
:
lfp=open(LOCK_FILE,O_RDWR|O_CREAT,0640);
if (lfp<0) exit(1); /* can not open */
if (lockf(lfp,F_TLOCK,0)<0) exit(0); /* can not lock */
sprintf(str,"%d\n",getpid());
write(lfp,str,strlen(str)); /* store pid in file */
:
The webpage doesn't seem to bother with cleaning up after the daemon terminates. In fact, searching the web I cannot find a way to handle this.
All examples of daemonizing C-code will create a lockfile, but none remove it afterwards.
How should I unlock and then remove the pidfile assuming that I can catch SIGTERM and exit gracefully?
The lock itself is automatically released:
reference:
File locks are released as soon as the process holding the locks closes some
file descriptor for the file.
To remove the file you can use unlink. I suspect that the lock file is kept around since future invocations of the program will re-recreate it, thus reducing overhead.
You can unlock explicitly using F_ULOCK. By the way from fcntl manpage (which is used on linux by lockf) it is indicated that locks are removed on file close or process end.
So after dying the daemon do not hold any lock. It can so open the file and set a new lock.
I'm using C to scan a directory which contains frames extracted by ffmpeg. Now in the event that the last file is reached during the scan, I need to check for two conditions:
It's the last file as the video duration is over.
It's the last file as ffmpeg terminated abruptly and is no longer able to populate the directory
My C program workflow is like:
while(<there exists files in the directory>)
{
// iterate over them and do something with each frame
}
// coming out of the loop means no more files available...so I need a if condition
if(<check if ffmpeg is stopped>) // <-- need to know what to put inside the condition
{
// start it again
}
else
{
// video is over, nothing more left to do
}
I'm thinking I can do this using Process ID of ffmpeg, but how would I get that info? Any other alternative way of checking if ffpmeg has stopped?
Some metadata
OS : Windows 7
IDE : Dev C++
Language Used : C
You can definitely wait for FFmpeg process to finish. You normally obtain ffmpeg.exe process handle and either wait for it using wait functions, check its GetExitCodeProcess or both.
If you don't have a handle, but you do have a process identifier, OpenProcess will get you the handle.
Of course, you would not have to go into that trouble if you used native Windows APIs where you would be dealing with frames directly, not through files and external processes.
Not sure if this is a way to go in your case, but... in unix world a program that runs in background normally creates a publicly readable file with its process id. And then removes it when finished.
You could create this file from your batch script and then in your C program you could check if a pid from that file is running or not.
I am writing a program in ANSI C, that takes PID as an argument and needs to print on stdout information about a file name every time, when that given PID opens or closes any file.
Basicly we know, that /proc/PID/fd directory contains symlinks to the files, used by a PID.
By readdir()'ing that directory in a while loop and readlink()'ing each element - I can get file names of all files, currently opened by a PID and print them to stdout.
But that doesn't fully solve my original task - I need to print to STDOUT only events of changes in Opened File Descriptor Table for a PID. Moreover, I need to catch not only when new file is opened, but also when it's FD is closed.
So, I need some mechanism to catch file access events for a given PID in a user-space.
I also tried to use inotify() mechanism to catch IN_OPEN / IN_CLOSE, but that only works for regural directories, not for /proc (procfs) ! When I add inotify_watch for /proc/PID/fd directory - it simply doesn't catch any events (most likely due to the nature of PROCFS)
Could you please suggest mechanism to solve my task ?
P.S. And sorry for my bad english.
If you need Linux-specific solution, you could use fanotify. Check here for example - http://git.infradead.org/users/eparis/fanotify-example.git. You can subscribe for global notifications and then to filter only those, which are for the pid you're interested in.
If you run a .bat or .cmd file with %0|%0 inside, your computer starts to use a lot of memory and after several minutes, is restarted. Why does this code block your Windows? And what does this code programmatically do? Could it be considered a "bug"?
This is the Windows version of a fork bomb.
%0 is the name of the currently executing batch file. A batch file that contains just this line:
%0|%0
Is going to recursively execute itself forever, quickly creating many processes and slowing the system down.
This is not a bug in windows, it is just a very stupid thing to do in a batch file.
This is known as a fork bomb.
It keeps splitting itself until there is no option but to restart the system.
http://en.wikipedia.org/wiki/Fork_bomb
What it is:
%0|%0 is a fork bomb. It will spawn another process using a pipe | which runs a copy of the same program asynchronously. This hogs the CPU and memory, slowing down the system to a near-halt (or even crash the system).
How this works:
%0 refers to the command used to run the current program. For example, script.bat
A pipe | symbol will make the output or result of the first command sequence as the input for the second command sequence. In the case of a fork bomb, there is no output, so it will simply run the second command sequence without any input.
Expanding the example, %0|%0 could mean script.bat|script.bat. This runs itself again, but also creating another process to run the same program again (with no input).
%0 will never end, but it never creates more than one process because it instantly transfers control to the 2nd batch script (which happens to be itself).
But a Windows pipe creates a new process for each side of the pipe, in addition to the parent process. The parent process can't finish until each side of the pipe terminates. So the main program with a simple pipe will have 3 processes. You can see how the bomb quickly get's out of control if each side of the pipe recursively calls the parent batch!
It's a logic bomb, it keeps recreating itself and takes up all your CPU resources. It overloads your computer with too many processes and it forces it to shut down. If you make a batch file with this in it and start it you can end it using taskmgr. You have to do this pretty quickly or your computer will be too slow to do anything.
I have to change working directory from my C program. For this I have used the following command:
execl("/bin/cd","cd","..",(char*)0);
but this command is not changing the directory?
Is anything wrong in this command or is there any other way to change working directory from C program?
To change the current directory you should use chdir:
int chdir(const char *path);
On success it returns 0.
You can't use execl for several reasons:
cd is typically a shell builtin command;
on most systems /bin/cd does not exists; on the very very few systems that have it, it changes the current directory and then spawns a child shell process;
the current directory is a process' property: if you change the current directory using /bin/cd, you'd lose the directory change as soon as the process terminates;
if you use a function from the exec family, the current process image is replaced with a new process image - you could use system, but wouldn't fix the previous 3 problems.
What you are doing won't work because the exec family of calls will actually replace your current program in the current process. In other words, you will have been terminated so that, when cd is finished, your parent process will once again take over.
If you want to change the working directory for the current process, use chdir. If you want to change it on exit, you're out of luck because your program itself is running in a separate process from the parent that started it.
So, unless you have some form of communication with the parent, that's not going to work.
You need to use the chdir system call to change the working directory of the calling process.