** Changed in: upstart (Debian)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to irqbalance in Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect fork/daemon
** 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
Server Team, which is subscribed to irqbalance in Ubuntu.
https://bugs.launchpad.net/bugs/406397
Title:
init: job stuck with expect
** 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
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
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
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
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:
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
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
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
** 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
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.
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
** 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
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
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
** 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
** 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
** 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
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
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
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
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
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
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
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
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
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
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
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
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
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 one
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
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
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
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
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
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 that
** 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.
--
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
** 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
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
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
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
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
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
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
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 on
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
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 this
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,
** 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.
--
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
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
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
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 ends
61 matches
Mail list logo
