Error while processing SIGTERM signal on shutdown [SOLVED]

TwiNight · 2011-10-24 05:33:32

When I shut down my laptop, it goes as follows....

(This is not exact)

switching to runlevel:0
.
.
.
shutting down dbus................[done]
shutting down acpid...............[done]
.
.
.
sending SIGTERM to all processes...............[Failed]
.
.
.

So I want to know why the processing of SIGTERM is failing - it's not normally recommended to kill the processes, is it?
What should I do?

Last edited by TwiNight (2012-05-17 04:01:42)

TwiNight · 2011-11-02 08:31:20

This is the first time I've noticed so much time has passed since I posted the problem....

thisoldman · 2011-11-02 10:24:54

See anything in /var/log/messages.log?

TwiNight · 2011-11-03 16:54:03

Will see...

silverzhao · 2011-11-04 08:21:01

the same problem, searching for solutions...

TwiNight · 2011-11-04 10:06:28

I saw the messages.log file, but it's a little too confusing for a newbie like myself. Still, I read it and found no apparent reason as to what is causing the problem.

How can I upload file here?

thisoldman · 2011-11-04 11:42:46

@Twinight,

There are usually only 10 to 20 lines in the messages.log from the previous shutdown. The lines are sorted by date and time.

Let's search for the shutdowns from yesterday.

# sudo egrep 'Nov\ +3' /var/log/messages.log | grep -A 20 shutdown

The first command, 'egrep', searches for all lines datestamped 'Nov 3'. The second command, 'grep', takes that output and searches for any lines with the word 'shutdown', and prints that line, with 'shutdown', and then the 20 following lines.

If you shutdown more than once on Nov 3, the code will be separated into blocks, using double hyphens, '--', as the separator between the blocks. The last block is enough to paste as code in a message on the forums, from the last double hyphens to your next command prompt.

TwiNight · 2011-11-05 12:07:39

When I tried that command, I got no output. Upon further searching, I found out that the last entries in the log file are for October 28. There are no entries after that. What can be causing this?

Here is the output of the command for October 28

Oct 28 01:39:32 localhost shutdown[722]: shutting down for system reboot
Oct 28 01:39:32 localhost systemd-initctl[724]: Received environment initctl request. This is not implemented in systemd.
Oct 28 01:39:33 localhost acpid: exiting
Oct 28 01:39:33 localhost crond[727]: /etc/rc.d/functions: line 67: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory
Oct 28 01:39:33 localhost crond[727]: /etc/rc.d/functions: line 67: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory
Oct 28 01:39:33 localhost crond[727]: /etc/rc.d/functions: line 67: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory
Oct 28 01:39:33 localhost crond[727]: /etc/rc.d/functions: line 67: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory
Oct 28 01:39:33 localhost crond[727]: /etc/rc.d/functions: line 67: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory
Oct 28 01:39:33 localhost crond[727]: :: Stopping Cron Daemon    [BUSY]    [DONE]
Oct 28 01:40:00 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset
Oct 28 01:40:00 localhost kernel: [    0.000000] Initializing cgroup subsys cpu
Oct 28 01:40:00 localhost kernel: [    0.000000] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Oct 19 10:27:51 CEST 2011
Oct 28 01:40:00 localhost kernel: [    0.000000] Command line: root=/dev/sda7 ro 
Oct 28 01:40:00 localhost kernel: [    0.000000] BIOS-provided physical RAM map:
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c400 (usable)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 000000000009c400 - 00000000000a0000 (reserved)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 000000009727c000 (usable)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 000000009727c000 - 0000000097282000 (reserved)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 0000000097282000 - 00000000973d8000 (usable)
Oct 28 01:40:00 localhost kernel: [    0.000000]  BIOS-e820: 00000000973d8000 - 000000009740f000 (reserved)

TwiNight · 2011-11-05 12:08:55

And again....

Oct 28 01:40:18 localhost shutdown[906]: shutting down for system halt
Oct 28 01:40:19 localhost init: Switching to runlevel: 0
Oct 28 01:40:25 localhost acpid: exiting
Oct 28 02:17:20 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset
Oct 28 02:17:20 localhost kernel: [    0.000000] Initializing cgroup subsys cpu
Oct 28 02:17:20 localhost kernel: [    0.000000] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Oct 19 10:27:51 CEST 2011
Oct 28 02:17:20 localhost kernel: [    0.000000] Command line: root=/dev/sda7 ro 
Oct 28 02:17:20 localhost kernel: [    0.000000] BIOS-provided physical RAM map:
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c400 (usable)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000000009c400 - 00000000000a0000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 000000009727c000 (usable)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000009727c000 - 0000000097282000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 0000000097282000 - 00000000973d8000 (usable)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 00000000973d8000 - 000000009740f000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000009740f000 - 000000009745d000 (usable)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000009745d000 - 000000009745e000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000009745e000 - 00000000974df000 (ACPI NVS)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 00000000974df000 - 000000009770f000 (reserved)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 000000009770f000 - 0000000097717000 (usable)
Oct 28 02:17:20 localhost kernel: [    0.000000]  BIOS-e820: 0000000097717000 - 000000009771f000 (reserved)

Oct 28 02:20:26 localhost shutdown[1819]: shutting down for system reboot
Oct 28 02:20:29 localhost init: Switching to runlevel: 6
Oct 28 09:20:30 localhost rtkit-daemon[1235]: Demoting known real-time threads.
Oct 28 09:20:30 localhost rtkit-daemon[1235]: Successfully demoted thread 1248 of process 1233 (/usr/bin/pulseaudio).
Oct 28 09:20:30 localhost rtkit-daemon[1235]: Successfully demoted thread 1242 of process 1233 (/usr/bin/pulseaudio).
Oct 28 09:20:30 localhost rtkit-daemon[1235]: Successfully demoted thread 1233 of process 1233 (/usr/bin/pulseaudio).
Oct 28 09:20:30 localhost rtkit-daemon[1235]: Demoted 3 threads.
Oct 28 02:20:30 localhost acpid: exiting

thisoldman · 2011-11-05 16:21:31

We're at a point where I'm not much help. All I can do is offer very general advice.

Are your mirrors and files up-to-date?
Have you checked for any pacnew or pacsave files? Have you merged them?
For your logfile problems, reinstall syslog-ng, logrotate and whatever you are using for cron (cronie)?
Check the pacman log for what you might have updated around October 28th or 29th. Perhaps reinstall those programs?

Leonid.I · 2011-11-05 17:47:42

@TwiNight:
The SIGTERM fails probably because there are some processes on your system which take longer to shutdown. Namely, there is a "kill_all" call to /etc/rc.d/functions from /etc/rc.shutdown.

kill_all() {
  stat_busy "Sending SIGTERM To Processes"
    kill_all_wait 15 40
    if (( $? == 0 )); then
      stat_done
    else
      stat_fail
      status "Sending SIGKILL To Processes" kill_all_wait 9 60
    fi
}

"kill_all_wait 15 40" (kill_all_wait is defined in functions too) means send SIGTERM (15) to processes and do so 40 times, until none is running. If this fails, we send SIGKILL (which you should also see, does it fail too?). I wouldn't worry too much about it, but if you want to investigate, you could add "/bin/bash" after stat_fail to get a shell so you can browse /proc/ dir and see which processes are still running. After you're done just type exit and shutdown should continue. Alternatively, you could increase 40 to 80 or something, but this will increase shutdown time.

Last edited by Leonid.I (2011-11-05 17:49:13)

TwiNight · 2011-11-06 14:07:47

thisoldman wrote:

We're at a point where I'm not much help. All I can do is offer very general advice.
Are your mirrors and files up-to-date?
Have you checked for any pacnew or pacsave files? Have you merged them?
For your logfile problems, reinstall syslog-ng, logrotate and whatever you are using for cron (cronie)?
Check the pacman log for what you might have updated around October 28th or 29th. Perhaps reinstall those programs?

I have removed syslog-ng and installed rsyslog as a replacement. Is it no set up to handle message from cron automatically?

TwiNight · 2011-11-06 14:11:39

Here is an excerpt from rsyslog.conf that might be relavent...

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                -/var/log/messages

TwiNight · 2011-11-06 14:16:08

Okay. Now this is somewhat scary. Almost all the log files have latest entries for October 28 only. No entries after that. Does that mean rsyslog is not handling the logs properly?

TwiNight · 2011-11-06 14:31:17

For the moment being, I have switched to syslog-ng and it's working fine.

nierro · 2012-02-09 09:44:58

is your "sigterm fail" problem fixed? I've that problem too (https://bbs.archlinux.org/viewtopic.php?id=134425)

TwiNight · 2012-02-18 06:09:18

No

dash · 2012-05-12 12:38:46

Same problem here.

TwiNight · 2012-05-17 04:01:19

The problem is solved. I don't know how, but it is. No more failed SIGTERM.

I wonder what happened.

Arch Linux

#1 2011-10-24 05:33:32

Error while processing SIGTERM signal on shutdown [SOLVED]

#2 2011-11-02 08:31:20

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#3 2011-11-02 10:24:54

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#4 2011-11-03 16:54:03

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#5 2011-11-04 08:21:01

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#6 2011-11-04 10:06:28

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#7 2011-11-04 11:42:46

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#8 2011-11-05 12:07:39

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#9 2011-11-05 12:08:55

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#10 2011-11-05 16:21:31

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#11 2011-11-05 17:47:42

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#12 2011-11-06 14:07:47

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#13 2011-11-06 14:11:39

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#14 2011-11-06 14:16:08

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#15 2011-11-06 14:31:17

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#16 2012-02-09 09:44:58

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#17 2012-02-18 06:09:18

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#18 2012-05-12 12:38:46

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

#19 2012-05-17 04:01:19

Re: Error while processing SIGTERM signal on shutdown [SOLVED]

Board footer