일단...
cas process 잔당을 처리해 주십시요^^
흠...잔당 처리하기가 쉽지 않던데...
ipcs를 치시면...
거기 shared memory를 잡고 있는 유저가 나올겁니다...
물론 root로 ipcs를 실행하시고...
'iprm -m 해당 id'를 실행해서~ 아직 잡고있는 shared 메모리를 정리합니다.
그리고 나서 다시 uc stop ; uc start 하시면 정상적으로 수행 될 듯합니다.^^

이건 제가 좀(?) 압니다. cubrid_cas란 놈은 shared memory기반으로 broker와 cas(db client)간에 통신을 합니다. 이때 중요한 것이 cubrid_cas.conf에 있는 shared memory id입니다. 여기에 master_shm_id란 놈과 브로커별로 appl_server_shm_id란 놈이 있는데, 이 ID값은 해당 서버의 shared memory에서 유일(unique)하게 존재해야 합니다.  ipcs란 명령을 수행해보면 해당서버의 shared memory현황을 볼 수 있습니다. 

대략 이렇게 생깁니다. 
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00040001 721518602  cubrid    644        1888       2                      
0x00040000 721551371  cubrid    644        100552     101                    
0x00043000 721584140  cubrid    644        59752      6  

여기에서 구동시킨 owner와 key값을 보시면 어떤 브로커에 대한 값인지 알 수 있습니다. key값으로 출력되는 숫자는 cubrid_cas.conf에서 설정한 shm_id 인것을 확인 할 수 있음^^

상황설명은 이쯤하고 해결책을 찾아보면;
1. cubrid_service나 uc 명령을 통해 start시킨 계정과 stop시키는 계정이 다른지 확인. 물론아니겠지만^^

2. cubrid_cas.conf에 이미 사용중인 shared memory id 값을 설정한 것은 아닌지... 위에서 언급한 ipcs로 확인할 수 있음.

3. 원인파악은 그정도에서 하면 될 것이고, 실제 상황을 종료하려면, ps-ef | grep cas 와 ps -ef | grep broker로 나오는 프로세스를 모두 죽인다 (kill -9)

해당 프로세스 ID를 일괄로 가져오는 방법은 ps -ef|grep cubrid | grep cas |awk '{print $2}'를 통해 확인할 수 있음.

4. 그리고 ipcs를 통해 shmid 값을 확인한 후 ipcrm -m "shmid" 라는 명령어로 제거해 주면 됩니다. 

그리고 uc start해주면 됩니다.