Please,
I think everyone understands the issues in place. There is a firm
statement that dbmail will support everyone's way of doing things.
MTOWTDI is fine.
As much fun as it is to argue, let's move on to other better things
(like making a better dbmail).
Matt
On Wed, 2006-03-08 at 09:58 -0800, Christian G. Warden wrote:
> Two benefits of init.d are that it makes it easier to stop services
Do we often want to stop services?
> makes it easier to define dependencies between services.
init.d has NO support for declaring dependencies, only the ability to
On Wed, 2006-03-08 at 10:28 -0800, Aaron Stone wrote:
> On Wed, 2006-03-08 at 12:38 -0500, Geo Carncross wrote:
>
> > I would like to see a process that can resist kill -9
>
> I once had a process stuck in the D state, waiting on returns from a
> filesystem located on a block device that was dyin
On Wed, 2006-03-08 at 12:38 -0500, Geo Carncross wrote:
> I would like to see a process that can resist kill -9
I once had a process stuck in the D state, waiting on returns from a
filesystem located on a block device that was dying but wasn't quite
dead yet (picture Monty Python's crew carrying
> When a message have more than one target adresses (cc, bcc etc) and one of
> the adresses have full mailbox, all of the others also get the "(User
> unknown)" error.
Sounds similar to:
http://svn.ic-s.nl/websvn/listing.php?repname=DBMail&path=%2Fbranches%
2Fdbmail_1_2_branch%2Fdbmail%2F&rev=13
On Wed, Mar 08, 2006 at 12:38:15PM -0500, Geo Carncross wrote:
> On Wed, 2006-03-08 at 11:47 -0500, Matthew T. O'Connor wrote:
> > Geo Carncross wrote:
> > If init were really such a good answer why haven't all the really smart
> > people put distros together use it for more than a few simple proc
On Wed, 2006-03-08 at 11:47 -0500, Matthew T. O'Connor wrote:
> Geo Carncross wrote:
> > Nonetheless, "hung" processes are another deal: "hung" processes are the
> > result of broken code, or a broken design.
>
> No more so than a program that crashes or a kernel that randomly kills
> off process
Geo Carncross wrote:
Nonetheless, "hung" processes are another deal: "hung" processes are the
result of broken code, or a broken design.
No more so than a program that crashes or a kernel that randomly kills
off processes.
The problem I've been pointing out is that processes can be killed f
On Wed, 2006-03-08 at 09:32 +0100, Thomas Mueller wrote:
> Hi Geo,
>
> > But even working init.d scripts and working daemons can be killed or
> > stopped for lots of reasons, and unless you duplicate the work of init,
> > or manually intervene, they won't start back up.
>
> I read that argument s
Hi Geo,
> But even working init.d scripts and working daemons can be killed or
> stopped for lots of reasons, and unless you duplicate the work of init,
> or manually intervene, they won't start back up.
I read that argument several times now but I still think init doesn't
help here.
I have to m
The following issue has been SUBMITTED.
==
http://www.dbmail.org/mantis/view.php?id=310
==
Reported By:Alligator
Assigned To:
On Wed, 2006-03-08 at 00:23 +, Aaron Stone wrote:
> On Tue, Mar 7, 2006, Geo Carncross <[EMAIL PROTECTED]>
> said:
>
> > I have no idea how to attack this for _all_programs_ i.e. the community
> > at large, when really, the problems that would affect dbmail DON'T
> > affect some other programs
Yes, I can find myself in your proposed sollution.
If I get bit in the butt, I'll be happy to report it here.
Furthermore, Paul and Aaron, many thanks for this great piece of
software! I'm a very happy user!
/Marc
On Wed, Mar 08, 2006 at 12:08:32AM -, Aaron Stone wrote:
> Ohhhk
On Tue, Mar 7, 2006, Geo Carncross <[EMAIL PROTECTED]>
said:
> I have no idea how to attack this for _all_programs_ i.e. the community
> at large, when really, the problems that would affect dbmail DON'T
> affect some other programs.
Write an article for freshmeat.net or one of the Sysadmin or Li
On Tue, Mar 7, 2006, Marc Dirix <[EMAIL PROTECTED]> said:
> And secondly, starting from inittab is IMHO only usefull for daemons
> which tend to get killed or die, and therefor is a quickfix for not propperly
> working daemons.
Nothing's perfect, and there are a plenty more ways to blow up your
Ohhhkkaayy
Geo's approach is really cool. Marc's approach is more typical.
You guys are free to choose either one. I'm sure that Geo thinks that Marc
will get bit in the butt by his choice at some point, and Marc thinks that
Geo is being weird. For sure
On Wed, 2006-03-08 at 00:49 +0100, Marc Dirix wrote:
> Like I said, a daemon should run indepedentally from the shell
> implemantation.
But you haven't said _why_.
> And secondly, starting from inittab is IMHO only usefull for daemons
> which tend to get killed or die, and therefor is a quickfix
On Tue, 2006-03-07 at 21:33 +, Aaron Stone wrote:
> On Tue, Mar 7, 2006, Geo Carncross said:
> > On Tue, 2006-03-07 at 20:11 +0100, Paul J Stevens wrote:
> >> Since we already support 1 and 3, adding 2 would make this picture
> >> complete. We could then also allow selection of the default thro
Like I said, a daemon should run indepedentally from the shell
implemantation.
And secondly, starting from inittab is IMHO only usefull for daemons
which tend to get killed or die, and therefor is a quickfix for not propperly
working daemons.
Furthermore, a standard init only tries X time to res
On Tue, 2006-03-07 at 21:56 +0100, Marc Dirix wrote:
> Using the &> and the sorts is just plain wrong.
Why?
> You want a daemon if it daemonizes itself to daemonize by itself without
> needing any shell implementation.
No I don't.
Daemons get started by the shell anyway. The shell is in a perf
20 matches
Mail list logo
