Telnet and "who" problem
Alan Maul
logout and disconnect, "who" still show that pseudo device as logged
in. The symptom gets better if we disconnect and then reconnect and
have the login displayed when we shut Procomm down, but about 10 percent
of the time we still have the problem.
Are there any suggestions as to what I might do to fix the who problem?
or what a better procedure to follow would be to clear the speudo
devices?
Charles Regalia
It's that utmp/wtmp/utmpx/wtmpx horror that SCO introduced a few years ago.
Did you notice that if you dial out from your SCO host that you will lose
the ability to dial out again until you go through their fix ritual which
includes a reboot. That's right, one call out allowed per boot because of
the login log corruption.
The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
and MSDOS 3.0 or higher.
Charles V. Regalia
us02...@mindspring.com
301-855-0523
John DuBois
>>
>> We are using ProcommPlus 32 to Telnet into SCO Unix v5.0.4. When we
>> logout and disconnect, "who" still show that pseudo device as logged
>> in. The symptom gets better if we disconnect and then reconnect and
>> have the login displayed when we shut Procomm down, but about 10 percent
>> of the time we still have the problem.
>>
>> Are there any suggestions as to what I might do to fix the who problem?
>> or what a better procedure to follow would be to clear the speudo
>> devices?
This occurs when your /etc/auth/system/ttys file has become corrupt, typically
as a result of a bad shutdown (though you may not notice the problem until much
later). Search the TA database for the filename above.
Charles Regalia <us02...@mindspring.com> wrote:
>Did you notice that if you dial out from your SCO host that you will lose
>the ability to dial out again until you go through their fix ritual which
>includes a reboot. That's right, one call out allowed per boot because of
>the login log corruption.
This is off-the-wall enough that I can't even guess what your real problem is.
If you describe the symptoms more carefully, someone here may be able to help
you.
John
--
John DuBois spc...@armory.com. KC6QKZ http://www.armory.com./~spcecdt/
Tony Lawrence
>
> It's that utmp/wtmp/utmpx/wtmpx horror that SCO introduced a few years ago.
> Did you notice that if you dial out from your SCO host that you will lose
> the ability to dial out again until you go through their fix ritual which
> includes a reboot. That's right, one call out allowed per boot because of
> the login log corruption.
>
> The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
> and MSDOS 3.0 or higher.
What a maroon.
Sheesh. "One call out per boot". Boopy, I don't know what your problem
is, I don't even know what you *think* your problem is, but I assure you
that my SCO machine can dial out, disconnect, dial out again, disconnect
and so on all damn day long. Secondly, dialing out has nothing to do
with login and finally none of your blather has anything to do with
telnet. So your misinformed, confused, and inaccurate "advice" is worth
crapola.
Personally I'd be happy to see dopes like you concentrate on MSDOS 3.0.
On the infinitesimal chance that this nonsense has some relation to
anything real, you might try explaining what you mean in a more
intelligent fashion, and then perhaps some of us could offer you some
assistance in taming the machine that has apparently given you some
problems.
--
Tony Lawrence (to...@aplawrence.com)
SCO ACE
SCO articles, help, book reviews: http://www.aplawrence.com
Charles Regalia
> This occurs when your /etc/auth/system/ttys file has become corrupt, typically
> as a result of a bad shutdown (though you may not notice the problem until much
> later). Search the TA database for the filename above.
Sorry John, this is not the only cause. Search the TA database.
> This is off-the-wall enough that I can't even guess what your real problem is.
> If you describe the symptoms more carefully, someone here may be able to help
> you.
Doubt it. SCO has been unable to fix this for years now. If you want to see
the failure, telnet or rlogin to a SCO v5.0.[2-4] and dial out. Now report
the failure to SCO.
Charles Regalia
> What a maroon.
When did SCO start color coding PTs. ?
> Sheesh. "One call out per boot". Boopy, I don't know what your problem
> is, I don't even know what you *think* your problem is, but I assure you
> that my SCO machine can dial out, disconnect, dial out again, disconnect
> and so on all damn day long. Secondly, dialing out has nothing to do
> with login and finally none of your blather has anything to do with
> telnet. So your misinformed, confused, and inaccurate "advice" is worth
> crapola.
Wrong. You can't dial out if the port is left in use because of the way SCO
corrupts the login log.
> Personally I'd be happy to see dopes like you concentrate on MSDOS 3.0.
Anyone trying to use SCO as a reliable platform is a dope. Fortunately we
have other choices.
> On the infinitesimal chance that this nonsense has some relation to
> anything real, you might try explaining what you mean in a more
> intelligent fashion, and then perhaps some of us could offer you some
> assistance in taming the machine that has apparently given you some
> problems.
Maybe I can simplify it for you. Steps:
(1) Telnet or rlogin to a SCO v5.0.[2-4] system.
(2) Verify the plethera of bug fixes from SCO have been applied.
(3) Dial out to another System.
(4) Terminate the dial out connection.
(5) Try to dial out again.
(6) Report the failure to SCO.
(7) Apply the fixup ritual from the TA addressing the wtmp/utmp
corruption.
(8) Reboot if you need to dial out again.
If you need further simplification, I might be able to further break down
these steps.
Jean-Pierre Radley
| Alan Maul wrote:
| >
| > We are using ProcommPlus 32 to Telnet into SCO Unix v5.0.4. When we
| > logout and disconnect, "who" still show that pseudo device as logged
| > in. The symptom gets better if we disconnect and then reconnect and
| > have the login displayed when we shut Procomm down, but about 10 percent
| > of the time we still have the problem.
| >
| > Are there any suggestions as to what I might do to fix the who problem?
| > or what a better procedure to follow would be to clear the speudo
| > devices?
|
| Did you notice that if you dial out from your SCO host that you will lose
| the ability to dial out again until you go through their fix ritual which
| includes a reboot. That's right, one call out allowed per boot because of
| the login log corruption.
|
| The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
| and MSDOS 3.0 or higher.
I dial out several times a day from OSR 5.0.5, and did so under 5.0.4,
5.0.2, and 5.0.0. I've never seen any need to reboot because I dialed
out.
Please put some evidence on the table, or don't play.
--
Jean-Pierre Radley <j...@jpr.com> XC/XT Custodian Sysop, CompuServe SCOForum
Jean-Pierre Radley
| Doubt it. SCO has been unable to fix this for years now. If you want
| to see the failure, telnet or rlogin to a SCO v5.0.[2-4] and dial out.
| Now report the failure to SCO.
Well, I did that just this morning. Telnet from a laptop running OSR
5.0.5 to my main machine also running OSR 5.0.5 in order to dial out from
the main machine.
Neither machine has been rebooted in a week, and I've since dialed out
from the main machine more than once.
You're still a maroon.
Tony Lawrence
>
> Maybe I can simplify it for you. Steps:
>
> (1) Telnet or rlogin to a SCO v5.0.[2-4] system.
Check. 3.2v5.0.4. Telnet, because I don't allow rlogin. Actually, I
don't allow telnet either, but I turned it on just for you.
> (2) Verify the plethera of bug fixes from SCO have been applied.
Plethora? RS504C is a plethora? Never mind..
> (3) Dial out to another System.
OK. I have to take my ppp connection down.. all right, now a manual cu
to the same ISP. Connected, logged in.
> (4) Terminate the dial out connection.
Terminate how? Do you mean logout or kill it or shutoff the modem? I
tried logging out first..cute, ppphooks.sh runs. Wonder why? Oh, well,
unimportant. Maybe it was just delayed from the ifconfig ppp0 down..
> (5) Try to dial out again.
OK. No problem. Logged in again.
> (6) Report the failure to SCO.
What failure? I'm logged in to the ISP on a cu.
OK, let's try just shutting off the modem instead. Same thing, no
problem. Dial out Yet Again. Boring, Charles, very very boring.
Furthermore, once I'm done wasting time with this foolishness, my
dynamic ppp comes right back up again, which is another dialout. So
where's the problem again?
> (7) Apply the fixup ritual from the TA addressing the wtmp/utmp
> corruption.
I don't have any wtmp/utmp corruption to fix.
> (8) Reboot if you need to dial out again.
No need yet.
>
> If you need further simplification, I might be able to further break down
> these steps.
Sure, break it down some more. Maybe somebody else will have the
patience to work with you on it. I sure as hell don't.
Understand that I am in no way saying that you don't have a problem.
I'm sure YOU have this problem. If you think you've seen it on other
machines, it may even be something that can be reproduced with the
proper mix of hardware, software, stupidity and luck. But I can tell
you that it's a fair bet that I've worked with and on more SCO machines
than you have, and I haven't seen this. That doesn't mean it doesn't
exist, of course.
But your blatant insistence that this is an omnipresent issue is, as I
said before, malarkey. Maybe you should keep playing with your DOS
machine until you are ready to run this big awful SCO box..
Joe Scholz
Set your AT&D(X) correctly on your modem string and you won't have these
problems.
Duh!
Joe Scholz
Charles Regalia wrote in message <36E80568...@mindspring.com>...
>Tony Lawrence wrote:
>> What a maroon.
>
>When did SCO start color coding PTs. ?
>
>
>> Sheesh. "One call out per boot". Boopy, I don't know what your problem
>> is, I don't even know what you *think* your problem is, but I assure you
>> that my SCO machine can dial out, disconnect, dial out again, disconnect
>> and so on all damn day long. Secondly, dialing out has nothing to do
>> with login and finally none of your blather has anything to do with
>> telnet. So your misinformed, confused, and inaccurate "advice" is worth
>> crapola.
>
>Wrong. You can't dial out if the port is left in use because of the way SCO
>corrupts the login log.
>
>
>> Personally I'd be happy to see dopes like you concentrate on MSDOS 3.0.
>
>Anyone trying to use SCO as a reliable platform is a dope. Fortunately we
>have other choices.
>
>
>> On the infinitesimal chance that this nonsense has some relation to
>> anything real, you might try explaining what you mean in a more
>> intelligent fashion, and then perhaps some of us could offer you some
>> assistance in taming the machine that has apparently given you some
>> problems.
>
>Maybe I can simplify it for you. Steps:
>
> (1) Telnet or rlogin to a SCO v5.0.[2-4] system.
> (2) Verify the plethera of bug fixes from SCO have been applied.
> (3) Dial out to another System.
> (4) Terminate the dial out connection.
> (5) Try to dial out again.
> (6) Report the failure to SCO.
> (7) Apply the fixup ritual from the TA addressing the wtmp/utmp
>corruption.
> (8) Reboot if you need to dial out again.
>
> If you need further simplification, I might be able to further break down
> these steps.
>
>
John DuBois
Charles Regalia <us02...@mindspring.com> wrote:
>John DuBois wrote:
>
>> This occurs when your /etc/auth/system/ttys file has become corrupt, typically
>> as a result of a bad shutdown (though you may not notice the problem until much
>> later). Search the TA database for the filename above.
>
>Sorry John, this is not the only cause. Search the TA database.
The TA in question is, unfortunately, rather confused and is wrong on several
points.
The only commonly-occuring problem that causes the widely described symptom of
"who" reporting on users who are not actually logged in and who have no active
processes (often being misinterpreted as "unkillable" users) is the corruption
of the /etc/auth/system/ttys file. This occurs because the ttys file is an
extremely active file, and therefore exceptionally subject to the filesystem
corruption that can occur when the system is shut down badly. The other
possibilities mentioned in the TA do not result in this behaviour.
>> This is off-the-wall enough that I can't even guess what your real problem is.
>> If you describe the symptoms more carefully, someone here may be able to help
>> you.
>
>Doubt it. SCO has been unable to fix this for years now. If you want to see
>the failure, telnet or rlogin to a SCO v5.0.[2-4] and dial out. Now report
>the failure to SCO.
I've dialed out from my 5.0.4 system daily for more than a year, sometimes
while remotely logged in. I do not shut down between dialouts. I have yet to
experience such a failure. It is really very likely that the problem you're
experiencing can be resolved.
John DuBois
Charles Regalia <us02...@mindspring.com> wrote:
>Wrong. You can't dial out if the port is left in use because of the way SCO
>corrupts the login log.
What do you mean by "left in use"?
Also, whatever the source of this problem is, it is a near-certainty that it
has nothing to do with the utmp/wtmp/ttys file corruption problem.
> (4) Terminate the dial out connection.
Terminate in what manner?
> (7) Apply the fixup ritual from the TA addressing the wtmp/utmp corruption.
> (8) Reboot if you need to dial out again.
Try rebooting *without* the "fixup ritual" - I think you've gotten sidetracked
by the utmp problem.
Charles Regalia
> Furthermore, once I'm done wasting time with this foolishness, my
> dynamic ppp comes right back up again, which is another dialout. So
> where's the problem again?
>
> > corruption.
>
>
Which is why your dial out works. Ask SCO what bug it is that causes the
corruption so you can reproduce the failure.
> Understand that I am in no way saying that you don't have a problem.
> I'm sure YOU have this problem. If you think you've seen it on other
> machines, it may even be something that can be reproduced with the
> proper mix of hardware, software, stupidity and luck. But I can tell
> you that it's a fair bet that I've worked with and on more SCO machines
> than you have, and I haven't seen this. That doesn't mean it doesn't
> exist, of course.
Of course, because it does exit. Let's put some money on your fair bet.
> But your blatant insistence that this is an omnipresent issue is, as I
> said before, malarkey. Maybe you should keep playing with your DOS
> machine until you are ready to run this big awful SCO box..
The failure is omnipresent on all SCO systems that have the bug and on
which the sequence of events that cause the bug are followed. SCO knows
what it is because they have fixed it 5.0.5 but they have not released a
patch
for earlier versions that address the bug.
Charles Regalia
>
> Charles, Here a tip:
>
> Set your AT&D(X) correctly on your modem string and you won't have these
> problems.
>
> Duh!
The modem string has nothing to do with the lock file created. I think SCO
offers some training classes. You need to attend some.
Charles Regalia
> What do you mean by "left in use"?
Left in use.
> Terminate in what manner?
Think about the context and consult Webster.
> Try rebooting *without* the "fixup ritual" - I think you've gotten sidetracked
> by the utmp problem.
Nope, a reboot without the fixup ritual does not solve the problem. The utmp
problem is the problem. The reboot is part of the ritual.
Charles Regalia
> Please put some evidence on the table, or don't play.
It's not a game to me. Unfortunately, it is to SCO.
--
Thank you,
Charles Regalia
> Well, I did that just this morning. Telnet from a laptop running OSR
> 5.0.5 to my main machine also running OSR 5.0.5 in order to dial out from
> the main machine.
>
> Neither machine has been rebooted in a week, and I've since dialed out
> from the main machine more than once.
>
> You're still a maroon.
No one ever claimed it fails on 5.0.5. Do you ever actually read these
postings
or just spend your time watching cartoons ?
Charles Regalia
> The TA in question is, unfortunately, rather confused and is wrong on several
> points.
> The only commonly-occuring problem that causes the widely described symptom of
> "who" reporting on users who are not actually logged in and who have no active
> processes (often being misinterpreted as "unkillable" users) is the corruption
> of the /etc/auth/system/ttys file. This occurs because the ttys file is an
> extremely active file, and therefore exceptionally subject to the filesystem
> corruption that can occur when the system is shut down badly. The other
> possibilities mentioned in the TA do not result in this behaviour.
John, you seem to be serious so I'll treat your response as such. Although
the
problem of phantom users reported by "who" is what gets reported widely, it
is not
the only consequence of the bug. The versions of the SCO OS that have the
bug
will continually create the lock file on the dialout port when the 'phantom'
user
was using the dial out port. The have apparently fixed it in 5.0.5.
> I've dialed out from my 5.0.4 system daily for more than a year, sometimes
> while remotely logged in. I do not shut down between dialouts. I have yet to
> experience such a failure. It is really very likely that the problem you're
> experiencing can be resolved.
It happens much less frequently in 5.0.4 because the corruption happens much
less
frequently. Back when I first developed our work arounds, I believed that
the problem was releated to that strange Advanced File/Print Server package,
only because I never saw it on systems that didn't have it installed.
John DuBois
Charles Regalia <us02...@mindspring.com> wrote:
>John DuBois wrote:
>
>> What do you mean by "left in use"?
>
>Left in use.
>
>
>> Terminate in what manner?
>
>Think about the context and consult Webster.
Well, it's clear from this that an excuse to continue your misdirected ragging
on SCO is far more important to you than actually seeing your problem resolved.
Given that your responses to any questions asked of you by SCO's tech support
were undoubtedly similarly pointedly useless, it's hardly a wonder that they
weren't able to help you either.
A final, futile attempt at a clue:
I am more familiar with the problem of stale utmp entries (aka 'ghost users')
on SCO systems than any other person on earth. It is NOT the source of your
dialout problem. The pattern you saw that made it look like they are related
deceived you. It happens. If you could find it within yourself to take a peek
outside this blind alley, your problem would likely be resolved in short order.
Sadly, it is apparent that the probability of this happening is excruciatingly
low.
Tony Lawrence
> The failure is omnipresent on all SCO systems that have the bug and on
> which the sequence of events that cause the bug are followed. SCO knows
> what it is because they have fixed it 5.0.5 but they have not released a
> patch
> for earlier versions that address the bug.
Omigod.
And diabetes is omnipresent in all French speaking people who have
diabetes.
Charles, you are a *grand* maroon.
More than one of us here have told you that this supposed "bug" does not
exist on our systems and that we haven't seen it on our clients
systems. As some of the people telling you this have been involved with
literally thousands of SCO systems, your data points begin to look
pretty pathetic.
We followed your instructions; our systems don't fail. What does that
tell you?
Oh, of course: that WE are idiots.
>
> Which is why your dial out works. Ask SCO what bug it is that causes the
> corruption so you can reproduce the failure.
Now there's a brilliant suggestion. Because the Grand Maroon Charles
has a screwed up system or two, it must be EVERYWHERE. SCO sucks,
because the Grand Maroon says so. When I and others show you that WE
don't have this problem, the Grand Maroon back-pedals:
> It happens much less frequently in 5.0.4 because the corruption happens much
> less frequently.
And then he condescends to advise:
> No one ever claimed it fails on 5.0.5.
But before this the Grand Maroon sang a different tune of useless
machines and omnipresent problems. Let's see, what was it? Oh, yeah:
> Doubt it. SCO has been unable to fix this for years now.
Except the Grand Maroon forgot to mention that it is fixed in 5.0.5?
> If you want to see
> the failure, telnet or rlogin to a SCO v5.0.[2-4] and dial out. Now report
> the failure to SCO.
But we have no failures. Earlier, the Grand Maroon told us:
> The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
> and MSDOS 3.0 or higher.
Or, apparently, 5.0.5. Thank you, Oh Grand Maroon, Disseminator of
Useless Knowledge, Master of All Things Unix, Tamer of AFPS, Rebooter of
Machines: we are not worthy. Your shining pearls of wisdom fall among
the swine and are trampled into the mud. The bug EXISTS, you cry, the
Emperor has no clothes! And we lowly fools mock you, and fail to
terminate our sessions improperly enough, or have Advanced Versions that
do not suit your needs. Alas, the Grand Maroon is lonely, misunderstood
as all Great Men are, unappreciated, even ridiculed. He knows SCO
sucks, and we do not.
Again, I have no doubt that you have experienced this problem. I'm even
willing to believe momentarily that it might be related to utmp/wtmp
corruption. I'll even stretch it and grant that on certain specific
releases in certain specific configurations, this might even be
reproducible. However, it is NOT the far reaching, omnipresent horror
that your previous rantings imply, and if you weren't such a jerk,
people here might even be able to help you fix it, though I suspect the
window of opportunity for that may have passed.
Stephen Davies
NEVER, repeat NEVER come across the problem that you discribe.
Since Open server 5 was released I have had only 3 occations of a corrupt
ttys database, and that was caused by incorrect shutdown of the servers.
This is among the some 500 Open server 5 clients my company has out there.
My server has been up for over 250 days without a shutdown, and I am doing
EXACTLY as you stated without a problem. I must call out to customers at
least 10 times a day, that is approximately 1800 calls (just in case you are
an idiot with mathmatics as well - 250 days is approximately 180 work days,
180 x 10 = 1800).
I have had 5.0.0, 5.0.2 and 5.0.4 on this server and ever come across the
problem.
Guys, I think no matter what we say to Charles, he is not going to beleive
us. Just look at what he says about the excessive number of Operating
system patches for SCO, but openly recommends an operating system such as
linux which has patches released daily, or even a commercial system like
Solaris which went from 2.0 to 2.5 with some 10 releases between in less
than 2 years.
Just ignore him he will soon go away.
Stephen Davies
SCO ACE
Charles Regalia wrote in message <36E957A3...@mindspring.com>...
>Jean-Pierre Radley wrote:
>
>> Please put some evidence on the table, or don't play.
>
>It's not a game to me. Unfortunately, it is to SCO.
>
>
>--
>Thank you,
>
>
Charles Regalia
> Charles, you are a *grand* maroon.
>
> More than one of us here have told you that this supposed "bug" does not
> exist on our systems and that we haven't seen it on our clients
> systems. As some of the people telling you this have been involved with
> literally thousands of SCO systems, your data points begin to look
> pretty pathetic.
>
> We followed your instructions; our systems don't fail. What does that
> tell you?
> Oh, of course: that WE are idiots.
Don't be so hard on yourself. Your just inexperienced.
> > Which is why your dial out works. Ask SCO what bug it is that causes the
> > corruption so you can reproduce the failure.
>
> Now there's a brilliant suggestion. Because the Grand Maroon Charles
> has a screwed up system or two, it must be EVERYWHERE. SCO sucks,
> because the Grand Maroon says so. When I and others show you that WE
> don't have this problem, the Grand Maroon back-pedals:
I offered a bet. Any takers ?
> > It happens much less frequently in 5.0.4 because the corruption happens much
> > less frequently.
>
> And then he condescends to advise:
???
> > No one ever claimed it fails on 5.0.5.
>
> But before this the Grand Maroon sang a different tune of useless
> machines and omnipresent problems. Let's see, what was it? Oh, yeah:
> > Doubt it. SCO has been unable to fix this for years now.
>
> Except the Grand Maroon forgot to mention that it is fixed in 5.0.5?
It has existed in 5.0.[2-4] for years. Still exists in 5.0.[2-4]. Most
likely
will always exist in 5.0.[2-4].
> Or, apparently, 5.0.5. Thank you, Oh Grand Maroon, Disseminator of
> Useless Knowledge, Master of All Things Unix, Tamer of AFPS, Rebooter of
> Machines: we are not worthy. Your shining pearls of wisdom fall among
> the swine and are trampled into the mud. The bug EXISTS, you cry, the
> Emperor has no clothes! And we lowly fools mock you, and fail to
> terminate our sessions improperly enough, or have Advanced Versions that
> do not suit your needs. Alas, the Grand Maroon is lonely, misunderstood
> as all Great Men are, unappreciated, even ridiculed. He knows SCO
> sucks, and we do not.
Chill Tony, The bug is in SCO software. It is not your fault. It is just
fact.
> Again, I have no doubt that you have experienced this problem. I'm even
> willing to believe momentarily that it might be related to utmp/wtmp
> corruption. I'll even stretch it and grant that on certain specific
> releases in certain specific configurations, this might even be
> reproducible. However, it is NOT the far reaching, omnipresent horror
> that your previous rantings imply, and if you weren't such a jerk,
> people here might even be able to help you fix it, though I suspect the
> window of opportunity for that may have passed.
Signs of hope for you. It is a bug related to utmp/wtmp corruption. It is
100%
reproducible.
The only people who post to this group that can be helpful are those that
have
access to the information.
Charles Regalia
> Well, it's clear from this that an excuse to continue your misdirected ragging
> on SCO is far more important to you than actually seeing your problem resolved.
> Given that your responses to any questions asked of you by SCO's tech support
> were undoubtedly similarly pointedly useless, it's hardly a wonder that they
> weren't able to help you either.
Sorry I misled you but the problem is resolved. We work around it and
absolutely don't care whether SCO musters enough pride to fix their bugs.
> A final, futile attempt at a clue:
> I am more familiar with the problem of stale utmp entries (aka 'ghost users')
> on SCO systems than any other person on earth. It is NOT the source of your
> dialout problem. The pattern you saw that made it look like they are related
> deceived you. It happens. If you could find it within yourself to take a peek
> outside this blind alley, your problem would likely be resolved in short order.
> Sadly, it is apparent that the probability of this happening is excruciatingly
> low.
Too bad you don't consult to SCO, they might fix it.
Charles Regalia
>
> Are you for real. I have been supporting SCO systems for 13 years and have
> NEVER, repeat NEVER come across the problem that you discribe.
OSE 5 has not been available for 13 years. Perhaps your thinking of Xenix.
> Since Open server 5 was released I have had only 3 occations of a corrupt
> ttys database, and that was caused by incorrect shutdown of the servers.
> This is among the some 500 Open server 5 clients my company has out there.
>
> My server has been up for over 250 days without a shutdown, and I am doing
> EXACTLY as you stated without a problem. I must call out to customers at
> least 10 times a day, that is approximately 1800 calls (just in case you are
> an idiot with mathmatics as well - 250 days is approximately 180 work days,
> 180 x 10 = 1800).
>
> I have had 5.0.0, 5.0.2 and 5.0.4 on this server and ever come across the
> problem.
Do you update the 500 clients when SCO issues their releases. Techniques on
mitigating the cost of doing that would be real useful.
> Guys, I think no matter what we say to Charles, he is not going to beleive
> us. Just look at what he says about the excessive number of Operating
> system patches for SCO, but openly recommends an operating system such as
> linux which has patches released daily, or even a commercial system like
> Solaris which went from 2.0 to 2.5 with some 10 releases between in less
> than 2 years.
I believe that if you don't install or use the software that causes the
problem, then you won't observe the problem. If you do install the package
that has the bug, SCO will not help you to find the cause.
Tony Lawrence
: Tony Lawrence wrote:
: > We followed your instructions; our systems don't fail. What does that
: > tell you?
: > Oh, of course: that WE are idiots.
: Don't be so hard on yourself. Your just inexperienced.
Well, at least *that* was a good laugh to start my day with :-)
--
Tony Lawrence (to...@aplawrence.com)
SCO Articles, Tips, Book Reviews: http://www.aplawrence.com
Tony Lawrence
> I believe that if you don't install or use the software that causes the
> problem, then you won't observe the problem. If you do install the package
> that has the bug, SCO will not help you to find the cause.
Package? This is the first time you've mentioned that, Grand Maroon.
What "package"?
Now why don't you just lay it all out for us? Just what is the complete
configuration, hardware and software, for the machines that had this
problem?
It might also be interesting to hear about your "workaround", though of
course you run the risk of exposing yourself as an even More Grand
Maroon than you already have shown us.
Here's my guess as to what you might have experienced:
You had somebody telnet in and dial out. While in the midst of the dial
out session, something happened so that the telnet session was
disconnected, but was left as a stale utmp entry. While I *have* seen
that now and then, I can't actually duplicate that on this 5.0.4
machine, so I'm guessing at the rest..so there you are with a stale
entry. Big deal. That's not going to stop you from dialing out again;
the LCK file might be there, but the PID wouldn't be, so cu would
override it. BTW, did you ever run cu -x9 to see WHY you couldn't dial
out? I doubt it.
So the only thing that's going to stop you is a real PID. But you say
the process was terminated (though you refuse to tell us how, which
causes me to agree with John's assesment: SCO techs couldn't help you
because you are too much of a maroon to give them the information they
need!). So was it maybe a zombie? OK, if so, cu would think the PID
was real. However, all you'd have to do is remove the LCK file and cu
would happily proceed. In fact, if you want a demonstration of that,
start up a cu, leave it running, and then remove the lock file and dial
out from elsewhere. The second dialout will cause the modem to hang up
(assuming you have things at least half-assed configured) and will knock
the first process out. If you are stubborn about it, you can arrange
things so that the first process remains connected to the port, and that
will cause read() difficulties, but that's all, and a zombie would NOT
be reading anything, so that wouldn't be a problem.
So, Grand Maroon, if you want to regain ANY credibility with this group,
it's time to stop being a jerk and tell us exactly what you saw, what
you did, and why you thought it had anything to do with utmp.
Personally, I think John D. is right: you're (and that's the proper
contraction for "you are", BTW, not "your"!) so convinced that you are
right you don't listen to people who could help you.
But, given that we're dealing with a Grand Maroon, here's your chance:
lay it out for us. Show us what morons we are, and how fiendishly
clever you are. Show us how your amazing skills cut to the heart of the
problem and showed you that stale utmp entries were the cause. We
inexperienced dullards can perhaps learn something, and won't it be
grand to see us abjectly apologising to you? Wouldn't you love to see
us with our tails between our legs, whimpering, begging for
forgiveness? Come on, Charles, whip us with your brilliance. We're
begging for it, we deserve it, and only a Grand Maroon such as you can
deliver it.
--
Tony Lawrence (to...@aplawrence.com)
Charles Regalia
>
> Charles Regalia wrote:
>
> > I believe that if you don't install or use the software that causes the
> > problem, then you won't observe the problem. If you do install the package
> > that has the bug, SCO will not help you to find the cause.
>
> Package? This is the first time you've mentioned that, Grand Maroon.
> What "package"?
>
> Now why don't you just lay it all out for us? Just what is the complete
> configuration, hardware and software, for the machines that had this
> problem?
SCO OSE 5.0.[2-4]
> It might also be interesting to hear about your "workaround", though of
> course you run the risk of exposing yourself as an even More Grand
> Maroon than you already have shown us.
I don't use dial out on the SCO systems that have this problem. I dial the
SCO machine and send data to them. If you know of a real fix, pass it on.
> Here's my guess as to what you might have experienced:
>
> You had somebody telnet in and dial out. While in the midst of the dial
> out session, something happened so that the telnet session was
> disconnected, but was left as a stale utmp entry. While I *have* seen
> that now and then, I can't actually duplicate that on this 5.0.4
> machine, so I'm guessing at the rest..so there you are with a stale
> entry. Big deal. That's not going to stop you from dialing out again;
> the LCK file might be there, but the PID wouldn't be, so cu would
> override it. BTW, did you ever run cu -x9 to see WHY you couldn't dial
> out? I doubt it.
If you search through the deja news groups, you can find where another user
than my self had the problem.
You have less than two time slices to clear the LCK file and issue the cu. I
don't know how to accomplish that. A consequence of the bug is that SCO
continually re creates the LCK file. That IS why cu doesn't work and in fact
the -x9 will show you that.
> So the only thing that's going to stop you is a real PID. But you say
> the process was terminated (though you refuse to tell us how, which
> causes me to agree with John's assesment: SCO techs couldn't help you
> because you are too much of a maroon to give them the information they
> need!). So was it maybe a zombie? OK, if so, cu would think the PID
> was real. However, all you'd have to do is remove the LCK file and cu
> would happily proceed.
> In fact, if you want a demonstration of that,
> start up a cu, leave it running, and then remove the lock file and dial
> out from elsewhere. The second dialout will cause the modem to hang up
> (assuming you have things at least half-assed configured) and will knock
> the first process out. If you are stubborn about it, you can arrange
> things so that the first process remains connected to the port, and that
> will cause read() difficulties, but that's all, and a zombie would NOT
> be reading anything, so that wouldn't be a problem.
You are describing how it should work. The failures are caused by a bug.
1) SCO does not support their software. They do sell a service they call
support but they do not provide problem determination and resolution so
it is not support. SCO techs will proceed if you tell them where the
bug
is.
2) They only way to clear the problem is to go through the utmp/wtmp
ritual.
Once the bug has done it's damage no more dial outs until you go
through
that ritual. The re-boot has nothing to do with fixing the problem and
your
wags on 'zombies', 'cu', 'real PID' and 'configuration' are nor
relevant.
The phantom pid causes SCO to keep the port left in use. Simple.
> So, Grand Maroon, if you want to regain ANY credibility with this group,
> it's time to stop being a jerk and tell us exactly what you saw, what
> you did, and why you thought it had anything to do with utmp.
> Personally, I think John D. is right: you're (and that's the proper
> contraction for "you are", BTW, not "your"!) so convinced that you are
> right you don't listen to people who could help you.
People who have the capability to help do. Others rant.
> But, given that we're dealing with a Grand Maroon, here's your chance:
> lay it out for us. Show us what morons we are, and how fiendishly
> clever you are. Show us how your amazing skills cut to the heart of the
> problem and showed you that stale utmp entries were the cause. We
> inexperienced dullards can perhaps learn something, and won't it be
> grand to see us abjectly apologising to you? Wouldn't you love to see
> us with our tails between our legs, whimpering, begging for
> forgiveness? Come on, Charles, whip us with your brilliance. We're
> begging for it, we deserve it, and only a Grand Maroon such as you can
> deliver it.
Don't be so hard on yourself, you are just inexperienced.
Tony Lawrence
>
> Tony Lawrence wrote:
> > Package? This is the first time you've mentioned that, Grand Maroon.
> > What "package"?
> >
> > Now why don't you just lay it all out for us? Just what is the complete
> > configuration, hardware and software, for the machines that had this
> > problem?
>
> SCO OSE 5.0.[2-4]
Again,: what bleeping package???
You do this crap continually: you throw out garbage, and then you ignore
questions relating to the crap you spew. Like your "terminate" crap,
where both I and JP wondered just what in hell you meant, but we never
got a bleeping answer, did we?
>
> > It might also be interesting to hear about your "workaround", though of
> > course you run the risk of exposing yourself as an even More Grand
> > Maroon than you already have shown us.
>
> I don't use dial out on the SCO systems that have this problem. I dial the
> SCO machine and send data to them. If you know of a real fix, pass it on.
As I and others have repeatedly told you, we can't fix something that
isn't broken, and so far you've failed to give us sufficient information
to help you.
If you were a customer of mine, you woukld have received an immediate
refund check, because you are completely hopeless.
> If you search through the deja news groups, you can find where another user
> than my self had the problem.
Jeeeeeeezus!!
Search for what? Search for "I am an idiot and I think SCO sucks?"??
If you have a reference in Dejanews, give enough information that
someone can extract it without spending an afternoon clicking "next".
>
> You have less than two time slices to clear the LCK file and issue the cu. I
> don't know how to accomplish that. A consequence of the bug is that SCO
> continually re creates the LCK file. That IS why cu doesn't work and in fact
> the -x9 will show you that.
What in the world are you blabbering about? "Sco" doesn't continually
recreate lock files. A getty on the port that dies and restarts would
do that; cu creates lock files.. is THAT your problem? You have a
miswired or misconfigured modem and getty keeps locking it?? Sheesh.
>
> You are describing how it should work. The failures are caused by a bug.
Maybe, but you have not yet demonstrated how to cause that "bug".
>
> 1) SCO does not support their software. They do sell a service they call
> support but they do not provide problem determination and resolution so
> it is not support. SCO techs will proceed if you tell them where the
> bug
> is.
SCO has good techs and bad techs. But when they have to work this hard
to get basic information, it's no wonder they can't help you:
Charles: This is broken.
Tech: Would you describe the circumstances where it breaks?
Charles: It's broken.
Tech: Can you give me more information?
Charles: It's broken.
No wonder they tossed you away!
>
> 2) They only way to clear the problem is to go through the utmp/wtmp
> ritual.
> Once the bug has done it's damage no more dial outs until you go
> through
> that ritual. The re-boot has nothing to do with fixing the problem and
> your
> wags on 'zombies', 'cu', 'real PID' and 'configuration' are nor
> relevant.
So you say, but in fact they are.
>
> The phantom pid causes SCO to keep the port left in use. Simple.
Prove it. Nobody here believes that for a minute. How can a phantom
pid cause a lock file to be recreated, boopy? If it's a phantom, then
there's no process, is there? Did you ever look in the LCK file to see
what the PID was? What was it, Charles? It sure couldn't have been the
phantom, could it? So what was it?
> Don't be so hard on yourself, you are just inexperienced.
Yeah, right.
jrich...@my-dejanews.com
Don't be so hard on poor Charles. I have found a bug in UW7 and it's been
there since the AT&T 6300. Do you think any one's fixed it yet? Well? Well?
What do you say about that?
Now I've never had problems like this with cu on my dos systems. And I can't
tell you when I last saw a corrupted utmp/wtmp problem on DOS. That just
doesn't happen with some os's. You, John, JPR and the others are just not
willing to admit that Charles is right.
He found a problem.
It's in every version of SCO since Xenix except 5.05 and it's really a secret
undocumented enhancement.
Not everyone is allowed to use that secret enhancement and if not allowed,
ofcourse they won't see the effect.
SCO knows about the problem since they fixed it in 5.05 (and could have fixed
it earlier but they wanted to piss off Charles).
You just aren't important or experienced enough to have received the
enhancement (you probably don't even listen to BBC1).
It's easy to test to see if you have the required enhancement.
1) corrupt your utmp/wtmp files.
2) telnet in.
3) cu out.
4) terminate (perhaps with prejudice).
5) try to call out again.
If that succeeeds, you didn't get the secret enhancement so nah, nah nah :)
In article <F8Mto...@world.std.com>,
a...@world.std.com (Tony Lawrence) wrote:
> Charles Regalia (us02...@mindspring.com) wrote:
> : Tony Lawrence wrote:
>
> : > We followed your instructions; our systems don't fail. What does that
> : > tell you?
> : > Oh, of course: that WE are idiots.
>
> : Don't be so hard on yourself. Your just inexperienced.
>
> Well, at least *that* was a good laugh to start my day with :-)
>
> --
> Tony Lawrence (to...@aplawrence.com)
> SCO Articles, Tips, Book Reviews: http://www.aplawrence.com
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Tony Earnshaw
> Package? This is the first time you've mentioned that, Grand Maroon.
> What "package"?
Whilst I _have_ been sitting here gawping over this thread, that a
mortal dares to enter into conflict with a large number of the immortals
and the way that this is being done, I cannot help thinking: "Perhaps
he'll die in his sleep (heart attack?) and not come back again".
Therefore:
Give the devil his due, he did mention that he'd (mainly, only?) seen
the problem occur on machines that had AFPS installed.
It doesn't happen (never has) on our main file and print server running
5.0.0, though. In spite of the call-in/call-out facility, used by up to
10 modem lines at a time.
Just thought I'd mention it, in case he does die in his sleep.
Tony
--
************* THE NEW DIMENSION IN DISTRIBUTION ***********
ilion Faculty B.V.
Tony Earnshaw email: to...@ilion.nl
Randstad 21-57
1314 BH Almere-Stad tel: +31 (0) 36 548 50 10
The Netherlands fax: +31 (0) 36 534 05 34
***************** http://www.ilion.nl *********************
Tony Earnshaw
Charles Regalia
> Again,: what bleeping package???
Again, SCO OSE 5.0.[2-4]. Somewhere in there and I'm not wasting any time
tracking
it down for SCO.
> You do this crap continually: you throw out garbage, and then you ignore
> questions relating to the crap you spew. Like your "terminate" crap,
> where both I and JP wondered just what in hell you meant, but we never
> got a bleeping answer, did we?
Do you really not know what terminate means ? Okay, change it to something
like
hang up, or disconnect, or log off, or log out, or end the dial out session,
or stop
the connection to the remote computer, etc.
> As I and others have repeatedly told you, we can't fix something that
> isn't broken, and so far you've failed to give us sufficient information
> to help you.
True statement but not relevant here.
> If you were a customer of mine, you woukld have received an immediate
> refund check, because you are completely hopeless.
I would not have signed up.
> Search for what? Search for "I am an idiot and I think SCO sucks?"??
>
> If you have a reference in Dejanews, give enough information that
> someone can extract it without spending an afternoon clicking "next".
Had you been foolish enough to accept my challenge, I would have done it for
you.
> What in the world are you blabbering about? "Sco" doesn't continually
> recreate lock files. A getty on the port that dies and restarts would
> do that; cu creates lock files.. is THAT your problem? You have a
> miswired or misconfigured modem and getty keeps locking it?? Sheesh.
Nope, wrong wag. The problem gets cleared when you go through the utmp/wtmp
ritual.
> SCO has good techs and bad techs. But when they have to work this hard
> to get basic information, it's no wonder they can't help you:
>
> Charles: This is broken.
> Tech: Would you describe the circumstances where it breaks?
> Charles: It's broken.
> Tech: Can you give me more information?
> Charles: It's broken.
>
> No wonder they tossed you away!
If SCO wants me to find their bugs, they need to ask for a quote.
> Prove it. Nobody here believes that for a minute. How can a phantom
> pid cause a lock file to be recreated, boopy? If it's a phantom, then
> there's no process, is there? Did you ever look in the LCK file to see
> what the PID was? What was it, Charles? It sure couldn't have been the
> phantom, could it? So what was it?
Its a bug, that how.
Charles Regalia
> It doesn't happen (never has) on our main file and print server running
> 5.0.0, though. In spite of the call-in/call-out facility, used by up to
> 10 modem lines at a time.
I too have only seen it on 5.0.[2-4] with AFPS.
Joe Scholz
Charles Regalia wrote in message <36EC7AF2...@mindspring.com>...
A lot of meaningless dribble, except for:
>Sorry I misled you but the problem is resolved. We work around it
Looks like changing your modem settings worked, eh Charles.
I know, I know, you don't want to admit it, and you want to respond with
this "bug" thing again.
Please don't.
I understand.
Joe Scholz
Tony Lawrence
>
> Charles Regalia wrote in message <36EC7AF2...@mindspring.com>...
>
> A lot of meaningless dribble, except for:
>
> >Sorry I misled you but the problem is resolved. We work around it
>
> Looks like changing your modem settings worked, eh Charles.
Actually, last night I remembered that I *have* seen something similar
to what Charles has been ranting about. This was on an unpatched 5.0.4
system (no RS504c had been applied), but it was a dial-in session, not
out, and it was also a badly configured modem and to top it off, the
cable was screwy too! I'm not having a lot of luck remembering the
details, because there was so much wrong there: no rs504c, it was a smp
system without the smp patches, it had cron jobs that rebooted the
system nightly while other cron jobs that were updating databases, it
also had a cron jon that was stomping on utmpx and wtmpx regularly, the
modems were all set up wrong, conflicting entries in Devices and so on,
lots of screwed up stuff courtesy of some idiots who sell a lot of Unix
systems and ought to be publically horsewhipped - so I really didn't
care much about this hung modem- and of course after the rest of the
mess was dealt with, the modem problem didn't come up again.
So, as I've said right along, Charles undoubtedly has had this problem -
but it's NOT the wide spread problem he thinks it is, and it could even
be just bad configuration or whatever on the part of you know who. And
that's what I object to: not the assertion that there was/is a bug,
because there certainly could be. It was the stupid bleating that
EVERYBODY running SCO has this insurmountable problem that annoyed me.
--
Tony Lawrence (to...@aplawrence.com)
Charles Regalia
> Looks like changing your modem settings worked, eh Charles.
>
> this "bug" thing again.
>
> Please don't.
>
> I understand.
Apparently not. The work around is to not use SCO to dial out from the
systems with the bug.
Charles Regalia
> Actually, last night I remembered that I *have* seen something similar
> to what Charles has been ranting about. This was on an unpatched 5.0.4
> system (no RS504c had been applied), but it was a dial-in session, not
> out, and it was also a badly configured modem and to top it off, the
> cable was screwy too! I'm not having a lot of luck remembering the
> details, because there was so much wrong there: no rs504c, it was a smp
> system without the smp patches, it had cron jobs that rebooted the
> system nightly while other cron jobs that were updating databases, it
> also had a cron jon that was stomping on utmpx and wtmpx regularly, the
> modems were all set up wrong, conflicting entries in Devices and so on,
> lots of screwed up stuff courtesy of some idiots who sell a lot of Unix
> systems and ought to be publically horsewhipped - so I really didn't
> care much about this hung modem- and of course after the rest of the
> mess was dealt with, the modem problem didn't come up again.
Not even related. The bug is caused by that utmp/wtmp thing.
> So, as I've said right along, Charles undoubtedly has had this problem -
> but it's NOT the wide spread problem he thinks it is, and it could even
> be just bad configuration or whatever on the part of you know who. And
> that's what I object to: not the assertion that there was/is a bug,
> because there certainly could be. It was the stupid bleating that
> EVERYBODY running SCO has this insurmountable problem that annoyed me.
No problem is insurmountable. But, before you go. Do you know if the
keyboard
focus bug they brought into OSE 5.0.5, (that attempt to fix the keyboard
focus
bug they brought into 5.0.4) is being worked on ?
Charles Regalia
> You may have slipped up here and actually supplied some
> useful information...
>
> Peering into my crystal ball I sense that he is using a modem
> with echo enabled on a non-modem controlled port or with CD
> wired up (or configured up in the modem) and login is engaged
> in a shouting match with the modem. Also if the modem is not
> "quiet" (Q1) result codes can set off a getty war. If you
> can't use the proper modem control setup, you should setup the
> modem as ATE0Q1 so that it will neither echo output from login
> nor output control messages when the line is ringing or when
> you connect or hangup. This really is an inferior setup but it
> can be made to work. A second problem here is that if you hang
> up the line, the user stays logged in. This has it's own set
> of problems, the least of which is whoever connects next
> inherits the same login session from the previous caller.
Wrong wag. Only the utmp/wtmp ritual fixes the problem.
Logan McLeod
their SCO systems....
<shudder>
JP, Tony, and the others are all trusted, experienced, and helpful folks who
are just trying to lend a hand.
All you can do "Charles" is be a condacending, arrogant, pain in the neck
with no appreciation for the help being offered. I imagine the only reason
you posted your initial response to Alan's problem was to start a spitting
match...
Reading this entire thread, I agree with Tony, you're an idiot on the
grandest scale seen here in quite some time. Congratulations...
Logan
Kevin Smith, ShadeTree Software, Inc.
>Alan Maul wrote:
>>
>> We are using ProcommPlus 32 to Telnet into SCO Unix v5.0.4. When we
>> logout and disconnect, "who" still show that pseudo device as logged
>> in. The symptom gets better if we disconnect and then reconnect and
>> have the login displayed when we shut Procomm down, but about 10 percent
>> of the time we still have the problem.
>>
>> Are there any suggestions as to what I might do to fix the who problem?
>> or what a better procedure to follow would be to clear the speudo
>> devices?
>
>It's that utmp/wtmp/utmpx/wtmpx horror that SCO introduced a few years ago.
>Did you notice that if you dial out from your SCO host that you will lose
>the ability to dial out again until you go through their fix ritual which
>includes a reboot. That's right, one call out allowed per boot because of
>the login log corruption.
>
>The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
>and MSDOS 3.0 or higher.
For those of you who've been following this thread, a quick search of
deja-news showes an eerily parallel thread
ose5.0.2 problems - Charles V. Regalia 1997/08/11
In that thread, he's dealing with a different set of issues but his
presentation and the resulting discussion is an absolutly remarkable
likeness to the current one. In that case, he was arguing with Bela
(nice to see your recent post!) and Jim Sullivan (Hi again).
Here's part of another exchange
Re: what happened to open(S) mode argument
Author: Bela Lubkin <be...@sco.COM>
Date: 1996/11/21
Forum: comp.unix.sco.programmer
Charles V. Regalia wrote:
> Bela Lubkin wrote:
>
> > Surely we can think of better things to spend our time on than issuing
> > supplements to fix documentation bugs that you already fully understand
> > and do not actually need to have fixed.
>
> Thus, you concur that SCO has always demonstrated a low regard for
> accuracy in documentaion. It is interesting that you expect the end
> user to be a 'mind reader' when it comes to interpreting errors and
> omissions in SCO documentation, but, whenever you don't know the answer
> to well researched questions that are posted here, your answer is always
> ...
Like any software company, SCO must balance the desire to produce a
perfect product against the desire to actually *ship* a product.
Serious bugs in shipping product are fixed as quickly as possible and
those fixes made available in various forms. Less significant problems
are fixed in future development code and the fixes become available as
new releases are shipped. If SCO shipped a "fix" (SLS or whatever) for
every tiny documentation bug, you would be installing hundreds of
insignificant patches every month. It would drive you crazy.
Now, regarding your "well researched questions"... You post one of
these every once in a while, then present a complete stonewall when I
ask for any additional information. I don't care how complete *you*
think your research is. If I need additional information to understand
the problem, I ask for it. If you refuse to give it, the problem is
most assuredly not at my end.
Furthermore, you appear to misunderstand my presence here. I am not an
official support service. I post for my own enjoyment and to help those
people whom I can help. If a problem comes up that I can't solve, well,
I can't solve it -- that's all. Nobody ever promised you that you would
get answers over USENET. If you need some sort of guaranteed support,
you will have to pay for it, sign contracts that detail exactly what
sort of support is actually guaranteed, etc. I *certainly* have no
obligation to get answers for people who verbally abuse me.
>Bela<
To be fair, his problems are real, it's just his complete inability
to communicate and cooperate that gets in the way.
--
Do two rights make | Kevin Smith, ShadeTree Software, Philadelpha, PA, USA
a libertarian | 001-215-487-3811 shady.com,kevin bbs.cpcn.com,sysop
Stephen Davies
I have used AFPS on 5.0.0, 5.0.2, 5.0.4 without a problem EVER. I have used
it with and without the patches, I have tried to emulate your problem with
5.0.0 with NO patches, 5.0.4 with NO patches, 5.0.0 with the net100 and
various other patches, and 5.0.4 with rs504c. STILL NO PROBLEM
Charles, get a life - give this group some evidence of what you are bleating
about or p.....s off. OK. We are all getting a little sick of your mindless
drible.
Stephen Davies
Charles Regalia wrote in message <36EDEC4D...@mindspring.com>...
>Tony Earnshaw wrote:
>
>> It doesn't happen (never has) on our main file and print server running
>> 5.0.0, though. In spite of the call-in/call-out facility, used by up to
>> 10 modem lines at a time.
>
>I too have only seen it on 5.0.[2-4] with AFPS.
>
>
Stephen Davies
I hear? Failed to produce the evidence again?
Jeff Holloway
> In article <36E7523D...@mindspring.com> Charles Regalia <us02...@mindspring.com> writes:
>>Alan Maul wrote:
>>>
>>> We are using ProcommPlus 32 to Telnet into SCO Unix v5.0.4. When we
>>> logout and disconnect, "who" still show that pseudo device as logged
>>> in. The symptom gets better if we disconnect and then reconnect and
>>> have the login displayed when we shut Procomm down, but about 10 percent
>>> of the time we still have the problem.
>>>
>>> Are there any suggestions as to what I might do to fix the who problem?
>>> or what a better procedure to follow would be to clear the speudo
>>> devices?
>>
>>It's that utmp/wtmp/utmpx/wtmpx horror that SCO introduced a few years ago.
>>Did you notice that if you dial out from your SCO host that you will lose
>>the ability to dial out again until you go through their fix ritual which
>>includes a reboot. That's right, one call out allowed per boot because of
>>the login log corruption.
>>
>>The fix is simple. Choose one of Linux, HP-UX, Solaris, AIX, IRIX, TOPIX,
>>and MSDOS 3.0 or higher.
Sorry for the snip, Kevin.
Our company does a LOT of remote work on our clients' sites, using 5.0.4 and
cu. At no time have we experienced the 'bug' related by Chucky above. I must
have gotten the 'patched' version of 5.0.4....:)
Jeff
--
Jeff Holloway | He had that rare weird electricity about him --
System Administrator | that extremely wild and heavy presence that you
Tech 7 Systems, Inc. | only see in a person who has abandoned all hope
je...@tech7.com | of ever behaving "normally" - Hunter S. Thompson,
| "Fear and Loathing '72"
Not a member of the Lumber Cartel (tinlc) and not Unit #1572
Charles Regalia
>
> WRONG AGAIN.
>
> I have used AFPS on 5.0.0, 5.0.2, 5.0.4 without a problem EVER. I have used
> it with and without the patches, I have tried to emulate your problem with
> 5.0.0 with NO patches, 5.0.4 with NO patches, 5.0.0 with the net100 and
> various other patches, and 5.0.4 with rs504c. STILL NO PROBLEM
>
> Charles, get a life - give this group some evidence of what you are bleating
> about or p.....s off. OK. We are all getting a little sick of your mindless
> drible.
>
Charles Regalia
>
> What scares me... Is that somebody, somewhere, is paying this guy to work on
> their SCO systems....
>
> <shudder>
>
> JP, Tony, and the others are all trusted, experienced, and helpful folks who
> are just trying to lend a hand.
>
> All you can do "Charles" is be a condacending, arrogant, pain in the neck
> with no appreciation for the help being offered. I imagine the only reason
> you posted your initial response to Alan's problem was to start a spitting
> match...
Actually, even though it is quite entertaining to see the rantings from all
those dweebs, the posting indicated that when the problem occurs in your
system, SCO will not help you with it.
> Reading this entire thread, I agree with Tony, you're an idiot on the
> grandest scale seen here in quite some time. Congratulations...
Tony simply quoted the children's cartoons he watches.
Charles Regalia
>
> Oh Charles I notice you have not bothered to reply to my post. No comment do
> I hear? Failed to produce the evidence again?
I'm baffled by this one. Let me try this:
"no"
Charles Regalia
> To be fair, his problems are real, it's just his complete inability
> to communicate and cooperate that gets in the way.
To be fair, post my response to Bela.
Kevin Smith
>"Kevin Smith, ShadeTree Software, Inc." wrote
>
>> To be fair, his problems are real, it's just his complete inability
>> to communicate and cooperate that gets in the way.
>
>To be fair, post my response to Bela.
To be fair, you post it. I'm not going to jump through any hoops
for you.
Tony Lawrence
> Actually, even though it is quite entertaining to see the rantings from all
> those dweebs, the posting indicated that when the problem occurs in your
> system, SCO will not help you with it.
I don't think anyone can help poor Charles.
Bela couldn't, JPR can't, John Dubois can't, I certainly can't- nobody
can help poor Charles.
The combined experience and knowledge of the people who have tried to
help you is beyond your ability to comprehend. Your truly clueless
responses to attempts to elicit information that might get to the bottom
of your problem indicate to me that you don't WANT a solution; you just
want to bitch and moan about not being helped. That's a pretty sick
person: maybe you should think about just why you do this.
In the meantime, I just want to point out again that whatever problem
you may or may not have had, it is NOT the widespread problem that your
original posts indicated, that if you were not such an arrogant twit it
is very likely that people here could help you solve it, and that your
remarks about the only solution being to switch to some other OS were
ignorant and quite ridiculous.
Other than that, have a nice day.
Charles Regalia
> The combined experience and knowledge of the people who have tried to
> help you is beyond your ability to comprehend. Your truly clueless
> responses to attempts to elicit information that might get to the bottom
> of your problem indicate to me that you don't WANT a solution; you just
> want to bitch and moan about not being helped. That's a pretty sick
> person: maybe you should think about just why you do this.
Where was my request for help? There wasn't one.
> In the meantime, I just want to point out again that whatever problem
> you may or may not have had, it is NOT the widespread problem that your
> original posts indicated, that if you were not such an arrogant twit it
> is very likely that people here could help you solve it, and that your
> remarks about the only solution being to switch to some other OS were
> ignorant and quite ridiculous.
Again, the solution is known. SCO won't fix it so don't use it.