The file ttys might be corrupt. This file is located in: /etc/auth/system
If the date and time of the file doesn't equal the last login, then it's corrupt. A rough way to fix this, is to empty the file. It will build up itself again.
So a simple: > ttys
will do the job.
Greetz, Wim. Please...
This article has been very helpfull to me:
http://wdb1.sco.com/kb/showta?taid=109467&qid=1561009252&sid=241005517&pgnum=1
Greetz, Wim. Please remember, The Netherlands is in a different timezone.
You can check in the /etc/profile by puting in something like this:
USERNAAM=`logname`
LOGS=`who|grep $USERNAAM|wc -l`
if [ $LOGS -gt "1" ] && [ $USERNAAM != "root" ]
then
echo "
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!This user is already logged on ...
Problem with the permissions is probably on a higher level, /usr/spool/lp. You might want to try /etc/fixperm to fix it. For the good use: man fixperm
Greetz, Wim. Please remember, The Netherlands is in a different timezone.
Maybe this link can be of any use:
http://wdb1.sco.com/kb/showta?taid=107582&qid=693892833&sid=1997508217&pgnum=1
Greetz, Wim. Please remember, The Netherlands is in a different timezone.
Not familiar with Unixware but had same sort of problem in Openserver once. Do you have a tcp-wrapper activ? You might want to look for a /etc/hosts.allow and /etc/hosts.deny
Greetz, Wim. Please remember, The Netherlands is in a different timezone.
In the /usr/spool/lp/admins/lp/interfaces/{printername} you might want to add the option -N at line 75:
if $REALMODEL "$@" | $HPNPF -x $PERIPH -N 2> $LOG > /dev/null
This option takes care for CR/LF when printing directly from the OS.
In...
I don't know if it's available under OpenServer 6.0 but in the version 5.0x, my favorite was:
dfspace
Greetz, Wim. Please remember, The Netherlands is in a different timezone.
It's definitly worth trying. In our case we just replaced the card by a 3com (money doesn't matter) So, I can't tell you if replacing the driver is sufficiant.
But this is the combination (card & driver) I was refering to yes. You don't have problems with telnet or other small packets but when...
Maybe you can find something on de SCO system using:
llistat -l
Is the slow system a HP server? If it is, what driver did you use for the NIC? There is a problem with the HP 10/100 driver. Had the same problem with a HP server and changed the NIC with a 3Com and the problem was solved.
Strange, your load average seems normal but your disks and processor are put to the max. If there hasn't been any updates in your application software, i would say the system has got a hardware problem.
You might want to check the hard-disks to start with. A bad disk can really slow the system...
In the EFS 5.770a from the HP site is a disk with Btld's. It includes the lsil and hpsas. These are usefull for loading sco 5.07 on a Proliant G4 or G5 server which contains a sata controler.
You can redirect your active crontab by:
#cd /tmp
#crontab -l > cronfile
Now you can edit (vi) cronfile, make your modifications and then activate it by:
#crontab cronfile
You can check if it's active by:
#crontab -l
No reboot required.
You're using this scirpt at another location. Is it working there? Did you make a copy to this location?
If so, it might be that syn isn't an executable anymore.
When you use ./ the file has to have the +x permissions.
If it hasn't, you can set them by:
#chmod +x syn
Have had the same problem once. The protections weren't right. They have to be as mentioned above.
You set them straight by:
#chmod 664 /etc/passwd
#chown bin:auth /etc/passwd
Good luck
I agree with motoslide. The hpnp is a better option, allthough you probably already used it, seen the fact there's a hpnpcfg.log in the /tmp
Default for hpnp and most printer servers is port 9100 but you can change it in the interface file with the option
-p3100 (port1) -p3101 (port2) and...
This message wasn't followed by a physical drive failure?
Maybe start the system with the Compaq smartstart cd and examine the disk by the ACU utility. This might give you some more information.
If your using the hpnpf then you can send a print job and look in the /tmp for a file named like hpnpf.<number>
This file might give you the reason why it's not printing.
Are you using a HP printer on port 3? Do you get a reply on a telnet to the print server on port 9102?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.