Recovering from abnormal termination If a logical volume that was previously allocated by the BB services is not mounted when  bbProxy is restarted, bbProxy removes such logical volumes as part of the restart. However, if  such logical volumes are still mounted, they are not removed during the restart of bbProxy. If  the logical volumes are not removed, it might be necessary to remove them after the services  are restarted. Before you remove the logical volume first, it must be unmounted. If job IDs are reused or recycled and metadata on one or more of the bbServers already has  existing information about that job ID, a best practice is to remove that metadata by running  the following command: bbcmd removejobinfo –jobid If bbProxy does not start because of an existing UNIX socket file, remove the  bb.unixpath  file  from the configuration file. If you are using the provided configuration file or if the  bb.unixpath key is not found in the configuration file, this location is  /run/bb_socket . If bbServer’s metadata becomes stale or corrupted, you can recover it by stopping all  instances of bbProxy and bbServer and then removing the directory that is provided by the  bb.bbserverMetadataPath  key in the configuration file. All bbServers on the system must use  the same copy of the metadata as given by this key in the configuration file. If you use the  provided configuration file or if the  bb.bbserverMetadataPath  key is not found in the  configuration file, this location is  /gpfs/gpfs0/bbmetadata . If bbServer or bbProxy fail when attempting to bind to an address, double-check that a  bbServer or bbProxy process is not already running on the system. If no processes are found,  it is possible that Linux needs a couple of minutes before reclaiming the port. 158  IBM High-Performance Computing Insights with IBM Power System AC922 Clustered Solution 