Steve Langasek writes:
> On Mon, May 27, 2013 at 11:58:13AM -0700, Nikolaus Rath wrote:
>> As I said, there isn't a bug anywhere here. Once you understand what's
>> going on, this all makes sense. But I don't consider this a very good
>> design.
>
> Well, I don't think it's a bad design that third
On Mon, May 27, 2013 at 11:58:13AM -0700, Nikolaus Rath wrote:
> The only way to avoid this (at least at the time I reported the bug),
> would have been to recompile mountall to emit events with --no-wait (but
> I'm not sure what other unintended consequences that would have had).
Lots of them. T
Wouter Verhelst writes:
> On 26-05-13 15:11, Holger Levsen wrote:
>> Hi,
>>
>> On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
>>> For example: after some intense studying, I now fully understand why
>>> declaring a new upstart job C that depends on existing jobs A and B
>>> ("start on job-a-did-i
On 26-05-13 15:11, Holger Levsen wrote:
> Hi,
>
> On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
>> For example: after some intense studying, I now fully understand why
>> declaring a new upstart job C that depends on existing jobs A and B
>> ("start on job-a-did-its-thing AND job-b-did-its-thing"
Hi,
On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
> For example: after some intense studying, I now fully understand why
> declaring a new upstart job C that depends on existing jobs A and B
> ("start on job-a-did-its-thing AND job-b-did-its-thing") may prevent the
> start of job A (cf
> https://
❦ 24 mai 2013 12:29 CEST, Dmitrijs Ledkovs :
> The best way to run daemons under upstart is in foreground, then
> correct PID is tracked and the complete stdout/stderr is properly
> collected and stored in /var/log/upstart/$job.log (even early boot
> output).
The best way to run a daemon under
Dmitrijs Ledkovs writes:
>> Also on technical merits although more philosophically, with Upstart you're
>> expressing yourself in an event-based DSL rather than writing configuration
>> files. It's pretty generic. But unfortunately, that means it's also not
>> entirely straightforward, and, I beli
On Fri, May 24, 2013 at 12:29:07PM +0100, Simon McVittie wrote:
> On 24/05/13 11:29, Dmitrijs Ledkovs wrote:
> > As far as I understand (correct me if I am wrong), systemd instead of
> > counting/tracking forks uses cgroups to keep track of the started
> > processes.
> systemd uses cgroups to trac
Dmitrijs Ledkovs debian.org> writes:
>> Also on technical merits although more philosophically, with Upstart you're
>> expressing yourself in an event-based DSL rather than writing configuration
>> files. It's pretty generic. But unfortunately, that means it's also not
>> entirely straightforward
On 24/05/13 11:29, Dmitrijs Ledkovs wrote:
> As far as I understand (correct me if I am wrong), systemd instead of
> counting/tracking forks uses cgroups to keep track of the started
> processes.
systemd uses cgroups to track "which processes are part of this
service?", which means the services ma
On Fri, May 24, 2013 at 11:29:27AM +0100, Dmitrijs Ledkovs wrote:
> Blog posts are interesting to read, but at times I'd like to look up
> reference manuals which are more than bear minimal man pages. Whilst
> systemd ships manpages, the website has either incorrectly formatted
> wiki-pages and/or
On 23 May 2013 10:37, Ole Laursen wrote:
> Steve Langasek debian.org> writes:
>> Sorry you ran into trouble with upstart.
>
> Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic
> of Upstart, I have some technical comments on why, surprisingly, I think it
> may not be matu
On 05/22/2013 06:19 PM, Steve Langasek wrote:
On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote:
On 05/22/2013 04:50 AM, Uoti Urpala wrote:
Lucas Nussbaum wrote:
I went through the various init systems threads again during the last
few days. My understanding of the consensus so fa
Steve Langasek debian.org> writes:
> Sorry you ran into trouble with upstart.
Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic
of Upstart, I have some technical comments on why, surprisingly, I think it
may not be mature enough yet.
A couple of years ago I was doing em
On 05/22/2013 06:19 PM, Steve Langasek wrote:
> I'm skeptical of the value of such a design in place of just using
> an initramfs, but the 'friendly-recovery' package in Ubuntu gives
> an example of to do this.
live-config-upstart needs the same to be useful. personally i have no
experience with u
15 matches
Mail list logo
