** Changed in: upstart (Debian)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
** Also affects: irqbalance (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps
And I'm happy to say that things are moving to systemd. My cron.conf now
looks #44 just so cron gets the right locale in 14.04. I'm baffled that
that's the best I can come up with with upstart. If there is a better
way, please enlighten me.
--
You received this bug notification because you are a
Nice tip MarcS. That is indeed better than the other workarounds.
Here, a quick script -- cleanup-upstart.sh -- that checks initctl list
for stalled processes and kills them:
#!/bin/sh
# vim: set ts=8 sw=4 sts=4 et ai tw=71:
upstart_spawn_and_stop() {
name=$1
pid=$2
pkill -xf 'slee
No, just look at the script stanzas used in the statd.conf or
winbind.conf as an example.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when par
This makes it impossible to use upstart with any daemon where you want
to source settings from /etc/default (using a "script" stanza).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
ini
I ran into this again and found a new (?) way of fixing the situation
once it has happened that is slightly less crazy than the exhaust-all-
pids script: The /proc/sys/kernel/ns_last_pid knob can be used to get a
process with the correct PID.
I used
echo $(($n-2)) | sudo tee /proc/sys/kernel/ns_la
holy cow, 2014 and this issue is not solved yet. I just got bitten by it
too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps ch
This issue also seems to be the cause of difficulties with minidlna if
the -R flag is added to rescan the media files directory because
minidlnad creates an additional process to do the rescanning. So if
expect daemon is used for the two process at startup, then the shutdown
runs into difficulties
** Changed in: upstart
Assignee: (unassigned) => James Hunt (jamesodhunt)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps c
I had a problem with john miller's bash script because bash didn't die
quickly enough for the microsleep to get re-parented by init (upstart),
so here is a better version:
#!/bin/bash
usleep 1 &
firstPID=$!
#first lets exhaust the space
while (( $! >= $firstPID ))
do
usleep 1 &
done
# [ will
I use it with respawn with out an issue just make sure you kill
everything/clean up in post-stop. I do the same kill/cleanup in pre-
start just to be sure.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs
John Miller: THANK YOU!!! Only thing is I'm not sure if this is
compatible with respawn
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when paren
** Changed in: upstart (Debian)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
To manage
I came up with a hack to use upstart with applications that fork more
than twice to use until the rewrite makes it downstream. It works for my
application on my system. YMMV.
1.start the application in the pre-start section
2.in the script section run a script that runs as long as the appl
Could upstart track an arbitrary number of forks? instead of limiting to
1 (expect fork) or 2 (expect daemon) could expect N be supported?
Also here is a bash script to exhaust the pid space if your system does
not have ruby.
pass the pid upstart is waiting for as an argument like this
exhaustPID
It seems to me that upstart could forget about a pid if it can verify
that it has in fact disappeared. I've seen quite a few people bit by
this bug in #upstart on Freenode and on various forum sites. Because I
think the impact is perhaps higher than we might have originally
anticipated, I'd suggest
** No longer affects: aiccu (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
To manage notifications about this b
** Changed in: upstart (Debian)
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
To manage n
** Bug watch added: Debian Bug tracker #582745
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745
** Also affects: upstart (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745
Importance: Unknown
Status: Unknown
--
You received this bug notification because y
Yeah, as Scott already mentioned, pidfiles introduce their own set of
problems, but also they aren't a solution for all use cases. E.g. the
daemon I was dealing with does not have any way to write out a pidfile,
forks multiple times, requires a script to do some setup before it's
launched, and is
oh, i see... this idea was turned down. sorry.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
To manage notifications ab
Given that the PID would be killed pretty much as soon as it started and
that you're most likely to trigger this while writing an unstart job for
a daemon, I'd agree that the potential for serious problems is low.
However, I don't think this is a user error/mistake, some daemons are
just more awkw
Peter, I understand that this is a dangerous bug. However, it is quite
detectable when a user has made the mistake, and avoidable by taking
care when creating new jobs. So I think Medium is appropriate, as there
are workarounds, and the potential for these problems is quite low.
--
You received t
According to Mark Hurenkamp's comment, severity of this bug should be set to
Critical.
Image your very important app got the same PID as non-existent process had.
Then Upstart:
- causes data corruption - imagine you are editing your photos and something
kills your application during rewrite of a
While implementing a new upstart script, i also ran into this problem,
and am now stuck with a job waiting for a non-existing pid.
I think the worst-case scenario has not been mentioned yet, which is
that when the actual pid does appear, it will be killed by this job
thinking it is the process it
Scott, would it be possible to add the thing that David Ressman
suggested, please? Something to manually reset a job state without
restarting the machine.
I'm a newbie to upstart and this bug is really annoying as it requires
me to restart my machine when I write the conf in a wrong way... Makes
d
Likewise to using a script stanza, this is also a problem when a script
that actually starts a daemon is specified in `exec'.
Although it wouldn't help with the original problem (avahi-deamon), for
scripts a workaround/fix could be if you could tell upstart the name of
the final executable, so it
** Changed in: aiccu (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
To manage n
I think I'm running into this bug on an Ubuntu Lucid server. I tried to
install the rsyslog package on this server, but the start / stop /
restart functions would never complete (hangs forever). In the end, I
had to abandon rsyslog and go back to sysklogd — bad solution, I need
rsyslog, but I obv
Out of curiosity, why can't a piece be written into init that allows one
to manually remove processes from the state table?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuc
Thanks Guido Scalise. That fixed it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon when parent reaps child
--
ubuntu-bugs mailing list
ubuntu-
Anand, there's a rather harsh workaround using a ruby script you can download
here:
http://heh.fi/tmp/workaround-upstart-snafu
It worked for me, but, as I said, the approach is quite "aggressive".
Basically it forks new dummy, short-lived, processes until the PID
sequence restarts. Then, when on
If I notice a start/killed or stop/killed job, is there any way to get
rid of it other than rebooting the machine?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with ex
I personally think being different from everyone else is a problem.
Also, this is the sort of bug that should be architecturally impossible
in an init system. init shouldn't have to track state perfectly to
function on the basic level of 'start jobs' 'stop jobs'.
I understand there are benefits f
This specific issue will be fixed in a future release of Upstart with
robust fork tracking. Is there a specific reason to switch? It’s not as
if there are better alternatives out there. :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
Thanks for your help Clint.
Is Ubuntu still intending to stick with upstart in future releases?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon w
Tim, I'm sorry that you're experiencing the issue. I believe that squid
may have always had this issue and we only stirred it up by updating
squid.
There is a really scary workaround available which is to create a
program that exhausts the pid-space until tracked pid exists again, and
then upstart
I've been bitten by this with squid after having to kill the squid
processes as a result of the upgrade process borking on 10.04 (LTS).
I was upgrading to this:
https://launchpad.net/ubuntu/+source/squid/2.7.STABLE7-1ubuntu12.2
replacing squid 2.7.STABLE7-1ubuntu12.
I assume I'm missing something
When will be that rewrite complete?
Or anyone has workaround, how to kill start/killed or stop/killed job?
It could be only one-time job / script.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/406397
This and bug #530779 are fundamental due to Upstart's use of ptrace()
for fork following - a rewrite of Upstart is in progress which uses
other newer kernel mechanisms to follow forks and would not be
vulnerable to this kind of issue. However there's no "quick fix" to it,
and no way to backport tha
** Also affects: pld-linux
Importance: Undecided
Status: New
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-b
I had the same problem with Upstart 0.6.5. Job locked at the 'killed'
state when the process Upstart waited for didn't even exist. This is
quite a serious problem as:
1. Can happen when the job 'expect fork|daemon' stanza does not match
what the process really does. And when it happens fixing the
** Changed in: upstart
Importance: Low => Medium
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
Oh, sorry, I completely misunderstood your message.
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
On Wed, 2010-04-07 at 18:47 +, Lars Düsing wrote:
> Has anybody forwarded this problem to upstream?
>
Ubuntu are upstream for Upstart (I wrote it!)
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/b
Has anybody forwarded this problem to upstream?
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu
For sanity's sake, I'm closing the Ubuntu tasks for upstream Upstart
bugs. I've experimented with having both, but it is just making bugs
hard to find now. Will use the policy whereby bugs on the Ubuntu
package exist in the Ubuntu packaging or patches only, any bugs in the
Upstart code are Upstre
Hi...
I got bitten by this bug earlier today.
I was attempting to set 'autossh' to be respawned, via a new
autossh.conf file. I copied the cron.conf file, and changed the exec
line to the appropriate autossh command line, and left the rest the
same. The mistake was that autossh doesn't fork int
I would vote for this to be higher priority. For anybody who doesn't
know 'old' init, it's frustrating to have to learn all the old syntax
just to get common stuff like Apache running properly. In my case, I
need a custom Xvfb service and there's nothing out there right now.
Apache already has ma
On Sat, 2009-12-12 at 09:55 +, Lars Düsing wrote:
> I'm wondering why this bug has a importance of "low", as it renders
> using upstart for many daemons (including apache, postfix and others) as
> impossible.
>
Because conversion of those daemons over to Upstart is not a priority;
just carry
Back to the bug itself again: A very evil solution would be checking the
"lowest" pid of the daemon (ok, you have to look out when pids are
starting again from zero again...)
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received thi
I'm wondering why this bug has a importance of "low", as it renders
using upstart for many daemons (including apache, postfix and others) as
impossible.
** Changed in: aiccu (Ubuntu)
Status: New => In Progress
** Changed in: aiccu (Ubuntu)
Status: In Progress => New
--
init: job s
** Also affects: aiccu (Ubuntu)
Importance: Undecided
Status: New
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubu
After looking into aiccu deeper, I see you have a real problem. You keep
the first pid you get from the first fork/clone. At least aiccu uses
multiple threads on initialization:
l...@artus:~$ sudo strace -o aiccu.log aiccu start
l...@artus:~$ grep clone aiccu.log
clone(child_stack=0, flags=CLONE_
It would be a good workaround in this case though..
I'm not saying that "pidfile" should get used by default, but it's a
nice option to have in case the program's pidfile behavior is sane.
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
Y
On Sat, 2009-10-03 at 15:10 +, Daniel Hahler wrote:
> A good workaround for this might be pidfile handling, where upstart
> would use a given pidfile for monitoring the job.
>
Ugh, god no.
Do you know how many bugs there are with a system of requiring
applications to write the correct pid to
A good workaround for this might be pidfile handling, where upstart
would use a given pidfile for monitoring the job.
--
init: job stuck with expect fork/daemon when parent reaps child
https://bugs.launchpad.net/bugs/406397
You received this bug notification because you are a member of Ubuntu
Bug
This also happens when you use "expect fork" or "expect daemon" combined
with "script", Upstart ends up following the first spawned child whose
exit status is reaped by the shell. For example:
script
ARGS=$(cat /etc/default/myservice)
exec /sbin/myservice $ARGS
end script
Upstart
59 matches
Mail list logo
