In NetBackup appliance 3.x a new startup solution was introduced.
Previously SysV scripts started sequentially, where SystemD starts services in parallel.
This highlighted a timing issue for services that are dependent on a mount point that belongs to a VxVM device.
nbuapp_sf: - [Error] Failed to mount the 'MSDP' partition '0'.
vxvm-fstab-automount: VxVM: Auto-mount of /dev/vx/dsk/nbuapp/pdvol on /msdp/data/dp1/pdvol failed!
hostname umount: UX:vxfs umount.vxfs: ERROR: V-
: cannot umount /msdp/data/dp1/pdvol: Device or resource busy
- Udev integration is needed to register the /dev/vx/dsk/<dg>/<volume> back to systemd
- VxVM requires the udev daemon to re-read the udev rules after VxVM has fully started up
- There is a requirement to create service dependencies by adding a order-after-vxvm.conf entry into /etc/systemd/system/service.service.d
- Modify the remote-fs-pre.target so that it has a dependency on vxvm-boot.service
- SystemD default timeout of 90 seconds is insufficient time to allow for veritas services to startup and the devices to be made available via UDEV
- VEKI startup script does not include a LSB header, newer versions of systemd set the dependency order for the veki startup script to start after vxvm
- VxVM startup script has a dependency on the following services "iscsi iodrive raw" which means vxvm will start later and after the operating system has probed all devices
- The "nofail" attribute for Veritas VxVM devices in /etc/fstab causes a shutdown issue for others systemD services that are dependent on the VxFS filesystem
- Systemd-udevd: inotify_add_watch(7, /dev/VxDMP[X], failed: No such file or directory messages in the journal/messages log
- systemd-fsck reports the following messages "systemd-fsck[xxxx]: UX:vxfs fsck.vxfs: ERROR: V-3-20113: Cannot open: No such device or address"
- VxVM has an additional 2 minute sleep to wait for infiniband devices to become available. this can create an addtional delay if you are not using these devices in your environment
- With the native systemd services for VeKI.service and VxFS.service we have simplified the dependency order
- SystemD VxFS .mount units may reach the systemD default timeout and processes called by mount can be subsequently killed
- Volumes that are under an RVG will report IO error as the RVG has not yet be enabled/active
- Systemd-fsck@[xxx] start failed with result 'dependency'
- The netbackup service may fail if VxVM volumes are not yet available
NetBackup service initialization may fail if VxVM services have not yet started.
This HotFix will add a systemD generator script which adds each mount point from the 'nbuapp' disk-group in the correct dependency order.
This HotFix is available here
These volumes are defined via the “nbu_vols” attribute in the /etc/vx/systemd/system.conf file.
This will mitigate issues identified above which pertain to the startup and shutdown sequence.
Was this content helpful?
Rating submitted. Please provide additional feedback (optional):