Argumentless MUPIP RUNDOWN should record in syslog the orphaned jnlpool ipcs (semid/shmid) that it removes #266
Labels
Comments
nars1
added a commit
that referenced
this issue
Nov 30, 2022
…pool in syslog Requirement ----------- * The requirement is described at https://gitlab.com/YottaDB/DB/YDB/-/issues/266#description. Pasted below. MUPIP RUNDOWN with no arguments examines all ipcs in the system (semaphores and shared memory segments) and removes any if finds are created by YottaDB if they are orphaned (i.e. no processes have interest in them). Currently, the argumentless rundown records the ipcs that it removes corresponding to database files in the form of SEMREMOVED and SHMREMOVED messages to the syslog. But it does not do this for journal pool ipcs that it removes. It would be desirable to have this recorded (e.g. in case an ipc disappears mysteriously, seeing it in the syslog would help confirm it is an argumentless rundown that removed it). Changes to argumentless MUPIP RUNDOWN output -------------------------------------------- * While trying to see what `mupip rundown` does in a replicated environment currently after all processes tied to that environment are killed, but ipcs are not yet removed, I saw the following messages corresponding to the journal pool ipcs on the source side being removed. ``` %YDB-I-MUJPOOLRNDWNSUC, Jnlpool section (id = 300285990) belonging to the replication instance mumps.repl successfully rundown %YDB-I-SEMREMOVED, Semaphore id 300285990 removed from the system %YDB-I-MUJPOOLRNDWNSUC, Jnlpool section (id = 1217265713) belonging to the replication instance mumps.repl successfully rundown . . ``` * There are a few issues I noticed. - The `MUJPOOLRNDWNSUC` message shows up twice for the same `mumps.repl` file but it has different `id`s. Turns out the first message displays a `semid` whereas the second message displays a `shmid`. - The `SEMREMOVED` message already displays the semid so no need to displays the `semid` twice. * I fixed the code so we print a `SHMREMOVED` message instead of the first `MUJPOOLRNDWNSUC` message. That way we have the following output after the changes in this commit. ``` %YDB-I-SHMREMOVED, Removed Shared Memory id 1217265713 corresponding to file mumps.repl %YDB-I-SEMREMOVED, Semaphore id 300285990 removed from the system %YDB-I-MUJPOOLRNDWNSUC, Jnlpool section (id = 1217265713) belonging to the replication instance mumps.repl successfully rundown . . ``` * The changes to achieve the above new output were to check in `sr_unix/mu_rndwn_repl_instance.c` if `rndwn_both_pools` is FALSE. If so, it means the caller is an argumentless mupip rundown. In that case, we now issue `SHMREMOVED` and `SEMREMOVED` messages to the rundown output (using `gtm_putmsg_csa()`). And skip issuing the `ERR_MURPOOLRNDWNSUC` etc. message since that will be done later in the caller (`sr_unix/mu_rndwn_all.c`). Changes to syslog ----------------- * In addition, enhanced `sr_unix/mu_rndwn_repl_instance.c` to also do `send_msg_csa()` calls whenever it does a `gtm_putmsg_csa()` call of `SHMREMOVED` or `SEMREMOVED` messages. This took care of implementing the original requirement (described in the `Requirement` section).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Final Release Note
Description
MUPIP RUNDOWN with no arguments examines all ipcs in the system (semaphores and shared memory segments) and removes any if finds are created by YottaDB if they are orphaned (i.e. no processes have interest in them). Currently, the argumentless rundown records the ipcs that it removes corresponding to database files in the form of SEMREMOVED and SHMREMOVED messages to the syslog. But it does not do this for journal pool ipcs that it removes. It would be desirable to have this recorded (e.g. in case an ipc disappears mysteriously, seeing it in the syslog would help confirm it is an argumentless rundown that removed it).
Draft Release Note
MUPIP RUNDOWN with no arguments records (in the syslog) the ids of orphaned semaphore and shared memory segments (corresponding to the journal and receive pool) that it removes in the form of SEMREMOVED/SHMREMOVED messages. Previously it did this recording only for database file ipcs and not for journal/receive pool ipcs making it harder for one to know why a journal pool semid/shmid suddenly disappeared.
The text was updated successfully, but these errors were encountered: