Cron Starts too many procs

Cron Starts too many procs

Post by paul.d.fink » Sat, 23 Apr 1994 05:16:46

Last week I asked if anyone had any experience with cron being
killed on a machine running UNIX V 3.2.3. The problem was resolved
by rewriting one of the shell scripts run by cron.

New problem: cron runs this same script once every 15 minutes during
the work day. The script was originally found in UNIX world.
It uses the output of "who -u" to kill all processes of users
logged in more than 15 minutes. It works fine. All the correct users
have their processes killed and are forced to login in again.
Problem: there are usually 3 versions of this same script running.
Sometime there are 5. The first of these processes has a parent process
which is cron's process id. Each subsequent running of the process is a
child of the previously invoked running of this program.

If any one has any idea (without looking at the code) as to why this might
happen, I'd appreciate hearing from you by e-mail. I will post replies
that assist in resolving this problem

Do unto others ... then split.
                        -- Mary Anne Stasium --


1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at

2. What's the deal McNeil? Bad interactive behavior in X w/ RH's 2.4.18

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. Per/User Accounting Data on AIX3.2

5. cron.deny and cron.allow files for CRON management

6. Wang Connectivty

7. cron: updatedb; find: /proc/self/fd/4: No such file or directory

8. non-blocking packet pacture (libpcap)

9. Why are there 2 proc when looking at CRON-Jobs?

10. Start a process using only one of several procs

11. How do I start /proc logging?

12. anacron runs daily at 4am (cron is not starting it, WHAT IS?)

13. Sol 2.3 --> cron does not start properly