My laptop began shutting down unexpectedly after the next to the last update. It shuts down as soon as I close my laptop, whether on powersupply or battery. Battery is good. I booted to the DVD I installed from, and the laptop does not shutdown after I close the laptop, whether it is connected to the power supply or running on battery. I think this behavior is due to the next to the last update.

LinuxMint 14.1 Nadia Cinnamon 64bit running on Dell Inspiron 1520

Actually it began in the middle of last update. Let me explain. I would run Update, but it would fail with report "Encountered a section with no Package: header" That was due to corrupted MergeList. That problem is solved. Maybe something related to Power is corrupted.

Power settings are as they should be - Suspend when lid is closed.
Battery widget sees battery.
Battery is good.
Temperature does not seem to be an issue.

No idea, but this is where I'd start. (paths are for Ubuntu (debian-based), yours may vary.)

Take a look at your system logs:
/var/log/syslog.1 and /var/log/syslog[2-7].gz
Hopefully, there will be some error messages there about what happened.

If there are, you can Google them and/or post them here.

I started with syslog.1 instead of syslog because, if your computer is still running, then the problem hasn't happened yet so it probably won't be in the current log.

I've stared (with little comprehension) at a lot of logs, so I sort of know what to expect - just by familiarity and pattern recognition, rather than by actually understanding them in much depth, but that's often enough to spot something that looks like it wasn't there before and deserves more attention.

What are the contents of /etc/apm ? This contains rules to action upon certain events. Perhaps a file there has become corrupt or only half-installed.

Also, check /var/log/messages and /var/log/syslog for any relevant error messages.

The problem seems to be really related to closing the lid, right?
Maybe it is best to check whether software that should act on this event was updated.
Perhaps also disable the suspend event when the lid is closed, just to check.
\

Hmm - Was yanked out of orbit yesterday by she who must be obeyed
Reply to josehhj:
error 4 in benchmark.so[7ff09f509000+b000] I found remarks on google related to battery monitor. I am having no problem with battery status being displayed. Also saw reference to video, overclocking, Directx,

<error> [1391397991.962714] [nm-dns-dnsmasq.c:392] update(): dnsmasq owner not found on bus: Could not
get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name

<error> [1391397991.962498] [nm-dns-dnsmasq.c:390] update(): dnsmasq not available on the bus, can't u
pdate servers.

The last 2 errors do not seem to be related to battery or power.

padeen - Also, check /var/log/message

/var/log $ cat pm-suspend.log.1

<error> [1391397991.962498] [nm-dns-dnsmasq.c:390] update(): dnsmasq not available on the bus, can't u
pdate servers.

<error> [1391397991.962714] [nm-dns-dnsmasq.c:392] update(): dnsmasq owner not found on bus: Could not
get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name



hoes
The problem seems to be really related to closing the lid, right?
Maybe it is best to check whether software that should act on this event was updated.

What software would that be?
I ran grep -iw upgrade /var/log/dpkg.log.1 && grep -iw upgrade /var/log/dpkg. Saw no errors. However I do not know what software to look for.


Perhaps also disable the suspend event when the lid is closed, just to check.

I did that. I changed the power settings to do nothing when the lid is closed. The laptop did not shutdown when I closed the lid.

Now, maybe someone will recognize those errors. I don't know anything about them.

On the face of it, those errors have nothing to do with it, and who knows why are they appearing in pm-suspend.log? What are the contents of /etc/apm again?

tom@tom-Inspiron-1520 /etc/apm $ ls
event.d resume.d scripts.d suspend.d

I use Slackware, not Mint. In Slackware, all suspend and sleep events are handled by acpi (/proc/acpi) and the default script in events directory. Your events.d probably serves the same purpose.

On receipt of a "lid" event, the script calls pm-suspend (from the pm-utils package) to perform the actual suspend. Wakeup is handled automatically without any special handlers, presumably by the kernel.

Hopefully this gives you something to go on to fix up your problem.

On Feb 3 2014 the Update Manager listed 2 new updates. I ran them. The laptop no longer shutsdown when I close the lid. I suspect the behavior had something to do with the botched update I mentioned earlier. It brings to mind "what happened or what did you do before something went wrong"

I am closing the lid under as many different scenereos as I can think of to see if it happens again. If the problem does not reoccur after several days, I will consider it gone.

/etc/apm/event.d $ cat 20hdparm
#!/bin/sh

# Copyright (c) 2000-2002 Massachusetts Institute of Technology
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
# 02111-1307, USA.

set -e

# The APMD_DRIVES setting specifies the drives to be changed. Set
# this to an empty string to disable any changes.
#APMD_DRIVES=

# The spindown timeout is set to the value of APMD_SPINDOWN when the
# computer is running on battery power. When the computer is on AC
# power, the spindown timeout is disabled. The number specified here
# is encoded in a complicated way. See the man page for hdparm(8) for
# details. For small timeouts, numbers between 1 and 240 specify
# multiples of 5 seconds. So the default value of 18 means 18*5=90
# seconds, or 1.5 minutes.
APMD_SPINDOWN=18

HDPARM=/sbin/hdparm
[ -x "${HDPARM}" ] || exit 0

[ -n "${APMD_DRIVES}" ] || exit 0

for DRIVE in $APMD_DRIVES; do
[ -b "${DRIVE}" ] || exit 0
done

[ "${APMD_SPINDOWN}" -gt 0 ] || exit 0

power_conserve ()
{
# Set IDE hard disk spindown time to a short time.
for DRIVE in $APMD_DRIVES; do
"${HDPARM}" -q -S "${APMD_SPINDOWN}" "${DRIVE}" || true
done
}

power_performance ()
{
# Disable IDE hard disk spindown.
for DRIVE in $APMD_DRIVES; do
"${HDPARM}" -q -S 0 "${DRIVE}" || true
done
}

choose_power ()
{
if on_ac_power > /dev/null
then
power_performance
else
power_conserve
fi
}

if [ "${1}" = "start" ]; then
choose_power
elif [ "${1}" = "resume" ] && [ "${2}" != "standby" ]; then
choose_power
elif [ "${1},${2}" = "change,power" ]; then
choose_power
elif [ "${1}" = "stop" ]; then
power_performance
fi

exit 0
/etc/apm/event.d $ cat anacron
#! /bin/sh

# This script makes anacron jobs start to run when the machine is
# plugged into AC power, or woken up. For a laptop, these are the
# closest parallels to turning on a desktop.

# The /etc/init.d/anacron script now normally tries to avoid running
# anacron unless on AC power, so as to avoid running down the battery.
# (Things like the slocate updatedb cause a lot of IO.) Rather than
# trying to second-guess which events reflect having or not having
# power, we just try to run anacron every time and let it abort if
# there's no AC. You'll see a message on the cron syslog facility
# (typically /var/log/cron) if it does run.

case "$1,$2" in
change,power|resume,*)
start -q anacron || :
;;
esac
tom@tom-Inspiron-1520 /etc/apm/event.d $