CANT DELETE 730UC3

Hi I have recently upgraded our development and production boxes to UC5 (everything seems to be working fine so far). Over the last few months we've run into a few space issues on our production system, so to resolve those I went to delete the UC3 directory. On my development box it just deleted with the databases running and all by on my production box it won't delete. It seems that the following files are always busy even if I shutdown everything: lib/esql/libixsql.so lib/esql/libixgen.so lib/esql/libixos.so lib/esql/libixgls.so lib/esql/libixglx.so lib/libixasf.so Can someone tell me what these files reference as I must have a setting still pointing to UC3 and i just can't figure out what it would be. thanks Bridget

Bridget wrote: > I have recently upgraded our development and production boxes to UC5 > (everything seems to be working fine so far). > > Over the last few months we've run into a few space issues on our > production system, so to resolve those I went to delete the UC3 > directory. On my development box it just deleted with the databases > running and all by on my production box it won't delete. > > It seems that the following files are always busy even if I shutdown > everything: > > lib/esql/libixsql.so > lib/esql/libixgen.so > lib/esql/libixos.so > lib/esql/libixgls.so > lib/esql/libixglx.so > lib/libixasf.so > > Can someone tell me what these files reference as I must have a > setting still pointing to UC3 and i just can't figure out what it > would be. If those files are being referenced, then some program is still running and using those files. One plausible culprit is oninit; that would mean that the UC3 system is still running. Another not so plausible possible culprit would be sqlexecd, though this would normally only apply if you had been running SE and probably wouldn't use all those libraries. You don't indicate whether the path preceding lib/esql/libixsql.so is the $INFORMIXDIR for UC3 or for UC5 or somewhere else -- so I'm assuming that it is for UC3 and is distinct from UC5. If that assumption is wrong, then it could be that the UC5 software is accessing it. Also, depending on how you installed the UC5 software, it would be possible for symlinks in /usr/lib to be pointing to the UC3 installation instead of the UC5 installation, and that would readily lead to the symptoms you're seeing. A standard installation does not put symlinks to the libraries you list in /usr/lib, but doing so removes the need to set LD_LIBRARY_PATH or its equivalent on your (unidentified) platform. What's the difference between the development and the production platform? -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>

Bridget wrote: > > Hi > > I have recently upgraded our development and production boxes to UC5 > (everything seems to be working fine so far). > > Over the last few months we've run into a few space issues on our > production system, so to resolve those I went to delete the UC3 > directory. On my development box it just deleted with the databases > running and all by on my production box it won't delete. > > It seems that the following files are always busy even if I shutdown > everything: > > lib/esql/libixsql.so > lib/esql/libixgen.so > lib/esql/libixos.so > lib/esql/libixgls.so > lib/esql/libixglx.so > lib/libixasf.so > > Can someone tell me what these files reference as I must have a setting > still pointing to UC3 and i just can't figure out what it would be. Most UNIXes deliver a utility, /etc/fuser, which will tell you what processes have a particular file open. Try: /etc/fuser $INFORMIXDIR/lib/esql/libixsql.so Which should return a list of PIDs which have the file open. Art S. Kagel

Thanks - the path is /730UC3/lib/esql etc. There is only one distinct difference between our development box and the production one, that is the path the software is installed in but I have checked the enviroment variables and they are all set correctly. Bridget Jonathan Leffler wrote: > Bridget wrote: > > I have recently upgraded our development and production boxes to UC5 > > (everything seems to be working fine so far). > > > > Over the last few months we've run into a few space issues on our > > production system, so to resolve those I went to delete the UC3 > > directory. On my development box it just deleted with the databases > > running and all by on my production box it won't delete. > > > > It seems that the following files are always busy even if I shutdown > > everything: > > > > lib/esql/libixsql.so > > lib/esql/libixgen.so > > lib/esql/libixos.so > > lib/esql/libixgls.so > > lib/esql/libixglx.so > > lib/libixasf.so > > > > Can someone tell me what these files reference as I must have a > > setting still pointing to UC3 and i just can't figure out what it > > would be. > > If those files are being referenced, then some program is still > running and using those files. One plausible culprit is oninit; > that would mean that the UC3 system is still running. Another > not so plausible possible culprit would be sqlexecd, though this > would normally only apply if you had been running SE and probably > wouldn't use all those libraries. You don't indicate whether the > path preceding lib/esql/libixsql.so is the $INFORMIXDIR for UC3 > or for UC5 or somewhere else -- so I'm assuming that it is for > UC3 and is distinct from UC5. If that assumption is wrong, then > it could be that the UC5 software is accessing it. Also, depending > on how you installed the UC5 software, it would be possible for > symlinks in /usr/lib to be pointing to the UC3 installation instead > of the UC5 installation, and that would readily lead to the symptoms > you're seeing. A standard installation does not put symlinks to > the libraries you list in /usr/lib, but doing so removes the need > to set LD_LIBRARY_PATH or its equivalent on your (unidentified) > platform. > > What's the difference between the development and the production > platform? > > -- > Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN > #include <disclaimer.h>