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
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 to have your daemon p
> 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 f
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 the fork-parent() functi
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 Techniques
of the Succ
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 completely different set
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 dev
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
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 number
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
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.
I
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 amd6
On 15.04.2017 10:24, 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"
>
> and using:
>
> --git-pbuilder
>
> as an argument for git-buildpackage. All the build depend
On 14.04.2017 22:42, goli...@dyne.org wrote:
> Perhaps these pages will help to clarify Devuan's naming scheme and
> packaging protocol:
>
> https://devuan.org/os/filenaming
release and file names - different area.
> and
>
> https://dev1galaxy.org/viewtopic.php?id=549
hmm, it seems to assume
It's on my to-do list to give this a shot again but my available free time is
constrained by family priorities. If nothing else, I'll slowly plug away at it
as time permits.
On April 14, 2017 4:04:06 AM CDT, "Enrico Weigelt, metux IT consult"
wrote:
::On 08.03.2017 18:59, goli...@dyne.org wrot
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 me
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 usefulness of a system
> >
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 i386+amd6
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 chroot jail by the
following
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 IRC Channel), one
20 matches
Mail list logo
