oss642a

[Jean-Pierre Radley]

OSS642a has appeared. It's got the new cron, and is pretty much required
for OSR 5.0.6, but can be installed on 5.0.4 and 5.0.5 as well.

It fixes the problem of cron launching a job twice, and affords some new
functionality governed by /etc/default/cron.

--
JP

[Pat Welch]

Where, JP?

Caldera has 'disappeared' www.sco.com/ta again. You're redirected to
stage.caldera.com/ta, and there's no hit on OSS642A.

--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
Caldera Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Fax: (413) 714-2833
Nationwide pager: (800) 608-7122
E-mail: pat...@inreach.com
Hunt down and KILL anyone involved in the NY attack!
----------------------------------------------------

[Jean-Pierre Radley]

Pat Welch propounded (on Tue, Sep 18, 2001 at 06:28:52AM +0000):

| Jean-Pierre Radley wrote:
| >
| > OSS642a has appeared. It's got the new cron, and is pretty much required
| > for OSR 5.0.6, but can be installed on 5.0.4 and 5.0.5 as well.
| >
| > It fixes the problem of cron launching a job twice, and affords some new
| > functionality governed by /etc/default/cron.
| >
|

| Where, JP?
|
| Caldera has 'disappeared' www.sco.com/ta again. You're redirected to
| stage.caldera.com/ta, and there's no hit on OSS642A.

ftp.caldera.com, in /pub/openserver5.

--
JP

[Bob Bailin]

"Pat Welch" <pat...@inreach.com> wrote in message
news:3BA6E986...@inreach.com...

> Jean-Pierre Radley wrote:
> >
> > OSS642a has appeared. It's got the new cron, and is pretty much
required
> > for OSR 5.0.6, but can be installed on 5.0.4 and 5.0.5 as well.
> >
> > It fixes the problem of cron launching a job twice, and affords some new
> > functionality governed by /etc/default/cron.
> >
> > --
> > JP
>
> Where, JP?
>
> Caldera has 'disappeared' www.sco.com/ta again. You're redirected to
> stage.caldera.com/ta, and there's no hit on OSS642A.
>

It's there today as TA #115162, "What is SLS OSS642A, the Cron supplement?".

[Bob Bailin]

"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2001091800...@jpradley.jpr.com...

I'd just like to report that after installing OSS642a on 5.0.5 (all
patches), I was told that Monday's nightly backup didn't run (tape wasn't
automatically ejected). Upon checking root's mail, I noticed 172 msgs (so
far) from cron with:

cron: can't set login UID.

It seems that though the custom install script went to the trouble of
killing cron and restarting it, it neglected to restart it using the sd
command (see TA #106462 which seems to apply to OSR5, even though it's not
stated).

[Jean-Pierre Radley]

Bob Bailin propounded (on Wed, Sep 19, 2001 at 11:22:22AM -0400):

|
| I'd just like to report that after installing OSS642a on 5.0.5 (all
| patches), I was told that Monday's nightly backup didn't run (tape wasn't
| automatically ejected). Upon checking root's mail, I noticed 172 msgs (so
| far) from cron with:
|
| cron: can't set login UID.
|
| It seems that though the custom install script went to the trouble of
| killing cron and restarting it, it neglected to restart it using the sd
| command (see TA #106462 which seems to apply to OSR5, even though it's not
| stated).

Hmm. I didn't see any such thing when I installed it, but I've forwarded
your observations to the responsible parties at Caldera.

--
JP

[Bela Lubkin]

Bob Bailin wrote:

> I'd just like to report that after installing OSS642a on 5.0.5 (all
> patches), I was told that Monday's nightly backup didn't run (tape wasn't
> automatically ejected). Upon checking root's mail, I noticed 172 msgs (so
> far) from cron with:
>
> cron: can't set login UID.
>
> It seems that though the custom install script went to the trouble of
> killing cron and restarting it, it neglected to restart it using the sd
> command (see TA #106462 which seems to apply to OSR5, even though it's not
> stated).

Thanks for the report, Bob.

You are correct, the ccs script should use `sd cron` to restart cron.
This only makes a difference on systems where the kernel parameter
SECLUID is set to 1. Apparently the people who wrote and tested oss642a
didn't try it on such a system. Yours may be that way because you chose
the "high" set of security defaults; most people choose "traditional",
which sets SECLUID=0.

Although there's a simple workaround (stop and properly restart cron;
or, crudely, reboot after installing oss642a), I think we should fix
this. I will recommend internally that we issue an oss642b.

(I might argue that the bug is in /etc/rc2.d/P75cron aka
/etc/init.d/cron: _it_ should use `sd cron` so that admins who manually
run rc scripts don't have to think about this madness.)

>Bela<

[Bob Bailin]

"Bela Lubkin" <be...@caldera.com> wrote in message
news:2001092001...@mammoth.ca.caldera.com...

One more cron related problem:

I originally fixed this problem by dialing in to our system on a modem on
/dev/tty1B16, logging as root, killing cron and issuing: sd cron .

Today I received many complaints that no one could dial in on this modem
last night (connect, no login prompt). A ps -ef | grep 1B16 showed that this
port was hung up on the modem init stage of getty. I disabled the port,
enabled it, but still had the same problem of getty hanging on the modem
init script.

I disabled the port again, did an: lsof /dev/tty1B16
and lsof reported that /dev/tty1B16 was still open by cron on file
descriptors 1 and 2. I killed cron and restarted it from tty10, and the
problem corrected itself.

So, my questions are: When you restart cron manually, will cron jobs default
to using the tty you started it from for fd's 0, 1 & 2 if the command line
doesn't otherwise specify an i/o source such as: ... < /dev/null > /dev/null
2>&1 ? Has this always been the behavior of cron, or was it introduced in
the oss642a version? When manually restarting cron from a modem port, should
I use: sd cron < /dev/console > /dev/console 2>&1 ?

[Steve Fabac]

I have observed this problem (cron started/restarted when logged in on
modem port) in all versions of Openserver 5.0.x as well as 3.2v4.2.

In short: Never restart cron from the modem port, unless some one
(Bela?) can provide a work a round.

--

Steve Fabac
S.M. Fabac & Associates
816/765-1670

[Stuart J. Browne]

> > I originally fixed this problem by dialing in to our system on a modem
on
> > /dev/tty1B16, logging as root, killing cron and issuing: sd cron .
>

> In short: Never restart cron from the modem port, unless some one
> (Bela?) can provide a work a round.

Be cheeky and use 'at' to launch it a minute from now after you've dropped
the connection?

[Tony Lawrence]

Steve Fabac wrote:

> I have observed this problem (cron started/restarted when logged in on
> modem port) in all versions of Openserver 5.0.x as well as 3.2v4.2.
>
> In short: Never restart cron from the modem port, unless some one
> (Bela?) can provide a work a round.

Never had this, but wouldn't "nohup" work?

--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com