search for: sigkill

...id` sshd leave pid file ! sshd.c code: =============== .... /* * Arrange to restart on SIGHUP. The handler needs * listen_sock. */ signal(SIGHUP, sighup_handler); signal(SIGTERM, sigterm_handler); signal(SIGQUIT, sigterm_handler); .... =============== Missing line is : signal(SIGKILL, sigterm_handler);

2017-09-08 13:44 GMT+02:00 Pavel Szalbot <pavel.szalbot at gmail.com>: > I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL > will be as well. This assumption might be wrong. So I will test it. It would > be interesting to see client to work in case of crash (SIGKILL) and not in > case of graceful exit of glusterfsd. Exactly. if this happen, probably there is...

...sites. > > recently, at multiple customer sites it has started just going away. > no core file (yes, ulimit is configured), nothing in any of its > (several) log files. it's just gone. > > running it under strace until it dies reveals that every thread has > been given a SIGKILL. > > How does one figure out who deliverd a SIGKILL? For other, non-fatal, > signals it is possible to glean the PID of the sending process in a > signal handler, but obviously you can't do that for SIGKILL because > the app doesn't survive the signal. > > I'm...

...end signal 15 (SIGTERM) to the process, maybe a bug in signal management on gluster side? Because kernel is already telling glusterfsd to exit, though signal 15 but glusterfsd seems to handle this in a bad way. a server hard-crash doesn't send any signal. I think this could be also similiar to SIGKILL (9) that can't be catched/ignored software side. In other words: is this a bug in gluster's signal management (if SIGKILL is working and SIGTERM no, i'll almost sure this is a bug in signal management), a engineering bug (relying only on a graceful exit [but even SIGTERM should be thre...

...the past 10 or so point releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32, but with 2.2.33 (and .1 and .2) no new logfiles are created, file descriptors still have the original files open and keep writings to those logs. On an idling test instance, I get: master: Warning: Sent SIGKILL to 1 log processes I can see both SIGUSR1 and SIGKILL generated by the master process, but the current log process doesn't terminate - it receives SIGUSR1, but not SIGKILL. Anyone able to verify this on their own setup? Am I missing a required config change? Using epoll, which hasn't chang...

...stall, the instance can't be destroyed. I have asked the question on openstack user mailing list and received no answers in weeks. Here is one example: # virsh destroy instance-00000085 error: Failed to destroy domain instance-00000085 error: Failed to terminate process 61222 with SIGKILL: Device or resource busy # lsof -p 61222 # ps -f -p 61222 UID PID PPID C STIME TTY TIME CMD 107 61222 1 68 Jan24 ? 9-23:06:19 [qemu-system-x86] <defunct> The log in /var/log/libvirt/libvirtd.log: 2014-02-08 03:21:31.597+0000: 2177: error...

...sh too much? I mean if reboot > reliably kills the VM, there is no doubt network crash or poweroff > will as well. IIUP, the only way to keep I/O running is to gracefully exiting glusterfsd. No, even killall resp. SIGTERMing glusterfsd ends up with I/O errors on the client. I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL will be as well. This assumption might be wrong. So I will test it. It would be interesting to see client to work in case of crash (SIGKILL) and not in case of graceful exit of glusterfsd. killall should send signal 15 (SIGTERM) to the process, ma...

Hi, I am using Dovecot 2.2.32 (dfbe293d4) I noticed lots of messages like: dovecot: master: Warning: Sent SIGKILL to 100 imap-login processes in /var/log/maillog I commented out "process_limit" service imap { # Most of the memory goes to mmap()ing files. You may need to increase this # limit if you have huge mailboxes. #vsz_limit = $default_vsz_limit # Max. number of IMAP processes (connections)...

...est-event-stats.c clang-4.0: warning: -Wl,-rpath=/usr/local/llvm40/lib: 'linker' input unused [-Wunused-command-line-argument] test-event-stats.c:101:8: warning: implicit declaration of function 'kill' is invalid in C99 [-Wimplicit-function-declaration] (void)kill(stats_pid, SIGKILL); ^ test-event-stats.c:101:24: error: use of undeclared identifier 'SIGKILL' (void)kill(stats_pid, SIGKILL); ^ 1 warning and 1 error generated. gmake[2]: *** [Makefile:656: test-event-stats.o] Error 1 gmake[2]: Leaving directory '/usr/...

...00's, is in use at hundreds of sites. recently, at multiple customer sites it has started just going away. no core file (yes, ulimit is configured), nothing in any of its (several) log files. it's just gone. running it under strace until it dies reveals that every thread has been given a SIGKILL. How does one figure out who deliverd a SIGKILL? For other, non-fatal, signals it is possible to glean the PID of the sending process in a signal handler, but obviously you can't do that for SIGKILL because the app doesn't survive the signal. I'm grasping at straws here, and am open...

Gandalf, SIGKILL (killall -9 glusterfsd) did not stop I/O after few minutes. SIGTERM on the other hand causes crash, but this time it is not read-only remount, but around 10 IOPS tops and 2 IOPS on average. -ps On Fri, Sep 8, 2017 at 1:56 PM, Diego Remolina <dijuremo at gmail.com> wrote: > I currently on...

...threads disabled freeze by setting PF_NOFREEZE, but vhost tasks's > didn't disable or add support for them. > > To fix both bugs, this switches the vhost task to be thread in the > process that does the VHOST_SET_OWNER ioctl, and has vhost_worker call > get_signal to support SIGKILL/SIGSTOP and freeze signals. Note that > SIGKILL/STOP support is required because CLONE_THREAD requires > CLONE_SIGHAND which requires those 2 signals to be suppported. > > This a modified version of patch originally written by Linus which > handles his review comment to himself to r...

The stub domain device model needs to trap the termination signal so as to actually destroy the stub domain. SIGKILL can''t be trapped, SIGTERM is caught by SDL and so may be unnoticed. SIGHUP can be trapped and is not caught by SDL (and by default causes a process termination without core). Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 2407a61c0d30 tools/python/xen/xend/...

...sites. > > recently, at multiple customer sites it has started just going away. > no core file (yes, ulimit is configured), nothing in any of its > (several) log files. it's just gone. > > running it under strace until it dies reveals that every thread has > been given a SIGKILL. > > How does one figure out who deliverd a SIGKILL? For other, non-fatal, > signals it is possible to glean the PID of the sending process in a > signal handler, but obviously you can't do that for SIGKILL because > the app doesn't survive the signal. > > I'm gr...

...eout goes into effect, it gets paused and I have to go into RHEVM to un-pause it. Diego On Fri, Sep 8, 2017 at 7:53 AM, Gandalf Corvotempesta <gandalf.corvotempesta at gmail.com> wrote: > 2017-09-08 13:44 GMT+02:00 Pavel Szalbot <pavel.szalbot at gmail.com>: >> I did not test SIGKILL because I suppose if graceful exit is bad, SIGKILL >> will be as well. This assumption might be wrong. So I will test it. It would >> be interesting to see client to work in case of crash (SIGKILL) and not in >> case of graceful exit of glusterfsd. > > Exactly. if this happe...

On 05/22, Mike Christie wrote: > > On 5/22/23 7:30 AM, Oleg Nesterov wrote: > >> + /* > >> + * When we get a SIGKILL our release function will > >> + * be called. That will stop new IOs from being queued > >> + * and check for outstanding cmd responses. It will then > >> + * call vhost_task_stop to tell us to return and exit. > >> + */ > > > > But who wi...

...ngs that looked like numbers into numbers. > The release does not build. Here is a patch to fix the build. > > > > test-event-stats.c:101:8: warning: implicit declaration of function 'kill' is invalid in C99 [-Wimplicit-function-declaration] > (void)kill(stats_pid, SIGKILL); > ^ > test-event-stats.c:101:24: error: use of undeclared identifier 'SIGKILL' > (void)kill(stats_pid, SIGKILL); > ^ On *BSD I assume? It would be useful to mention. But we'll think what we will do with this. Aki

...ned by its configuration. then all the threads, including the main prog, hang around doing stuff until they're told to stop, which happens all at once for all of them. On a good day, anyway. what is happening now is they will all run fine for some time (anhour or twelve) then they all receive a SIGKILL. Accordiing to a systemtap script I found online, it thinks the program is killing itself, but as the guy who wrote it, I don't think so. the script can be seen below in earlier mail. As for if it also fails on C6, I don't know. I've asked our support team to see if they have a C6/EL6...

When get_pending detects the task has been marked to be killed we try to clean up the SIGKLL by doing a sigdelset and recalc_sigpending, but we still leave it in shared_pending. If the signal is being short circuit delivered there is no need to put in shared_pending so this adds a check in complete_signal. This patch was modified from Eric Biederman <ebiederm at xmission.com> original

...unicorn slaves keep timing out & the master keeps restarting them. unicorn.log looks something like : E, [2011-12-08T18:11:32.912237 #26661] ERROR -- : worker=5 PID:15367 timeout (61s > 60s), killing E, [2011-12-08T18:11:32.952041 #26661] ERROR -- : reaped #<Process::Status: pid 15367 SIGKILL (signal 9)> worker=5 I, [2011-12-08T18:11:32.985925 #17824] INFO -- : worker=5 ready E, [2011-12-08T18:11:42.962869 #26661] ERROR -- : worker=3 PID:15499 timeout (61s > 60s), killing E, [2011-12-08T18:11:43.003741 #26661] ERROR -- : reaped #<Process::Status: pid 15499 SIGKILL (signal 9)&g...