signals

I have a loop handling an accept(2) call. I want to be able to perform some cleanup when a SIGINT is sent to the program. My first thought was to use the signal function. void signal_handler(int signal) { printf("Caught signal\n"); } int main() { signal(SIGINT, &signal_handler); // ... int accept_fd = accept(sock, NULL, NULL); if (accept_fd == -1) { close(sock); perror("accept"); return 1; } // ... } However, this simply prints "Caught signal" and then the program continues on. If I modify main to use sigaction , the program works as expected. int main() { struct sigaction sa; sa.sa_handler =

I am trying to add add some data to the database as soon as tables are created, using the post_syncdb signal. signals.post_syncdb.connect(init) Then in the init function, I want to set permission, so I use ct = ContentType.objects.get(app_label='news', model='Article') Permission(name='Approve articles', codename='can_approve_article', content_type=ct) But if I drop all the tables and run syncdb , I get ... File "...\base\functions\init.py", line 11, in init ct = ContentType.objects.get(app_label='news', model='Article') ... django.contrib.contenttypes.models.DoesNotExist: ContentType matching

flock() is generally async-signal-safe because it is a system call. Its semantics make it hard to implement it differently. It is not in the POSIX's list of async-signal-safe functions because it is not in POSIX at all. Is it possible to use flock() in the sigaction handler without problems? MOHAMED According to @alk answer in the following topic : We can develop our property flock() function (its name could be async_flock() ). we copy in this new function the content of the origin lockf() code and then we make the following changes in order to get an async-signal-safe function: replace _

It turns out that we can prevent appearing of a zombie process (i.e. the one whose parent doesn't wait() for it to _exit() ) by specifying SIGCHLD signal to be ignored with sigaction() by its parent. However, it seems like SIGCHLD is ignored by default anyway. How come does this work? int main (void) { struct sigaction sa; sa.sa_handler = SIG_IGN; //handle signal by ignoring sigemptyset(&sa.sa_mask); sa.sa_flags = 0; if (sigaction(SIGCHLD, &sa, 0) == -1) { perror(0); exit(1); } int pid = fork(); if (pid == 0) { //child process _exit(0); } do_something(); //parent process return 0; } Barmar The

Does this use of sem_post() in a signal handler rely on undefined behavior? /* * excerpted from the 2017-09-15 Linux man page for sem_wait(3) * http://man7.org/linux/man-pages/man3/sem_wait.3.html */ ... sem_t sem; ... static void handler(int sig) { write(STDOUT_FILENO, "sem_post() from handler\n", 24); if (sem_post(&sem) == -1) { write(STDERR_FILENO, "sem_post() failed\n", 18); _exit(EXIT_FAILURE); } } The semaphore sem has static storage duration. While the call to sem_post () is async-signal-safe, the POSIX.1-2008 treatment of signal actions seems to disallow referencing that semaphore

I just came across some code which used the kill system call to send a SIGSEGV signal to an app. The rationale behind this was that this would force the app to core dump and quit. This seems so wrong to me, is this normal practice? SIGQUIT is the correct signal to send to a program if you wish to produce a core dump. kill is the correct command line program to send signals (it is of course poorly named, since not all signals will kill the program). Note, you should not send random signals to the program, not all of them will produce a core dump. Many of them will be handled by the program