Re: [DNG] /etc/debian_version

On Sat, Apr 15, 2017 at 01:06:53PM +0200, Jaromil wrote: > Yet I believe we should file this as a bug as /etc/debian_version is > not there on new installs. The /etc/debian_version file is checked by > an enormous quantity of scripts in all sorts of deployements, we have > encountered this problem

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 22:50:20 +0200 marc wrote: > > Concerning the fork-parent.c and fork-parent.h revealed at > > http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how > > you'd bind the fork-parent() function to the stuff your daemon > > actually does, in order

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> Concerning the fork-parent.c and fork-parent.h revealed at > http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how > you'd bind the fork-parent() function to the stuff your daemon actually > does, in order to have your daemon properly fork and then terminate the > parent when ready

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 08:14:48 +0200 marc wrote: > I have written up the details at > http://welz.org.za/notes/on-starting-daemons.html Concerning the fork-parent.c and fork-parent.h revealed at http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how you'd bind

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 13:50:22 -0400 Steve Litt wrote: Oops. Concerning my statement: > What I > wrote was based on "why would you not simply use a process supervisor > like systemd?" s/systemd/daemontools/ SteveT Steve Litt April 2017 featured book: Troubleshooting

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 19:12:31 +0200 marc wrote: > I appreciate that Steve likes the daemontools approach where the > server process stays in the foreground, and I have no quarrel with > the advice of including a -f foreground option... The daemontools > approach makes a

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Hello again Steve > > The TLDR is that "A good daemon should fork soon, but have the > > parent process exit only once the child is ready to service requests" > > > > Sadly it seems too subtle for many people and the concept goes > > un-noticed ... > > It's as subtle as a 10 megaton nuclear

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 00:04, Daniel Abrecht wrote: > I still think this isn't a problem the service manager should attempt to > solve. This is a situation where the database is temporary unavailable, > for which there are many possible reasons. The services which relay on > the database should be able to

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 03:17, Steve Litt wrote: > Sounds like a good idea, but it's not, for the following reasons: > > 1) There will be endless arguments about HOW each and every daemon will >let its init system know "I'm now ready for business". The number of >different ways will make the

[DNG] Devuan 1.0 RC and DistroWatch

How can you advertise to Devuan 1.0 RC in DistroWatch? Best Regrards | ISMAEL | ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 11:42, Steve Litt wrote: > Once upon a time, daemon self-backgrounding was necessary, and this nohup (or something similar) was not sufficient ? I don't know when start-stop-daemon was incarnated (related to daemontools ?), but IMHO it seems to handle the daemonizing quite well.

Re: [DNG] pbuilder w/ docker

On 15.04.2017 10:42, Adam Borowski wrote: > Nope, this doesn't work unless you either: > * have a multiarch mixed i386+amd64 on the host -- you need at least the > kernel to be amd64 (well, if the kernel is self-compiled you don't even > need multiarch) -- but why would you run i386 on an

Re: [DNG] /etc/debian_version

On Fri, 14 Apr 2017, Gregory Nowak wrote: > cat: /etc/debian_version: no such file or directory. > > I can probably put that file back, and all would be good. However, > my question is what is still looking for that file during apt-get > dist-upgrade, and more to the point, how can I make this

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 08:14:48 +0200 marc wrote: > > > Go on down your path, but I suspect not many people would cheer > > > at you in this camp... > > > > I can see the merit - on two points, technical and political. > > > > > On the technical side, I can see the

Re: [DNG] pbuilder w/ docker

On Sat, Apr 15, 2017 at 10:24:58AM +0200, aitor_czr wrote: > If you are in i386, you can build for amd64 build a chroot jail by the > following way: > > cowbuilder --create --distribution="jessie" --architecture="amd64" Nope, this doesn't work unless you either: * have a multiarch mixed

Re: [DNG] pbuilder w/ docker

Hi, On 04/14/2017 07:19 PM, "Enrico Weigelt, metux IT consult" wrote: Hi folks, anyone here already used pbuilder w/ docker ? (instead of, eg. cowbuilder) Or is there anything else that can do that ? --mtx If you are in i386, you can build for amd64 build a

Re: [DNG] We need to speak up

Hi, On 04/14/2017 01:13 PM, Jaromil wrote: What is GUIX ? distro-agnostic packaging system done right (aka using a functional language) https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html ciao Somebody talked about GUIX in the past (here or in the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> > Go on down your path, but I suspect not many people would cheer at you > > in this camp... > > I can see the merit - on two points, technical and political. > > > On the technical side, I can see the usefulness of a system > wide standardised service status reporting - making it easy > for