This does seem to be getting kind of embarassing. With modern journalled
filesystems on relatively straightforward hardware configs an unclean
shutdown shouldn't be the end of the world (after all, power failures
can happen), but it's not nice either.
Unfortunately we also seem to have a hell of
On Wed, Jan 22, 2014 at 09:19:13AM -, Benny wrote:
Lennert of systemd refers to this bug on google+. He outlines a fix for
the simple case:
The fix he outlines is not for this bug. It's not for a bug we have in
upstart in Ubuntu at all; we already reliably ensure telinit u on upgrade of
Excerpts from Steve Langasek's message of 2014-01-22 16:51:06 UTC:
On Wed, Jan 22, 2014 at 09:19:13AM -, Benny wrote:
Lennert of systemd refers to this bug on google+. He outlines a fix for
the simple case:
The fix he outlines is not for this bug. It's not for a bug we have in
On Wed, Jan 22, 2014 at 05:11:03PM -, Clint Byrum wrote:
The other one is the one that would sweep up the mess we occasionally
see when something misbehaves.
I'd like to see Ubuntu's shutdown do more to protect against that
failure mode.
I would, too, but I don't agree that the method he
On 01/22/2014 05:51 PM, Steve Langasek wrote:
On Wed, Jan 22, 2014 at 09:19:13AM -, Benny wrote:
Lennert of systemd refers to this bug on google+. He outlines a fix for
the simple case:
The fix he outlines is not for this bug. It's not for a bug we have in
upstart in Ubuntu at all; we
On Wed, Jan 22, 2014 at 04:13:19PM -, Max wrote:
Steve Dodd:
Last time I did, my own problems were caused by dhclient and ureadahead..
It is not an ureadahead issue, it is an extra fork in upstart to launch
shell for ureadahead if more than one partition mounted.
Yes, I know - I was
Excerpts from Bernd's message of 2014-01-05 21:37:21 UTC:
due the respawn of some processes i think they are (re)started again even on
shutdown
so they are running if the / is remounted readonly
and that is why it fails
i think upstart should insure that all processes are killed (also
Excerpts from Alexander's message of 2013-10-25 05:39:16 UTC:
Guys, come on!
What the heck network-manager and network connections are you talking about?!
This really pissed me off already!
As I've said earlier, the problem is NOT in network-manager!
Excerpts from Steve Dodd's message of 2013-10-21 16:16:29 UTC:
That sounds plausible - I would guess wireless connections are usually torn
down at the end of the user session (i.e. logout) whereas I assume wired
connections persist right to system shutdown??
In theory they're brought down when
On Wed, Oct 23, 2013 at 10:15:46PM -, Gregor Larson wrote:
init 1 root 15w REG 8,24 1134 438383
/var/log/upstart/mountall.log
mountall is a service that's supposed to run once at boot and then exit. If
mountall is still running when you shut the system down, then
That sounds plausible - I would guess wireless connections are usually torn
down at the end of the user session (i.e. logout) whereas I assume wired
connections persist right to system shutdown??
On Oct 21, 2013 3:01 PM, Christian Niemeyer chr.nieme...@gmail.com
wrote:
It occurs that the problem
On Thu, May 16, 2013 at 04:21:12PM -, Max wrote:
'ps uw' only shows processes belonging to the current user.
Unless PID is specified
Oops, true. So the process is definitely not running.
Also, please file a bug report against the ureadahead package
for this package, and post the
Hi Max,
On Tue, May 14, 2013 at 04:17:18PM -, Max wrote:
There is at least one more cause of busy / besides network-manager
in Raring 13.10.
I have noticed file /var/log/upstart/ureadahead-other.log opened
for writing by init when /etc/init.d/umountroot was running.
It seems that the
On Tue, Apr 16, 2013 at 08:38:29PM -, Alexander wrote:
Something really going wrong here.
Today's morning I've found reaaally something new! I'm seeing this for the
first time ever. I've tried to halt the system (not poweroff as usually):
* Unmounting temporary filesystems...
umount:
On Mon, Feb 18, 2013 at 08:32:14AM -, Bernd Schubert wrote:
Well, network usually does not break by killing dhclient,
Irrelevant. The dhclient process is managed by NM, and sendsigs must not
interfere with it.
If we don't want to ignore the lease race and we don't trust NM to kill
On 02/18/2013 10:10 AM, Steve Langasek wrote:
On Mon, Feb 18, 2013 at 08:32:14AM -, Bernd Schubert wrote:
Well, network usually does not break by killing dhclient,
Irrelevant. The dhclient process is managed by NM, and sendsigs must not
interfere with it.
If we don't want to ignore
On Sun, Feb 17, 2013 at 09:04:32PM -, Bernd Schubert wrote:
I have no idea what Mathieu actually intended with this patch, but it is
entirely wrong and made everything worse. Instead of refusing to kill NM,
it needs to be killed, which is just the other way around than what the
patch is
On Tue, Jan 29, 2013 at 01:47:47PM -, Daniel J Blueman wrote:
Here, I see init (expected), dhclient, dnsmasq and plymouthd.
plymouthd is also expected to be running but should not have any files open
for writing. The other two are clearly associated with network-manager, and
seem to
18 matches
Mail list logo
