View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000119 | Pgpool-II | Bug | public | 2014-11-05 11:00 | 2014-11-28 17:21 |
| Reporter | bow.fujita | Assigned To | t-ishii | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | assigned | Resolution | open | ||
| Platform | Linux | OS | Debian | OS Version | 7 (wheezy) |
| Summary | 0000119: Signal might be sent to pid=1 (init process) in send_failback_request() | ||||
| Description | I built pgpool-II 3.2.6 from source code and run as streaming-replication mode. There are two backend PostgreSQL 9.2.4. One is localhost and another is remote. While I was testing failover and failback features of pgpool-II by restarting each PostgresSQL server repeatedly, Linux suddenly start shutting down. My environment is not actual Debian distribution but custom (embedded) Linux based on Debian and pgpool is running as root. I investigated why Linux would be shut down and found that init process (pid=1) received SIGUSR1 upon segfalt occurred in child process of pgpool. Updating pgpool to 3.2.9 wasn't fixed unfortunately. So I patched some debug codes to pgpool in order to figure out which code sent SIGUSR1 to init process, and I found that it was in send_failback_request() in main.c. My assumption is, send_failback_request() was called in pool process, however, that pool process had been zombie so ppid would be 1. Here I attach the patch to prevent kill() from sending a signal to init process. This patch replaces all kill() with pool_kill() in source tree because I'm not sure which kill() is suspicious. Regards | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Thanks for the report. Definitely sending any signal to process id 1 is no good. I have took a look at your patch. I think it would be better to replace getppid() where pgpool-II calls kill. My idea is remembering parent process when pgpool-II child is forked off, the use the process id when it needs to send signal to parent. This would be simple and less invasive. |
|
|
Either way is fine as long as no signal will be sent to pid=1. But I concern about in case a child process remembers its parent pid, no way to make sure that pid is actually its parent process and it's alive right before sending a signal. |
|
|
I wonder why you run pgpool-II as root in the first place. |
|
|
Just lazy configuration. I know I should run pgpool-II as non-root then init process would not accept any signal. |
|
|
I have tried to reproduce the issue but unable to do so. Apparently the scenario could occur, If somehow the child process becomes orphan and then it tries to issue a signal to its parent (getppid ()). So one solution could be to to check if the saved parent pid in the child is same to the one returned by getppid() before proceeding to send the signal, and if the bids differ that would mean the parent has already died and in that case the child go on to commit the suicide. There is another solution to guard the child process to become orphan by using prctl() [e.g prctl(PR_SET_PDEATHSIG, SIGHUP)] system call, Asking the kernal to deliver a signal when the parent goes down. And once the child receives that signal it stop processing and exit itself. But the problem with this approach is, prctl() is not posix function and only exists in Linux. So this becomes not an option. |
|
|
> Apparently the scenario could occur, If somehow the child process becomes orphan > and then it tries to issue a signal to its parent (getppid ()). So one solution > could be to to check if the saved parent pid in the child is same to the one returned by getppid() before proceeding to send the signal, and if the bids differ that would mean the parent has already died and in that case the child go on to commit the suicide. So this is the solution? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-11-05 11:00 | bow.fujita | New Issue | |
| 2014-11-05 11:00 | bow.fujita | File Added: pool_kill.patch | |
| 2014-11-06 08:00 | t-ishii | Assigned To | => t-ishii |
| 2014-11-06 08:00 | t-ishii | Status | new => assigned |
| 2014-11-06 08:03 | t-ishii | Note Added: 0000476 | |
| 2014-11-06 10:39 | bow.fujita | Note Added: 0000478 | |
| 2014-11-06 10:43 | t-ishii | Note Added: 0000479 | |
| 2014-11-07 06:09 | bow.fujita | Note Added: 0000481 | |
| 2014-11-13 22:25 | Muhammad Usama | Note Added: 0000491 | |
| 2014-11-28 17:21 | t-ishii | Note Added: 0000497 |
