This is correct - early Linux kernels created threads via clone(),
which look from the outside like multiple processes. It's not ps
that can't tell the difference, since they really are separate
processes, that just happen to share most resources. AFAIK, it was
just a fairly easy but very ugly way of implementing threads
initially. I'm guessing this has been cleaned up in the 2.6 Linux
kernels, but don't know for sure.
On Friday, Feb 27, 2004, at 20:33 Australia/Sydney, Rainer Schöpf wrote:
On Fri, 27 Feb 2004, Thomas Rupp, Vorarlberger Illwerke AG wrote:
I'm running Red Hat Linux Advanced Server release 2.1AS/i686
(Pensacola)
with the TSM 5.2.0.0 client.
When I start dsmcad by simply entering the command I get 5 dsmcad
processes.
root 8431 1 0 09:51 ? 00:00:00 dsmcad
root 8432 8431 0 09:51 ? 00:00:00 dsmcad
root 8433 8432 0 09:51 ? 00:00:00 dsmcad
root 8434 8432 0 09:51 ? 00:00:00 dsmcad
root 8435 8432 0 09:51 ? 00:00:00 dsmcad
I think that these are actually Linux threads, not processes (created
with
the clone system call instead of fork). Unfortunately, all versions
of ps
I have seen up to now cannot show the difference, although the ps man
page
tells you that only -m should show the threads.
I remember having recently seen an announcement on freshmeat.net for a
new
version of ps that _can_ show threads properly.
Scheduled backup runs fine for 2 days and then stops. All dsmcad
processes have
gone.
No messages in DSMERROR.LOG or DSMSCHED.LOG.
Just a wild guess (from personal experience): check with lsof on the
running dsmc processes that the dsmerror.log and dsmsched.log files are
really the ones begin written by the client. Use the SCHEDLOGNAME and
ERRORLOGLOGNAME options in the client config file to specify the full
path.
Rainer Schöpf
ProteoSys AG
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams
|