Hi Didier,
On 17.03.2015 19:00, Didier Kryn wrote:
The common practice of daemons to put themselves in background and
orphan themself is starting to become disaproved by many designers. I
tend to share this opinion. If such a behaviour is desired, it may well
be done in the script (nohup), and the "go to background" feature be
completely removed from the daemon proper. The idea behind this change
is to allow for supervisor not being process #1.
Ack, for the case the daemon does not allow to be used with an external
supervisor.
Invoking a daemon from scripts is no problem, but did you ever come in a
situation, where you needed to maintain a system by hand? Therefor I
personally vote for having a simple command doing auto background of the
daemon, allowing to run from a supervisor, by a simple extra parameter
(e.g. "-n"). Which is usually no problem, as the supervisor need any
kind of configuration, where you should be able to add the arguments,
the daemon gets started with. So you have to enter that parameter just
once for your usage from supervisor, but save extra parameters for
manual invocation.
Long lived daemons should have both startup methods, selectable by a
parameter, so you make nobodies work more difficult than required.
Dropping the auto background feature, would mean, saving a single
function call to fork and may be an exit. This will result in a savage
of roughly around 10 to 40 Byte of the binary (typical x86 32 bit). To
much cost to allow both usages?
Could you clarify, please: do you mean implementing in netlink the
logic to restart fifosvd? Previously you described it as just a data
funnel.
No, restart is not required, as netlink dies, when fifosvd dies (or
later on when the handler dies), the supervisor watching netlink may
then fire up a new netlink reader (possibly after failure management),
where this startup is always done through a central startup command
(e.g. xdev).
The supervisor, never starts up the netlink reader directly, but watches
the process it starts up for xdev. xdev does it's initial action
(startup code) then chains (exec) to the netlink reader. This may look
ugly and unnecessary complicated at the first glance, but is a known
practical trick to drop some memory resources not needed by the long
lived daemon, but required by the start up code. For the supervisor
instance this looks like a single process, it has started and it may
watch until it exits. So from that view it looks, as if netlink has
created the pipe and started the fifosvd, but in fact this is done by
the startup code (difference between flow of operation and technical
placing the code).
Well, this is what I thought, but the manual says an empty end
causes end-of file, not mentionning the pipe being empty.
end-of-file always include the pipe being empty. Consider a pipe which
has still some data in it, when the writer closes the write-end. If the
reader would receive eof before all data has bean consumed, it would
lose some data. That would be absolutely unreliable. Therefore, the eof
is only forwarded to the read end, when the pipe is empty.
*Does anybody know the exact specification of poll behavior on this
case?*
My experience, with select() which is roughly the same, is that it
does not detect EOF. And, since fifosvd must not read the pipe, how does
it detect that it is broken?
Not detect? Sure you closed all open file descriptors for the write end
(a common cave-eat)? I have never bean hit by such a case, except anyone
forgot to close all file descriptors of the write end.
No, they should still be processed by the handler, which then stumbles
on the eof, when all event messages are read.
See above. It would make sense but the manual does not tell that. I
bet the manual is wrong, in this case.
It's the working practice of pipes in the Unix world, may be the
specification of this goes back to K&R in the 1970th.
PS. I inadvertently went out of the list. Just my habit to click
"reply". I leave it up to you to go back to the list.
I tried to set a CC to the list, but got a response the message has bean
set to hold, but I try doing it vice versa.
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
