The command ps -ef shows a number of vxnotify processes, at times in hundreds:
# ps -ef | grep -i vxnotify | wc -l
207
root 6033 5962 0 16:20 pts/1 00:00:00 vxnotify -m -S -w 150
root 6043 5961 0 16:20 pts/1 00:00:00 vxnotify -T -f -w 15
root 6139 5963 0 16:20 pts/1 00:00:00 vxnotify -C -w 15
root 7522 5966 0 16:20 pts/1 00:00:00 vxnotify
root 8687 8638 0 16:21 pts/1 00:00:00 vxnotify -T -f -w 15
root 8734 8640 0 16:21 pts/1 00:00:00 vxnotify -m -S -w 150
root 8768 8641 0 16:21 pts/1 00:00:00 vxnotify -C -w 15
root 9868 8644 0 16:21 pts/1 00:00:00 vxnotify
root 18633 5928 0 16:23 pts/1 00:00:00 grep vxnotify
root 23000 22987 0 Mar16 ? 00:00:00 vxnotify -T -f -w 15
root 23036 23020 0 Mar16 ? 00:00:00 vxnotify -C -w 15
root 23741 23727 0 Mar16 ? 00:00:00 vxnotify -m -S -w 150
root 23781 23060 0 Mar16 ? 00:00:00 vxnotify
[...]
#
Customers may run /sbin/service --status-all command to check the status of various services in the Linux system. This command, in Linux checks the status of all services by running every startup script in the system with status option. The /etc/init.d/vxvm-recover script doesn't have the status option and instead starts the services again. Thus /bin/sh /etc/init.d/vxvm-recover status command starts vxrelocd, vxattachd, vxcached, vxconfigbackupd and vxvvrsecdgd daemons again, which in-turn spawns multiple vxnotify processes.
The current /etc/init.d/vxvm-recover script does not check if the process that is being started is already running (in this case, vxrelocd, vxattachd, vxcached, vxconfigbackupd and vxvvrsecdgd) prior to starting it again. This results in multiple vxnotify processes being started.
Veritas is enhancing the startup scripts to make them compliant to Linux Standard Base (LSB)
This is fixed in the following VxVM releases in Linux.
VxVM 5.0MP4RP1P1
VxVM 5.1SP1RP2