Re: [DNG] Openrc

[poitr pogo]

I agree.
In perfect world of knowlegable programmers writing software that works
there is no need for supervisors.

One can handle errors or leave this for supervisor.

For me supervisor will always be a tool of a helpless admin.

Regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd greybeards

[poitr pogo]

15.08.2016 22:31 "Brian Nash"  napisał(a):
>
> I still don't see the point of using containers, though.

For quite a few modern java developers it is easier to dump their
development workstations into a docker images than write a deployment
specification, i believe.
For quite a few system admins it is easier to pickup a docker image and
leave responsibility to developer than setup application from scratch which
often requires reading documentation, if exists.
And business loves things can be done quicker, read cheaper.
--
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts

[poitr pogo]

On 5/6/16, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote:
> poitr pogo <lepo...@gmail.com> writes:
>> On 5/6/16, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote:
>>
>> (...)
>>> I'm dealing with a program where every allocation failure is
>>> meticolously passed up the call stack so that the top-most function can
>>> then cause the process to terminate and I've just recently decided that
>>> this is completley useless and that I want to get a message what failed,
>>> followed by program termination close to the point of failure
>>> instead. Using a null pointer deref to this effect is an IMHO clever
>>> idea I didn't think of so far.
>>
>> Good for you.
>> Who will clean up  resources if you are using some (temporary files,
>> shared memory, etc).
>> System administrator?
>
> What's the base for your assumption that this would be a problem in the
> given situation?
>
> [...]
>
>>> NB: I'm not yet convinced that I'll end up using it but it's surely
>>> something to consider.
>>
>> Hope not using your applications , no offence, just wasted over a year
>> of my life supporting similar beast -
>
> And do you have something of any substance which would justify this
> "ignoramus recommendation"?


This is your code, these are your designing decisions.

I'm just saying that if I were in position of a customer, knowing the
software is designed/programmed the way you described I would not
spend my money on it for no apparent reason.

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts

[poitr pogo]

On 5/6/16, Rainer Weikusat  wrote:

(...)
> I'm dealing with a program where every allocation failure is
> meticolously passed up the call stack so that the top-most function can
> then cause the process to terminate and I've just recently decided that
> this is completley useless and that I want to get a message what failed,
> followed by program termination close to the point of failure
> instead. Using a null pointer deref to this effect is an IMHO clever
> idea I didn't think of so far.

Good for you.
Who will clean up  resources if you are using some (temporary files,
shared memory, etc).
System administrator?

I know,  memory is cheap, java programmer time is expensive nowadays.

:D

>
> NB: I'm not yet convinced that I'll end up using it but it's surely
> something to consider.

Hope not using your applications , no offence, just wasted over a year
of my life supporting similar beast -

try {
 parseAndSaveImportantDataToFile()
} catch ( Exception dummy) {
   /* java programmer time is expensive */
}

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.

sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
also cannot coexist.

so openrc is not an init subsystem on its own.

deamontools  are IMHO helpers for broken software like java application
which cannot daemonize itself under unix becaouse of java desing. trying to
convince people that writing unix daemons the old way is badthing(tm).

maybe i should go back to sls.
--
regards
piotr
04-05-2016 18:49, "Steve Litt"  napisał(a):

> On Wed, 4 May 2016 09:54:37 -0400 (EDT)
> Rob Owens  wrote:
>
> > - Original Message -
> > > From: "Steve Litt" 
> >
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > Rob Owens  wrote:
> > >
> > >> I agree with putting each init in its own directory, but sysvinit
> > >> should not own /etc/init.d.  sysvinit stuff should go
> > >> in /etc/sysvinit and by default /etc/init.d should be a link
> > >> to /etc/sysvinit/init.d. The reason is that other init systems may
> > >> expect to own /etc/init.d. For instance, openrc puts all its
> > >> scripts in /etc/init.d (at least on Funtoo it does).
> > >
> > > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > > and the only one I know that wants to do that is systemd.
> > >
> > > I wouldn't change sysvinit's expected files one little bit. Everyone
> > > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > > change to sysvinit would require lots of testing, and who needs
> > > that headache?
>
> > Then you would be designing under the assumption that sysvinit is the
> > "one true way"
>
> Not "one true way", but "it's what we have right now, let's not mess
> with it.
>
> > and that all others must be modified to work around
> > sysvinit -- an init system that you/we are actively attempting to make
> > obsolete (eventually) by way of providing all these alternatives.
>
> The other inits should have had the good sense not to entangle
> themselves with sysvinit, and in fact most of them did have that good
> sense, so for them this is a moot point.
>
> At this point I'm not sure that *any* init system other than sysvinit
> puts its daemon starting code/config under /etc/init.d. But if there is
> such an init system putting its stuff under/etc/init.d, that's some
> serious hubris. They could have taken their own namespace, but no,
> they polluted the namespace used by sysvinit for 30 years. If there is
> such an init system, moving their script/config storage is actually
> correcting a problem caused by the init system.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.

But in such a case I probably would not care what kind of init
subsystem is running on my box. I would not wait for Devuan to get
something with sysvinit.

So if I'm stick to sysvinit why I am to use 'service'? Why learn
another wrapper name which does one thing more if I can always do

env /etc/init.d/blabla start

If I want to have clean environment when starting this script.

But I cannot imagine why should I even use 'env' command (in ideal
world). The init script should use it if it is important that the
environment is cleaned up before starting the application daemon ( or
service if you want to call it this way). This is responsibility of
application maintainer to provide 'idiot proof' starting script.  The
assumption that 'service' command will prepare environment is IMHO  a
mistake, cause the init script _can_ be executed directly as it was
done for a long time, before 'service' command was introduced.

Yes, I think it was bad design decision to make 'service' command to
cleanup environment, not leaving this task to  init script, because of
legacy of /etc/init.d , and because the init.d scripts  can be
executed directly anyway.

If 'service' command  was running scripts from other
folder/schema/subsystem, but not from well known /etc/init.d, than I
would say I should obey the rules of the new command, once decided i
want to use it.

So, please make the system suit your needs, but do not assume what are mine. :)

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

IMHO i would expect package init scripts for default init system to be part
of a package (binary,base, etc) and scripts for alternate systems to be in
separate package(s).

Of course all residing in single src package maintained by the devuan
package maintainer.

Someone who decides to use alternate init is in some sense on his own, but
has all available scripts in packages so can install them.
Or the package for alternate init system can provide helper tools to
install available packages and even inform the user which packages have
missing scripts for selected alternate init system and have to be provided
manually.

So several init systems can coexist with one beeing more priviledged than
others.

Some enthusiast may even provide single package with all available optional
init scripts for all applications. Whatever suits.
Several options, one default with strict rules.

Regarding handling init scripts for different inits, the only hard moment i
can imagine is the time when devuan comes to decision to select new init
system as a default one.

But even then it will probably happen with a new release.
So all packages will be recreated including by default init scripts for new
system. And moving old sysvinit into separate, additional package, making
sysvinit optional.

--
Regards
piotr
written using my smartphone
03-05-2016 13:18, "KatolaZ"  napisał(a):

> On Tue, May 03, 2016 at 12:18:37PM +0200, parazyd wrote:
> > On Tue, 03 May 2016, KatolaZ wrote:
> >
>
> [cut]
>
> > > Why we don't just ship the init scripts for each system with the
> > > corresponding service, install them "somewhere else" (e.g.,
> > > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been
> > > already suggested by others) and then copy (or symlink) the
> > > corresponding directory in /etc/ only when the user selects "wtf" as
> > > init system?  This could be managed much more easily by
> > > update-alternatives, which has just to update two symlinks, e.g. he
> > > one corresponding to /sbin/init and the one corresponding to it's
> > > bloody scripts directory...
> >
> > This is very much a hack. Not really a good way to do it. As Dan says,
> > submitting patches to the already existing packages is a much more
> > elegant way. I think Dan proposed a very good thing, almost a complete
> > solution.
> >
>
> I am not against submitting patches to existing packags to include
> init scripts.
>
> Only, whatever smart solution you come up with guys, please try as
> hard as possible to keep it as *simple* as possible, not a single bit
> more, not a single bit less. The fewer interactions we have among sets
> of init scripts belonging to different init systems (ideally, no
> interaction whatsoever), the easier maintaining them in the long run,
> and plugging in new init systems as yet unforeseen.
>
> Ideally, switching between init systems (e.g., reverting back to an
> init system which is known to work) should be achievable from a
> single-user root shell spawned as an emergency "init", using only a
> few executables in /bin and /sbin. Anything more complicated than that
> risks to become not that useful or even harmful in the long run, IMHO.
>
> PrimoDevuanStabilisCreandaEst
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan Security Repo (was Re: invalid security certificate)

[poitr pogo]

So now, when information on web site is correct please consider removing
'mirrors'  workaround so it will not get propagated. And clear message will
be sent to users which address should be used.

Once removed people will be forced to clean their setup now, and new
mistakenly created setups will simply not work. The small mess will be
cleaned fast.

Proper message on web page, for those who read old outdated mails/post
might be helpful.

But once the official info is corected, remove the 's' workaround when the
cost of removing it is rather small.

IMHO

--
Regards
piotr
03-05-2016 12:52, "hellekin"  napisał(a):

> On 05/02/2016 09:15 AM, Arnt Gulbrandsen wrote:
> > helle...@dyne.org writes:
> >> auto.mirrors does not exist: only auto.mirror does.  Unknown names point
> >> to www.devuan.org.
> >
> > Auto.mirrors exists as of yesterday. It was on the devuan home page due
> > to a typo. Nextime made the typo work, then fixed the typo.
> >
>
> Indeed.  Hopefully this is the last instance of a typo going into
> production.  Wrong links have a cost: compare with losing bitcoins,
> related to the namespace; multiple links to the same resource is Bad™.
>
> So even if auto.mirrors exists, you shouldn't use it nor rely on it, and
> consider it doesn't exist.  The link might be removed in the future, so
> if you're currently using mirrors with an s, use mirror instead.
>
> ==
> hk
>
> --
>  _ _ We are free to share code and we code to share freedom
> (_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

I vote for init to be default for at least few years.
Devuan might consider switching to something else few years after
wheezy lts will be dead.

Meantime, all other init systems should be optional in Devuan.

--
Regards
Piotr

On 5/3/16, Steve Litt  wrote:
> On Mon, 2 May 2016 21:05:18 -0400
> Hendrik Boom  wrote:
>
>> Is there a summary of some sort explaining the various init systems,
>> how they're put together, how they work, and especially the salient
>> points on which they differ?
>
> I've tried. See
> http://troubleshooters.com/linux/init/features_and_benefits.htm#init_system_feature_matrix
>
> Keep in mind these two things:
>
> 1) I'm an order of magnitude less knowledeable on init systems than the
>average person on the supervis...@list.skarnet.org mailing list.
>Those guys found several mistakes in my matrix, and I'm not sure I
>corrected all of them.
>
> 2) Like everyone else, I have likes, dislikes and maybe an agenda. I'm
>a huge fan of daemontools-inspired inits, and I have a significant
>dislike of systemd.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[poitr pogo]

On 2/25/16, Rainer Weikusat  wrote:
(...)
> Considering that shared objects and dynamic linking were originally a
> MULTICS feature (dating back to about 1965) and introduced to UNIX(*)
> with SunOS 4.0 in 1988, the best course of action to deal with people
> who are so afraid of changes that they keep rejecting "useful new
> features" for 51/ 28 years in a row is "roundly ignore them". Especially
> if they claim to be 'modernizers' because the ancient technology they're
> so wedded to is so seriously ancient that large groups of people
> meanwhile forgot about that ...
> ___


Is this some kind of pro systemd propaganda ? :D

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)

[poitr pogo]

29-09-2015 16:48, "Steve Litt"  napisał(a):
>

> I thought it was stupid for other reasons, but now that you mention it,
> yeah, naming it after the particular slot into which it's plugged in is
> stupid, and if you take the box apart and move things around, you can
> break your OS.
>

no. it is not stupid. it is the most reasonable way. one can replace a part
and do not have to touch any system config.
but that's too hard to locate a part for common desktop user and we get a
user frienfly system which is bound tight to the detsils of the hardware it
is using and have to reconfigure itself every time new part is added. even
temporary. and finaly another layer of abstraction is invented, dynamic
reconfiguration instead. all to speed up boot process.

device by manufactuter name or model name or serial. this is stupid.

--
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide

[poitr pogo]

i'm against moderation.
if you find his posts disturbing use killfile instead.

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide

[poitr pogo]

Hi,

On Fri, Aug 28, 2015 at 5:00 PM, Michael Bütow mbu...@houtbay.com wrote:
 Article here:

 https://tlhp.cf/lennart-poettering-su/

 I for one look forward to not having any of this madness one day when I
 transition completely to Devuan!



This is rather good news, as this is extension to systemd not to su.

As systemd is it's own echosystem of some kind, with all that new
session/terminal/process  management using cgroups, etc. it is natural
that it needs su-like feature, which will handle all this systemd
internals properly.
IMHO systemd is some kind of  an android like layer between kernel and
desktop applications, providing it's own api/libraties/sdk.
I bet gnome will became a GUI part of systemd at some point. With API
allowing building linux based applications using html5 :D
It would be perfect if it develops own tools (like this one) instead
of modifying the existing ones.

So let them build desktop oriented linux, and let us focus on the
server oriented version.

regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] automount, mount, and USB sticks

[poitr pogo]

IMHO automount for desktop is a helper for a user running some X
session. Usually that means that a single person is using this system.
So make him a helper which can do automount/autorun etc which helps
him on a daily basis. Helps him not the admin of the system.  A simple
one which is a helper, not a policeman/guardian/supervisor who
monitors and authorizes user's actions.

I understand that sysadmin of a server  with many different users will
not install such thing on his system, cause this make be used to break
security.

If the tool is simple enouth to do limited number of actions, it can
be audited and secured and maybe some day it will be accepted even on
multiuser systems.


There is also automount for a sysadmin on a multiuser server, with no
X sessions, which makes life of sysadmin easier.

Same name two different targets. Same tool might be used for both, but
I personally would prefer to have two different ones.

For my X session perfect tool is a panel application listing available
devices with it's current/future  mount point, disk size/usage,
allowing mount/unmount/eject by mouse click.
It may have a checkboxes to automount/autorun new devices. I will not
use it, but I do not care if it is there  if it is not turned on or it
can be easily turned off.
It may list entries from fstab, autodiscoverd devices or even also
from it's own config file for those who want to put more complicated
mount/umount scripts.


For anything more complex su/sudo is better (for me).

I understand that there is a closed list of actions every user will
have to perform on any system while running interactive graphic
session. As such user would expect to have helpers for such actions
easily available (perfectly on desktop or as visible panel applets).
Later one will learn and choose the tools one wants and the way one
want to use them. And a fixed set of simple helpers visible on
desktop/panel would make a life easier.


On Thu, Jul 30, 2015 at 3:18 PM, Rob Owens row...@ptd.net wrote:
 - Original Message -
 From: Isaac Dunham ibid...@gmail.com
 I'm not sure where in the discussion this fits, but I thought I'd mention
 it here:
 Permitting all mount invocations via sudo does have a potential security
 hole if your mount implementation supports FUSE, as you can run an arbitrary
 command by specifying the mount type.
 I don't think that sudo does the necessary steps to block this.

 If you use a wrapper script, you can make it automatically determine the
 type and run ntfs-3g if appropriate, then allow sudo to run that.
 If you use a C wrapper, you can do that and make it suid.

 Another reason not to give users wholesale access to the mount command is that
 they could then 'mount -o remount,rw' any filesystem that the administrator
 has mounted read-only.  To protect against this, I think you probably need
 something a bit more complicated than just sudo.  Of course, for a single
 user system, this is not a problem.

 -Rob
 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Why daemontools is so cool

[poitr pogo]

Cannot. This is from the s6 docs. I'm not using s6. Just heard about it today.
Another s6 limitation - finish script must end in 3 seconds. or will be killed.
Nice for desktop, not a server.
It used to be that an application is responsible for proper start
up/shutdown procedure, as application  knows the proper way how to do
it. Init script is just a place where to hook a startup/shutdown
script to be executed when system needs to start/stop application in
some automatic way.

Now there are tools which help deamonize things.
Depending how portable they are it make the price one has to pay when
decides to use them instead of handling this yourself in the
application.

Regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Why daemontools is so cool

[poitr pogo]

On Sat, Mar 28, 2015 at 4:15 PM, Isaac Dunham ibid...@gmail.com wrote:
(...)
 If you want to *manage* a daemon (ie, do something when it stops, like
 restarting it), it's very tricky to do it reliably without having a fixed

It might be tricky if application does not support startup/shutdown procedure.
That's why I would expect application to provide a script to start/stop it.
I expect application to be tested on a system it is to be running on,
so developing a stop/start script is not a big deal comparing to the
whole test procedure.

 PID; daemonizing means close stdin/stdout/stderr, then
   if (fork()) exit(0);
 or some such thing (in other words, create a new process and exit the
 old one), so you do not have a fixed PID.

 On Linux, BSD, and older UNIX versions, this can be done thus:
   daemon(0,0);


How this can be done in java? ;)

Detaching from terminal, binding to reserved ports, dropping privileges, etc.


 Another s6 limitation - finish script must end in 3 seconds. or will be 
 killed.
 Nice for desktop, not a server.

 sysvinit /etc/init.d/sendsigs actually only allows 1 second.


I see it is skipping some processes (which have their own upstart
scripts, and others which are recorded in special file not to be
killed by sendsigs). So it (sendsigs) is for all the rest of processes
which do not care about how they should be stopped. Not for that which
provide its own start/stop scripts.
In case of s6 it is the limit for the finish script for particular application.

(...)

 My understanding is that s6 and some of the equivalent packages, such
 as daemontools, are fairly portable.

 They are generally not used as a way to offload daemonizing, but as a
 way to ensure that a service stays started. If you don't need that,
 you don't need them.


s6 advertises itself as init replacement.
I'm not using s6 or daemontools. I do not need them. Just learned
about them and I'm bit surprised thy tend to replace init instead of
being a good helpers for those who need them.

IMHO they came into existence cause more and more applications were
missing deamon part, to make sysadmin/programmer life easier. s6 doe
not support those which daemonize on its own, anyway :)

init has inittab for monitoring application which need continuous
restart by design like getty.

If a daemon needs to be monitored and restarted when it dies, bug
should be fixed.
I expect a deamon to work from start to stop command. No self stopping.
As workaround nohup, screen, while `true`,etc are enough to keep
system running until bug is fixed.

I do not like buggy software, so maybe that's why i do not need s6/daemontools.

just IMHO.

Regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Why daemontools is so cool

[poitr pogo]

On Sat, Mar 28, 2015 at 6:59 PM, Martijn Dekkers
devuan-li...@dekkers.org.uk wrote:

(...)

 They help to run as a unix daemon a program which is not written to be
 a unix daemon.

 No, sorry, you are wrong. They are supervisors, and as such they ensure any
 long-running job keeps running when it is supposed to.


No. They ensure the job will be started again if it stops for some reason.

:)
demons vs long running jobs.
programs designed and written to run in background  vs those logging
to stdout/stderr, but customer/business requires them to run in
endless loop

if we had time/money/knowledge we would make them proper daemons but
we did not have.

The product is not best quality but let's wrap it in a
beautiful,colorful,professionally looking piece of paper :)

 S6 even forces such a program must not handle daemon mode itself.
 That process must not background itself: being run by a
 supervision tree already makes it a background task.

 You say this like it is a bad thing.

naming myself an init replacement i am not supporting all old standard
unix daemons :)
it's not bad, it's funny
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng