I find such a problem. Assuming I have a C program sleepret.c, compiled with gcc inside cygwin.
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
int sec = 0;
if(argc>1)
sec = atoi(argv[1]);
sleep(sec);
return sec & 1;
}
I'm using cygwin1.dll 3.1.4 on Window 8.1.
Now, run sleepret.exe 10. During its sleeping, from another cygwin terminal, I use ps to identify its PID and kill -9 <pid>, then the sleepret's caller can identify its return value(process exit code) is 143 via $?. That's utterly correct behavior, so far so good.
However, if I kill sleepint.exe with Windows native taskkill /F /IM sleepint.exe, the $? will always be 0, which means, sleepint's caller will not be able to know whether sleepint results in success.
Then, how to workaround this issue?
I'm running an IO intensive process that supports O_DIRECT. Is there a way to tell if O_DIRECT is being used while the process is running?
I tried "iostat -x 1" but I'm not sure which field would help me.
Thanks.
You will have to get the pid of the running process. Once you get the pid, you can do
cat /proc/[pid]/fdinfo/<fd number>
You will aslo have to know the fd number of the file being opened.
It will show flags field. The flags field is octal value displaying the flags passed to open the file descriptor fd. You will have to examine it to know whether O_DIRECT is set or not.
As an example, on my ubuntu machine(X86_64), I created 2 files - foo1 & foo2
touch foo1 foo2
and then opened foo1 with O_DIRECT and foo2 without O_DIRECT. Below is the program
#define _GNU_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main()
{
printf("%u\n", getpid());
int fd1 = open("foo1", O_RDWR|O_DIRECT); //O_DIRECT set
printf("foo1: %d\n", fd1);
int fd2 = open("foo2", O_RDWR); //Normal
printf("foo2: %d\n", fd2);
sleep(60);
close(fd1);
close(fd2);
return 0;
}
On running this I got the output:
8885
foo1: 3 //O_DIRECT
foo2: 4
8885 is the pid. So I did
cat /proc/8885/fdinfo/3 //O_DIRECT
pos: 0
flags: 0140002
mnt_id: 29
-------------------------------
cat /proc/8885/fdinfo/4
pos: 0
flags: 0100002
mnt_id: 29
From the above output you can see that for O_DIRECT, in the flags field 0040000 is also set.
I'm trying to create a FIFO named pipe using the mknod() command:
int main() {
char* file="pipe.txt";
int state;
state = mknod(file, S_IFIFO & 0777, 0);
printf("%d",state);
return 0;
}
But the file is not created in my current directory. I tried listing it by ls -l . State returns -1.
I found similar questions here and on other sites and I've tried the solution that most suggested:
int main() {
char* file="pipe.txt";
int state;
unlink(file);
state = mknod(file, S_IFIFO & 0777, 0);
printf("%d",state);
return 0;
}
This made no difference though and the error remains. Am I doing something wrong here or is there some sort of system intervention which is causing this problem?
Help.. Thanks in advance
You are using & to set the file type instead of |. From the docs:
The file type for path is OR'ed into the mode argument, and the
application shall select one of the following symbolic
constants...
Try this:
state = mknod(file, S_IFIFO | 0777, 0);
Because this works:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main() {
char* file="pipe.txt";
int state;
unlink(file);
state = mknod(file, S_IFIFO | 0777, 0);
printf("state %d\n", state);
return 0;
}
Compile it:
gcc -o fifo fifo.c
Run it:
$ strace -e trace=mknod ./fifo
mknod("pipe.txt", S_IFIFO|0777) = 0
state 0
+++ exited with 0 +++
See the result:
$ ls -l pipe.txt
prwxrwxr-x. 1 lars lars 0 Jul 16 12:54 pipe.txt
I am trying to use named pipes for interprocess communication but I'm seeing strange things I cannot understand.
I have this "writer" code:
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#define FIFO_NAME "american_maid"
int main(void)
{
char s[300];
int num, fd;
mknod(FIFO_NAME, S_IFIFO | 0666, 0);
printf("waiting for readers...\n");
fd = open(FIFO_NAME, O_WRONLY);
printf ("FD = %d", fd);
printf("got a reader--type some stuff\n");
while (gets(s), !feof(stdin)) {
if ((num = write(fd, s, strlen(s))) == -1)
perror("write");
else
printf("speak: wrote %d bytes\n", num);
}
return 0;
}
Now when I do a "tail -f american_maid" the tail blocks waiting for a writer.
Then I run the writer code and it finds that tail -f is waiting on the other end of the pipe. So far so good.
When I type anything in the writer application, nothing shows up in tail window, HOWEVER, as soon as I close (Ctrl-C) the writer app, ALL that I had typed appear in the tail window.
It's like the writer has to close before tail could show anything. Any ideas what is happening and why it's happening and how I can fix this?
Thanks
There is nothing wrong here. tail wants to extract the last lines. To determine which these are, it is looking for end-of-file in the fifo, which it only sees after the writer has closed the writing end of the fifo.
On Linux, is it possible to somehow disable signaling for programs externally... that is, without modifying their source code?
Context:
I'm calling a C (and also a Java) program from within a bash script on Linux. I don't want any interruptions for my bash script, and for the other programs that the script launches (as foreground processes).
While I can use a...
trap '' INT
... in my bash script to disable the Ctrl C signal, this works only when the program control happens to be in the bash code. That is, if I press Ctrl C while the C program is running, the C program gets interrupted and it exits! This C program is doing some critical operation because of which I don't want it be interrupted. I don't have access to the source code of this C program, so signal handling inside the C program is out of question.
#!/bin/bash
trap 'echo You pressed Ctrl C' INT
# A C program to emulate a real-world, long-running program,
# which I don't want to be interrupted, and for which I
# don't have the source code!
#
# File: y.c
# To build: gcc -o y y.c
#
# #include <stdio.h>
# int main(int argc, char *argv[]) {
# printf("Performing a critical operation...\n");
# for(;;); // Do nothing forever.
# printf("Performing a critical operation... done.\n");
# }
./y
Regards,
/HS
The process signal mask is inherited across exec, so you can simply write a small wrapper program that blocks SIGINT and executes the target:
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
sigset_t sigs;
sigemptyset(&sigs);
sigaddset(&sigs, SIGINT);
sigprocmask(SIG_BLOCK, &sigs, 0);
if (argc > 1) {
execvp(argv[1], argv + 1);
perror("execv");
} else {
fprintf(stderr, "Usage: %s <command> [args...]\n", argv[0]);
}
return 1;
}
If you compile this program to noint, you would just execute ./noint ./y.
As ephemient notes in comments, the signal disposition is also inherited, so you can have the wrapper ignore the signal instead of blocking it:
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
struct sigaction sa = { 0 };
sa.sa_handler = SIG_IGN;
sigaction(SIGINT, &sa, 0);
if (argc > 1) {
execvp(argv[1], argv + 1);
perror("execv");
} else {
fprintf(stderr, "Usage: %s <command> [args...]\n", argv[0]);
}
return 1;
}
(and of course for a belt-and-braces approach, you could do both).
The "trap" command is local to this process, never applies to children.
To really trap the signal, you have to hack it using a LD_PRELOAD hook. This is non-trival task (you have to compile a loadable with _init(), sigaction() inside), so I won't include the full code here. You can find an example for SIGSEGV on Phack Volume 0x0b, Issue 0x3a, Phile #0x03.
Alternativlly, try the nohup and tail trick.
nohup your_command &
tail -F nohup.out
I would suggest that your C (and Java) application needs rewriting so that it can handle an exception, what happens if it really does need to be interrupted, power fails, etc...
I that fails, J-16 is right on the money. Does the user need to interract with the process, or just see the output (do they even need to see the output?)
The solutions explained above are not working for me, even by chaining the both commands proposed by Caf.
However, I finally succeeded in getting the expected behavior this way :
#!/bin/zsh
setopt MONITOR
TRAPINT() { print AAA }
print 1
( ./child & ; wait)
print 2
If I press Ctrl-C while child is running, it will wait that it exits, then will print AAA and 2. child will not receive any signals.
The subshell is used to prevent the PID from being shown.
And sorry... this is for zsh though the question is for bash, but I do not know bash enough to provide an equivalent script.
This is example code of enabling signals like Ctrl+C for programs which block it.
fixControlC.c
#include <stdio.h>
#include <signal.h>
int sigaddset(sigset_t *set, int signo) {
printf("int sigaddset(sigset_t *set=%p, int signo=%d)\n", set, signo);
return 0;
}
Compile it:
gcc -fPIC -shared -o fixControlC.so fixControlC.c
Run it:
LD_LIBRARY_PATH=. LD_PRELOAD=fixControlC.so mysqld