In the previous blog I showed you how to decommission a remote Content Server by deleting remote Docbase(s) and Docbroker(s). In fact, when I tried to delete remote Docbases I encounter a strange behavior, and it wasn’t easy to find the root cause!
In fact, the suppression of the remote Docbase may be silent or not… In case you use the silent way you probably will not see the strange behavior 😉
In the step of choosing the Docbase from the drop-down list, I saw each Docbase two times, like below:
Here, I cancelled the suppression to understand why, and to be sure that it is only a display issue to avoid side effects.
So, to understand what’s going on:
I activated RPC and SQL traces via iAPI:
I activated DFC traces, adding the following in the dfc.properties file:
dfc.tracing.enable=true dfc.tracing.verbose=true dfc.tracing.max_stack_depth=0 dfc.tracing.include_rpcs=true dfc.tracing.mode=standard dfc.tracing.include_session_id=true dfc.tracing.timing_style=date dfc.tracing.date_column_width=12 dfc.tracing.date_format=yyyy-MM-dd hh:mm:ss:SSS dfc.tracing.log.level = DEBUG dfc.tracing.print_exception_stack = true dfc.tracing.file_prefix=emc.support dfc.tracing.dir=/tmp
I started the installer again:
Once I reached the screen and opened the list of repositories with the duplicated names, I disabled traces vi iAPI:
Also, I disabled DFC traces in dfc.properties file:
I checked the following log files:
– Repository log
– DFC Traces output
Nothing! really nothing related to the suppression… I suspected that the installer take the list of Docbases from a file somewhere on the server…
First track, I checked the server.ini file and its content :
[[email protected] ~]$ ls -rtl $DOCUMENTUM/dba/config/repo/*server* -rw-rw-r--. 1 dmadmin dmadmin 1978 Dec 21 2017 /app/dctm/server/dba/config/repo/server.ini [[email protected] ~]$ cat /app/dctm/server/dba/config/repo/server.ini ... [SERVER_STARTUP] docbase_id = 123456 docbase_name = repo server_config_name = ser-1_repo database_conn = DBrepo database_owner = repo ...
Nothing could cause this issue 🙁
I decided to browse folders in $DOCUMENTUM, and what really jumped out at me is that I found two start scripts (backup of the original and updated one):
[[email protected] ~]$ ls -rtl $DOCUMENTUM/dba/dm_start* -rwxrw-rw-. 1 dmadmin dmadmin 2656 Mar 24 2017 dm_start_repo1_repo1_bck_20180123-132143 -rwxrw-rw-. 1 dmadmin dmadmin 2656 Mar 27 2017 dm_start_repo_repo_bck_20180123-132143 -rwxrw-rw-. 1 dmadmin dmadmin 2658 Jul 23 2018 dm_start_repo_repo -rwxrw-rw-. 1 dmadmin dmadmin 2658 Jul 23 2018 dm_start_repo1_repo1
I deleted the backup file, and checked again. YES, it was because of two start scripts in $DOCUMENTUM/dba!
By the way, the start file has been updated to correct permission issue, see this blog for more information 😉
I made some tests to understand how the installer behaves:
I created files deleted above to get the same list again, and copied an existing dm_start:
cp $DOCUMENTUM/dba/dm_start_repo_repo $DOCUMENTUM/dba/dm_start_
A third “repo” appeared in the list.
I updated the just created file dm_start_ content:
vi $DOCUMENTUM/dba/dm_start_ ... DM_REPOSITORY_NAME=test1 DM_REPOSITORY_SERVICE_NAME=test1 ...
Now, I have the below 🙂
To sum up, the installer grep both below values in all dm_start_* and display all:
So, it is only a display issue because of a light way to select the Docbases, I think you agree that there is more efficient way to do it.
No issue if you select the remote Docbase and you delete it, but it will still be shown by the installer until you delete the backup file.
I hope that this blog will save your time 😉 Don’t hesitate to share other strange behaviors you encountered.