alarm() generates SIGALRM after random time
I am trying to make a program, that will parse pcap file until the timer expires. I use alarm
function for that, found here, which really stops the pcap_loop
, but definitely not after given time.
Important parts of code:
pcap_t *handle;
void end_loop(int signum)
{
pcap_breakloop(handle);
}
int main(...){
...
handle = pcap_open_live(argv[2], BUFSIZ, 1, 100, errbuf);
....
signal(SIGALRM, end_loop);
alarm(5);
pcap_loop(handle, num_packets, got_packet, NULL);
pcap_close(handle);
send_syslog_message(hostname, list_of_parsed_packets));
return 0;
}
I have tried running the program many times and it always stops, but as the title says, the time it takes is just random. Am I doing something wrong?
c++ linux signals libpcap
add a comment |
I am trying to make a program, that will parse pcap file until the timer expires. I use alarm
function for that, found here, which really stops the pcap_loop
, but definitely not after given time.
Important parts of code:
pcap_t *handle;
void end_loop(int signum)
{
pcap_breakloop(handle);
}
int main(...){
...
handle = pcap_open_live(argv[2], BUFSIZ, 1, 100, errbuf);
....
signal(SIGALRM, end_loop);
alarm(5);
pcap_loop(handle, num_packets, got_packet, NULL);
pcap_close(handle);
send_syslog_message(hostname, list_of_parsed_packets));
return 0;
}
I have tried running the program many times and it always stops, but as the title says, the time it takes is just random. Am I doing something wrong?
c++ linux signals libpcap
add a comment |
I am trying to make a program, that will parse pcap file until the timer expires. I use alarm
function for that, found here, which really stops the pcap_loop
, but definitely not after given time.
Important parts of code:
pcap_t *handle;
void end_loop(int signum)
{
pcap_breakloop(handle);
}
int main(...){
...
handle = pcap_open_live(argv[2], BUFSIZ, 1, 100, errbuf);
....
signal(SIGALRM, end_loop);
alarm(5);
pcap_loop(handle, num_packets, got_packet, NULL);
pcap_close(handle);
send_syslog_message(hostname, list_of_parsed_packets));
return 0;
}
I have tried running the program many times and it always stops, but as the title says, the time it takes is just random. Am I doing something wrong?
c++ linux signals libpcap
I am trying to make a program, that will parse pcap file until the timer expires. I use alarm
function for that, found here, which really stops the pcap_loop
, but definitely not after given time.
Important parts of code:
pcap_t *handle;
void end_loop(int signum)
{
pcap_breakloop(handle);
}
int main(...){
...
handle = pcap_open_live(argv[2], BUFSIZ, 1, 100, errbuf);
....
signal(SIGALRM, end_loop);
alarm(5);
pcap_loop(handle, num_packets, got_packet, NULL);
pcap_close(handle);
send_syslog_message(hostname, list_of_parsed_packets));
return 0;
}
I have tried running the program many times and it always stops, but as the title says, the time it takes is just random. Am I doing something wrong?
c++ linux signals libpcap
c++ linux signals libpcap
edited Nov 15 '18 at 9:58
Ab Majeed
1084
1084
asked Nov 15 '18 at 9:45
ErikErik
398
398
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
man pcap_breakloop
says:
The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets returned by the OS. Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling pcap_breakloop() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling pcap_breakloop(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes.
This is probably what you observes. The alarm signal is received in due time, but you fail to specify that system calls should NOT be restarted by that signal. As a consequence, pcap_loop()
is not returning immediately.
See How to know if a Linux system call is restartable or not?
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag inend_loop
and ingot_packet
callpcap_breakloop
if flag is set.
– Erik
Nov 15 '18 at 9:58
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316536%2falarm-generates-sigalrm-after-random-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
man pcap_breakloop
says:
The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets returned by the OS. Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling pcap_breakloop() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling pcap_breakloop(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes.
This is probably what you observes. The alarm signal is received in due time, but you fail to specify that system calls should NOT be restarted by that signal. As a consequence, pcap_loop()
is not returning immediately.
See How to know if a Linux system call is restartable or not?
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag inend_loop
and ingot_packet
callpcap_breakloop
if flag is set.
– Erik
Nov 15 '18 at 9:58
add a comment |
man pcap_breakloop
says:
The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets returned by the OS. Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling pcap_breakloop() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling pcap_breakloop(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes.
This is probably what you observes. The alarm signal is received in due time, but you fail to specify that system calls should NOT be restarted by that signal. As a consequence, pcap_loop()
is not returning immediately.
See How to know if a Linux system call is restartable or not?
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag inend_loop
and ingot_packet
callpcap_breakloop
if flag is set.
– Erik
Nov 15 '18 at 9:58
add a comment |
man pcap_breakloop
says:
The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets returned by the OS. Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling pcap_breakloop() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling pcap_breakloop(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes.
This is probably what you observes. The alarm signal is received in due time, but you fail to specify that system calls should NOT be restarted by that signal. As a consequence, pcap_loop()
is not returning immediately.
See How to know if a Linux system call is restartable or not?
man pcap_breakloop
says:
The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets returned by the OS. Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling pcap_breakloop() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling pcap_breakloop(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes.
This is probably what you observes. The alarm signal is received in due time, but you fail to specify that system calls should NOT be restarted by that signal. As a consequence, pcap_loop()
is not returning immediately.
See How to know if a Linux system call is restartable or not?
answered Nov 15 '18 at 9:48
YSCYSC
24.3k555110
24.3k555110
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag inend_loop
and ingot_packet
callpcap_breakloop
if flag is set.
– Erik
Nov 15 '18 at 9:58
add a comment |
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag inend_loop
and ingot_packet
callpcap_breakloop
if flag is set.
– Erik
Nov 15 '18 at 9:58
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag in
end_loop
and in got_packet
call pcap_breakloop
if flag is set.– Erik
Nov 15 '18 at 9:58
It seems that this is the problem. However this is the first time I am using signals and I am not sure if I am able to make it work. My only idea, after reading this, is to set global flag in
end_loop
and in got_packet
call pcap_breakloop
if flag is set.– Erik
Nov 15 '18 at 9:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316536%2falarm-generates-sigalrm-after-random-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown