Our root (/) partition is nearing 100% utilization and upon further investigation the wtmpx file is the main culprit. We need to trim or flush this file but we need to have a backup of this file for audit purposes.
We have a very large core file and we need this to send to our vendor for analysis. The gzip’d file of the core is 20GB and the FTP server of the vendor does not like that. Therefore we need to split our very large file to smaller chunks that the FTP server would accept.
We have to patch a Sun V480 and during the pre-tasks we have to check on the console of the box. To our surprise (or not) the console is hung. We have to reset the Remote System Console (RSC) for to be able to use it again. Here are the simple guide on how to reset the RSC thru the OS.
We have already discussed extending a filesystem in AIX under JFS as well as the basic of softpartion where we could also extend its filesystem size. This time we have a task which is under Veritas Volume Manager (VxVM). We need to extend a partition that is being managed by VxVM.
Solaris Volume Manager (SVM) formerly called as Online DiskSuite and Solstice Disk Suite (SDS) is a volume manager that comes with the standard installation of Solaris 8, 9, and 10. But soft partition functionality was not included on the first release of SDS on Solaris 8, but it could be added with patch 108693-06 (latest). Upon introduction of Solaris 9, soft partition is included in SVM as one of it’s functionality.
More often than not, we UNIX Administrators like our OS and data files have a good and trusted backup of all our files. But let us accept it there are really files or filesystems that really do not need to be backed up and they would just take up some space on our very expensive tapes (and of course backup time).
An application user asks to kill all the processes under their application account. When you checked on the box itself you saw a lot of processes and killing them one by one would take forever.
Hey, what do we have a here? The df command says that our filesystem is 100% but after thorough examination you see that the filesystem is almost empty. This is caused by applications (most of the times poorly coded) which are still hogging the space that was originally used by the deleted file.