[ubuntu-us-ut] Grievances: Upstart, Launchpad, and Misuse of anacron

Aaron Toponce aaron.toponce at gmail.com
Mon Sep 13 22:39:01 BST 2010


On Mon, Sep 13, 2010 at 03:06:36PM -0600, Charles Curley wrote:
> Perhaps a re-write of cron is in order. But I still don't see the need
> to mush the clear dividing line between cron and anacron.

I understand the UNIX philosophy, but it doesn't make sense to have 3
separate daemons that are so closely related, to be fractured. Bringing
cron and anacron into the init pid just makes sense. Especially when
init is now going the way of event driven start/stop.

> See /etc/crontab, for the kludge used to run
> cron.[daily|weekly|monthly].

Right. This is what I mentioned previously. Cron is telling anacron to
update the timestamps on the system, so if a system goes down during the
time that a cron job should have been run, anacron knews when it was
last executed, and whether or not it should execute the job on boot.
This is standard anacron implementation and behavior. I don't see what
Debian/Ubuntu is doing differently here.

> Maybe I'm dense here. SysV already handles service dependencies.

Well, kind of. It's quite fragile at the momont. Just walk through any
/etc/init.d/ script, and check out the insane shell logic that exists
for many of them. Then there's naming the scripts appropriately, to make
sure they launch in the right order, which could break the dependency
the script author intended. Then you have the /etc/init.d/functions
script that is sourced in some, not in others. On and on. SysV is
turning into a package maintainers nightmare.

Also, Upstart does more than manage dependecies. As mentioned, it's
event driven, not daemon driven. It's a radically different paradigm
shift for init. When an event is triggered on the system, you cant start
or stop a service based on that event (like plugging in a USB drive).

What I was explaining was that Upstart doesn't start dependencies a
service requires to run (it handles that too), but it starts other
services that require the service you're starting to run.

For example: consider an event that starts networking. Any service that
depends on networking (NFS, Apache, DNS, DHCP, etc) would also be
started. (Bad example, but illustrates the point.) Systemd is different
in this respect, but replacing SysV is the goal of most .*n.x operating
systems. Apple has done it, Solaris has done it, BSD thought of
something beterr (as usual), Ubuntu and Fedora have done it. I think
openSUSE is implementing Upstart. In other words, SysV has shown its
age. It's served us well, but it's time to improve the init daemon, not
hinder it.

> I'm not sure what events you are referring to. Starting and stopping
> services because hardware is plugged in doesn't strike me as something
> the startup code should do. We already have code that detects new
> hardware and handles it, e.g. udev. If a device needs a service, let
> udev launch it. E.g.: gpsd. If a service becomes unnecessary when a
> device is removed, then let udev shut it down.
>
> It it too late to have plea for simplicity in Unix design? What ever
> happened to the Unix idea of having each program do one thing, only
> one thing, and do it very, very well?

Exactly why udev shouldn't be handling services. Udev should only be
handling devices creation/removal. Of course, you can extend udev with
all sorts of rules, scripts, etc. to do whatever you want, but that
doesn't mean you should. Starting services based on an event should be
handled by the init system, not udev. Udev just catches the event, and
tells init to do something about it.

> Windows and most office suites try to be all things to all men. As
> a result, they are bloated, buggy, and often insecure precisely because
> they violate this precept. I don't want it invading Unix.

Upstart/Systemd isn't trying to be the do-all/catch-all for everything
under the UNIX-subsystem. Cron/anacron/at/init all have very similar
like functionality, even to the possibility of duplicating a great deal
of effort. It would still be simple in design (the execution of daemons
at specific times based on logic/events/etc.), and it would execute very
well.

> Not necessarily. When the issue tracking software is so lame
> that it discourages people from filing legitimate issues, you have lost
> good information.

I will agree that you will lose some signal, especially if the bug
tracking system is too difficult to file bugs. Definitely a give/take
relationship. Debian has decided on some sort of middle ground. If you
want to submit a bug, go to http://www.debian.org/Bugs/Reporting on some
rough guidelines on how to submit or comment.

Personally, I can't wade through the bugs on Launchpad. They're far too
overwhelming, and you spend more time getting through the "this doesn't
work for me either" crap "+1" or " i want this" sort of whining. It's
quite difficult to find fixes or temporary hacks in the comments, and
it's even more difficult to find if a bug you're experiencing exists.



-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-us-ut/attachments/20100913/50efaf62/attachment.pgp 


More information about the ubuntu-us-ut mailing list