Bug 15915 - Startupposition (40) too less
Summary: Startupposition (40) too less
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: at
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-10 10:29 UTC by Enrico Scholz
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-06-11 20:12:18 UTC
Embargoed:


Attachments (Terms of Use)

Description Enrico Scholz 2000-08-10 10:29:30 UTC
See #15335 and #13353 for details

Comment 1 Glen Foster 2000-08-13 18:19:38 UTC
Could you please provide information on "at" that is seriously at risk?  I
understand (and agree) that the start-up and shut-down ordering of RH Linux
scripts could be modified... but a complete re-design of these scripts is a
large task that probably won't get fixed right before release; it's something
that should be a "release deliverable feature".

However, if there is some race-condition, or denial-of-service, or data
corruption, or something that can be demonstrated as a real problem, I would
like to see/hear/read more on the issue.

Comment 2 Enrico Scholz 2000-08-14 18:54:58 UTC
Because (ana)cron and at are related programs I will write about both...

When a job will be executed immediately after at/cron/anacron has been started,
the problems occur. Such race-conditions can be triggered e.g.:

- with `at' or similarly `anacron': create a job which has to be executed at
00:10, stop the machine at 00:00 and start it again at 00:20. `at' will execute
pending jobs at startup
- with `cron': create a crontab entry '@reboot  doSomething'


Some critical actions can be:
- DNS related ones: if localhost is the NS-server, bind will be started at pos
55 -- that's after `at' and `cron'.  Example:
| host <host_in_my_domain> || do_bad_things

- Time related ones: ntp starts at pos 55 and can set time to values causing an
unwanted behavior of the scheduling progs

- Mail related ones: `sendmail' starts at pos 80. If a job needs a sendmail
daemon listing on port 25 it will fail. A real world example is `fetchmail'
started by users at '@reboot'-time.

There are some cases left, depending e.g. on xinetd(50), lpd(60) or squid(90),
where similar examples are possible.


I understand that changing startup positions is a critical step shortly before
the release, but I don't see any reason why user-oriented daemons must be
executed before important system services. Additional at and cron are not
working determinedly (sometimes a job will be executed before positions >40,
sometimes not). If the @reboot feature is really needed at this stage, it's
better to write a seperate initscript doing it.

Comment 3 Enrico Scholz 2000-12-27 11:42:52 UTC
Still on florence, beta1

Comment 4 Enrico Scholz 2001-01-26 18:33:40 UTC
Still in beta2

Comment 5 Enrico Scholz 2001-06-11 20:12:14 UTC
still in at-3.1.8-16

Comment 6 Crutcher Dunnavant 2001-06-26 01:37:25 UTC
okay


Note You need to log in before you can comment on or make changes to this bug.