Like a daemon

[John Kelly]

/*

Traditional daemons listen on a socket and never quit. To cooperate
and not interfere with file system dismounts, they begin work in the
top level / directory. To attain independence and preclude unwanted
interruptions, they detach themselves from any controlling terminal.

Not all daemons listen on sockets.

It's easy to code a script that reads standard input. And it's easy
to substitute a FIFO for standard input. And syslog will also write
selected output to a FIFO. Gluing those pieces together gives you a
real time log processor. It may not look like a traditional daemon,
but you want it to read the FIFO and never quit.

Or suppose you want to start an ordinary job without any controlling
terminal. Or suppose you want to prototype a socket daemon, using a
script language tool for rapid development. In any such case, there
are certain steps required for launching your job with a life of its
own, like a daemon.

Duplicating the same code in one program after another is boring and
messy. I wanted to synthesize the common elements of daemon startup
and distill them into a utility program.

So I developed dh, the daemon helper. Written in the C language, it
starts any program, script, or shell command as a daemon.

Before developing the daemon helper, I found sundry daemon utilities
available for download, but none of them worked the way I wanted one
to work, so off to work I went ...

Its usage is simple: dh [-p lock.pid] daemon args

The "daemon" can be a program or shell command, and the lock.pid, if
unspecified, will default to the base name of the daemon plus a .pid
suffix. The lock.pid name is used to prevent inadvertently starting
multiple instances of the same daemon; specifying different lock.pid
names on successive invocations will circumvent that control.

The lock.pid file also serves as a pid file and initial log file for
the daemon. The pid alone is on the first line, and the second line
contains the process group identifier. The third line begins a list
of environment variables and their values. Then follows a timestamp
and startup message. Standard output and standard error are sent to
the file, until redirected by the daemon to some other destination.

*/


P.S.

Producing a universal tool takes time, trial, and error, and I have
gradually refined dh to meet my needs. It has the potential to become a
standard tool, and I have ideas for further development, outlined in the
PLANNED.options file.

Whether my ideas become plans or not, dh is an open source project with
an Apache license. Small enough for an individual to comprehend, it may
appeal to C programmers having varied experience and interest.

The source code is freely available:

ftp://isp2dial.com/users/jak/src/dh/


To contact me, you can find my real email address in the headers of this
post, and in the file MY.MAILTO where the source code resides.

 

[Seebs]

So I developed dh, the daemon helper. Written in the C language, it
starts any program, script, or shell command as a daemon.

This is not, strictly speaking, written in "C". It is written in C+POSIX.

Before developing the daemon helper, I found sundry daemon utilities
available for download, but none of them worked the way I wanted one
to work, so off to work I went ...

.... and wrote one that does not work the way anyone else wants one to work.

The lock.pid file also serves as a pid file and initial log file for
the daemon. The pid alone is on the first line, and the second line
contains the process group identifier. The third line begins a list
of environment variables and their values. Then follows a timestamp
and startup message. Standard output and standard error are sent to
the file, until redirected by the daemon to some other destination.

This is a fascinating behavior, which is completely incompatible with the
standard idiom:

$ kill -HUP $(cat daemon.pid)

Producing a universal tool takes time, trial, and error, and I have
gradually refined dh to meet my needs.

It's not universal, though -- and as you note, it is refined to meet
*your* needs.

It has the potential to become a standard tool,

No, it doesn't.

The BSD daemon(8) had reasonable potential to become a standard tool.
It was widely available under a BSD license and conformed closely with
the carefully-planned and considered semantics of the daemon(3) call
introduced in BSD 4.4. It carefully focuses on doing one thing, and doing
it well, and does so correctly; it handles the key components of daemonizing,
leaving the non-key components to be adapted to particular needs. (You
can look it up on FreeBSD or BSD/OS. I honestly don't know which had it
first, although the FreeBSD docs say it appeared in FreeBSD 4.7.)

.... Ahh, it was BSD/OS first:

* Copyright (c) 1999 Berkeley Software Design, Inc. All rights reserved.

* From BSDI: daemon.c,v 1.2 1996/08/15 01:11:09 jch Exp

So. Basically, here we are, twelve years after Jeff Honig solved this
problem, and you're offering a worse solution. His is correct, offers
additional flexibility, and has been available freely for over a decade.
It's been used in at least two different operating systems, and is built
around a carefully-designed interface which handles signals correctly and
honors Unix idioms.

Whether my ideas become plans or not, dh is an open source project with
an Apache license. Small enough for an individual to comprehend, it may
appeal to C programmers having varied experience and interest.

Not really.

Fundamentally, this is a newbie project. It's indistinguishable from a
million other projects written by first-year CS students. You've had it
explained why this is simply not topical to comp.lang.c, and you've
continued to post, ignoring that.

The fact is, you're not discussing C. You're not interested in discussing
C. You want to promote your software, and that makes your posts spam,
indistinguishable from any other spam we get. If you have questions about
C, please post them. If you'd like to advance claims about C, go right
ahead. But if all you're going to do is pimp your program, please do so
in a more appropriate newsgroup.

I am frustrated here, because you clearly have many of the traits that would
make for an excellent programmer, but you lack the most important: The
ability to accept that you fucked up, and learn from your mistakes, and stop
making them. "Hubris, laziness, and narcissism" are not the essential virtues
of an effective programmer.

You were wrong. Your program is poorly-written (fine for a newbie project,
but it's nothing anyone else would necessarily want to use.) Your ads for
it are consistently off-topic. You persist in posting them after having
that corrected and explained. You have great opportunities here to learn
from what other people have done, but instead, you carefully ignore them
because you're not comfortable with just coming out and saying you screwed
something up.

Move on. Drop the pretentious name (dh is already in use, and you've been
told that!). Stop advertising this useless program. If you want to learn
about C, start asking questions. Many of the questions that this program
raises are fundamentally Unix questions, rather than C questions, but that's
okay, there's Unix newsgroups too; you could learn about Unix by asking those
questions in a Unix newsgroup.

Stop hiding behind "you can email me if you have comments". If you aren't
interested in participating in a discussion, your posts are spam -- and yes,
they will get reported as spam. And it is not implausible that your ISP
would agree with this evaluation -- most ISPs are pretty clear on the
difference between participation in Usenet and spamming advertisements to
Usenet.

In short, grow up. You could do better than this. You are passionate about
contributing. If you want to contribute, you'll have to learn to do so. I
assure you it is worth it. Learning to admit that you don't know things, and
that you're wrong, is painful. It's also the only way to get better.

-s

 

[Seebs]

Traditional trolls write on a newsgroup and never listen. Some time
ago (a few days, maybe a couple of weeks), I posted a suggestion for
significantly improving the readability of your code. You have never
replied to that suggestion. You have not incorporated that suggestion
into your code. I conclude that you are not interested in feedback on
your code. So why post it?

Even if he was interested in feedback on the code, a great deal of it simply
isn't topical here.

That said, I think it's more significant that there's a 12-year-old program
out there which does all of this correctly. (Fascinating coincidence: The
original checkin was apparently by the guy who is now my boss at $DAYJOB.)

-s

 

[Seebs]

Nevertheless, my comments /were/ topical, and it was a shame that he
never bothered to read them, as they would have improved (and
shortened) his program dramatically.

Yeah.

That's the underlying reason I don't take him seriously; he's clearly
gotten caught up in defending his ego more than in trying to make good
code.

That way lies madness.

No, I don't see how that's significant at all. After all, the same is
likely to be true of /any/ program posted here for comment.

It's significant to his claims, because the other program appears to
be able to do everything this one does (except for the things that shouldn't
be done), and is a lot closer to standard conventions -- undermining the
claim that the toy program has the potential for standardization. (Not
completely refuting it, mind; I will not be surprised if some day POSIX
standardizes a particular breed, such as "calico", of cat(1), because
someone told them it was important existing practice.)

-s

 

[Seebs]

Yes, but his claims aren't significant!

They can be -- looking at his other claims can help us understand whether
it's likely to be productive at all to talk to him about the code.

What matters is the C code,
right? And the existence of prior art has, as far as I can tell,
never been a big deal with regarding to giving code feedback. Nobody
tells a "hello world" guy not to bother because it's already been
done.

Someone who posts "I am trying to learn about programming, here's my
hello world, what do you think?" Sure. But if someone posts under the
topic "hw, the greeter", explaining that his new program "hw" was
written because there simply weren't any programs out there which greeted
people in a useful manner, then gets outraged when people suggest that
maybe he shouldn't be posting ads for his program in random programming
groups, then it starts being relevant.

If he were discussing the code, I'd agree that it doesn't matter that
it's been done already; learning exercises are fun. But if all he's doing
is advertising, and a quick search confirms that he mostly refuses to accept
or react to criticism, then it's not so good.

For instance, consider the name. "dh". Well, that name was already in
use a LONG time ago -- debhelper 2.0 released in 1999, and the initial
design work happened in 1997. Now, sure, accidents like this happen. But
let's see what our intrepid adventurer does when someone points out
the clash:

http://www.mail-archive.com/[email protected]/msg259265.html

Here we see...

Well, let's try to itemize, because the list is big.

First, this was a posting to a *PYTHON* list. Remember how he said he
posted it here because it was in C? Apparently, he was lying. He's
just spamming it any old place.

Second, let's look at his response when someone points out that his brand
new program, announced in 2009, clashes with a program which has been
in widespread use and production for OVER TEN YEARS:

Until now, I was unaware of debhelper.

It's hard to find a short name not already taken. I decided that
dh was a good representation of its function, and I wanted a two
character name that's easy to use with minimal keystrokes.

I apologize to debhelper users, but I have no desire to change the
name of daemon helper now.

dh is its name; a natural companion to sh.

That's pure narcissism. It's not remotely sane or reasonable. It's not
how serious developers work. Think about it. What's his user base? Do
we have any evidence that there *exists* a user base beyond the original
spammer? I don't. So how many people will be affected if he renames it
in some way? For that matter, why on earth would it MATTER that the
name is short? Daemonizing a program is usually something that happens
in startup scripts, not something you type all the time.

His rationale for not fixing the clash is telling. He has "no desire" to do
so. Note: Only his desires are even part of his world. The question of
whether his actions might affect other people is *incomprehensible* to him.
He doesn't have the notion that other people might want something. You
can corroborate this with a look at his explanation of why it is suitable
for standardization:

Producing a universal tool takes time, trial, and error, and I have
gradually refined dh to meet my needs. It has the potential to
become a standard tool,

Note: "universal" ... "to meet my needs".

I can't find a single reference to this thing prior to August of this year,
although it's hard to tell; he has simply flooded the world with off-topic
posts about it, posting in Tcl, awk, and Python groups, various Unix-related
groups (none particularly topical), and so on.

In this case, that is much more significant than the code, because knowing
that he simply does not perceive other people as having desires, needs, or
importance saves you a TON of time. You don't need to read his code, or
respond to it. He can't hear you. Unless you're praising him, all he gets
is the vague impression that there's a noise.

In short, there's nothing to give feedback on. The program's useless for
a number of reasons, and that's because he doesn't understand, and that in
turn is because it's *impossible* for him to learn about requirements or
use cases that don't come from his own specialized uses -- to do so, he'd
have to be able to interpret other peoples' statements of requirements or
preferences as something other than rudeness to himself. He can't.

Unless you can fix that, you can't fix his code.

-s

 

[Seebs]

You have to learn to read between the lines, Seebs. That's just his
way of saying "I am trying to learn about programming, here's my
hello world, what do you think?"

This is certainly a reasonable inference, without the other information.
Indeed, that was my first thought. However, having observed how he handles
various sorts of criticism and interaction with the broader dev community,
I no longer think that. Simply put, that kind of willingness to learn,
even veiled, is inconsistent with what we've seen.

-s

 

[bartc]

For instance, consider the name. "dh". Well, that name was already in
use a LONG time ago -- debhelper 2.0 released in 1999, and the initial
design work happened in 1997. Now, sure, accidents like this happen. But
let's see what our intrepid adventurer does when someone points out
the clash:

Is the name really an inherent part of the program? I would have thought, if
there was a clash, someone could just... rename it.

And if "dh" is referenced inside the code, then maybe _that_ should be a
criticism.

(My only criticism is that the OP assumes everyone knows what a daemon is,
which I don't; not even Wikipedia was very enlightening. For all I know this
program, consisting mainly of error messages, is just a joke.)

 

[John Kelly]

ago (a few days, maybe a couple of weeks), I posted a suggestion for
significantly improving the readability of your code. You have never
replied to that suggestion. You have not incorporated that suggestion

I don't see every post. I'm more likely to see email copies. For that
purpose, I post my real email address.

Anyone can use it. However, trolls and flamers become filter fodder.

John Kelly <[email protected]>

 

[John Kelly]

if there was a clash, someone could just... rename it.

A universal utility trumps a distro utility.

I'm not renaming the daemon helper; dh is its name. The name I chose
does not conflict with any other *NIX variant. Debian is not important
to me.

 

[Nick Keighley]

(My only criticism is that the OP assumes everyone knows what a daemon is,
which I don't; not even Wikipedia was very enlightening. For all I know this
program, consisting mainly of error messages, is just a joke.)

a daemon is a unix term for a program that (usually) runs continuously
providing some service (eg. FTP). The nearest windows equivalent is
a Service.


--
Yeats defined daemons as
"that which we continuously struggle against yet paradoxically
need in order to survive, simultaneously the source of our pain and
of our
strength even in some sense the very essence of our being. [The
daemons is]
of all things not impossible the most difficult."
Essential Unix System Administration

 

[Keith Thompson]

A universal utility trumps a distro utility.

I'm not renaming the daemon helper; dh is its name. The name I chose
does not conflict with any other *NIX variant. Debian is not important
to me.

Your last statement is inconsistent with your claim that it's a
"universal utility".

I've got this great new program, a Comprehensive Archive Tool. Just
install it as /bin/cat. (Concatenating files is unimportant to me.)

 

[Nobody]

This is not, strictly speaking, written in "C". It is written in C+POSIX.

Requiring external libraries isn't the same thing as being "not C".

Suppose that I write a program consisting of multiple files, none of which
use any feature or function which isn't dictated by the language
specification. Then I modify the build process to make libraries from some
of the object files, and link against the libraries rather than linking
against all of the individual object files. Then I package the source code
into separate "program" and "library" archives, which can be downloaded
separately. Then someone else takes over maintenance and distribution of
the library part.

At what point do the source files for the main program stop being
"written in C"?

 

[John Bode]

[snip]

Like a daemon, touch(1)'d for the very first time,
Like a daeee-eee-eee-ee-mon, but the scheduler's gone offline...

 

[Seebs]

Is the name really an inherent part of the program? I would have thought, if
there was a clash, someone could just... rename it.

Yes. But by long-standing convention, in the face of a clash, you rename
the program preemptively so people don't have to.

Consider the case of a packaging system confronted with two programs named
"dh". How should it decide when or whether or how to rename them?

So traditionally, when people encounter clashes, they correct them by
renaming, and usually, a program under a month old with no user base would
rename rather than continue to clash with a program over a decade old with
a user base of millions.

(My only criticism is that the OP assumes everyone knows what a daemon is,
which I don't; not even Wikipedia was very enlightening. For all I know this
program, consisting mainly of error messages, is just a joke.)

It's a fairly common convention in Unix-like systems for "program which
runs in the background".

-s

 

[Seebs]

A universal utility trumps a distro utility.

It's not "universal". It's just your personal hobby horse. It is of no
use to other people.

If you had users across a dozen platforms and a history, you'd have a case.
You don't, and you don't.

I'm not renaming the daemon helper; dh is its name.

No, dh is debhelper's name.

The name I chose does not conflict with any other *NIX variant.

Hint:

Ubuntu is a kind of debian. Millions of users.

Debian is not important to me.

This is why I consider you a narcissistic idiot. You justify all engineering
decisions in terms of what is important *to you*. Your "utility" is not
universal; it's useful only to you, only on the particular systems you
care about.

As long as you have this attitude, your program will never be of use to other
people, and announcements of it will be nothing but spam.

It's not universal, it's not much of a utility, and your attitude guarantees
that it could never become one. Hypothetically, perhaps someone else
could turn it into one. But...

1. They'd immediately change the name.
2. There is no possible reason for them to use your buggy program which
violates standard UNIX conventions instead of the other freely available
ones which don't.

-s

 

[Seebs]

Anyone can use it.

Except users of Debian, or Ubuntu. Or Scratchbox. Or...

Oh, wait. That's right. They're not *you*, so they're not important.

-s

 

[Phil Carmody]

Your last statement is inconsistent with your claim that it's a
"universal utility".

I've got this great new program, a Comprehensive Archive Tool. Just
install it as /bin/cat. (Concatenating files is unimportant to me.)

If it ever becomes important, then you can use my Linear Streamer
utility.

Phil

 

[Phil Carmody]

Ubuntu is a kind of debian. Millions of users.
....
2. There is no possible reason for them to use your buggy program which
violates standard UNIX conventions instead of the other freely available
ones which don't.

Can you please go and beat up the idiots at Canonical (behind Ubuntu)
too, for the same reasons?

Phil

 

[Seebs]

Can you please go and beat up the idiots at Canonical (behind Ubuntu)
too, for the same reasons?

Which program were you thinking of specifically?

More importantly, have they advertised it in this group repeatedly?

-s

 

[Phil Carmody]

Which program were you thinking of specifically?

initctl.

More importantly, have they advertised it in this group repeatedly?

Fortunately not. However, I consider initctl a spammer.

Phil