Is there a shut down log, and where can I find it ?
- Login o registrati per inviare commenti
Often, when I shut down or restart Trisquel 7 in my Lenovo T420, a message very briefly appears (more properly, blinks) on my screen as white text on a black background just before the screen goes blank. It's impossible to read it or to photograph it.
Where might I find that message in the system logs, and what name would I expect to be used to describe such a log ?
I have installed ksystemlog.
Are you on the default Trisquel desktop environment?
It very well could be the shutdown dialog. This has happened to me before, as well- when you hold the power button for a second or so, the DE wants to show the shutdown dialog, but Trisquel just shuts down.
> It very well could be the shutdown dialog
I doubt it. He seems to be describing a message occuring after X has already
been killed- like the shutdown message in text mode. Why this happens is beyond
me- Plymouth should kick in for the shutdown procedure (at least if he's using
Trisquel or Triskel). For me, the DE terminates, the screen goes black for a
second, then the Plymouth wallpaper appears for a few seconds, and then the
computer switches off. Strange.
Oh, *after* X is killed. I read what he said wrong- my bad.
Anyway, I think that the white message on a black background you see is
actually a brief glimpse into text mode- the desktop environment has already
shut down, and the system is closing everything. The dialogue reads something
like this: "The system is going for shutdown NOW" and a bunch of things being
killed, or something to that effect.
> I have installed ksystemlog
Are you using KDE? That might have something to do with it. Or are you running
the standard Trisquel DE? About your normal shutdown procedure- does Plymouth
appear briefly on shutdown as well as boot? What do you normally see when you
shut down?
More data ...
What alarmed me about the very brief text is that I thought I picked up something about an apache server ... which I am not knowingly using.
The extra text doesn't always appear ... and the brevity varies.
Look in /var/log. Things like syslog and kern.log and dmesg and etc.
Try pressing the Home key while it is shutting down.
Maybe this is what I've been glimpsing:
cat /var/log/apache2/error.log.1 |more gives
... snippage of many lines ... to reach the last few groups of data (line feeds added between groups for clarity):
[Sat Sep 12 10:50:42.495415 2015] [core:notice] [pid 2556:tid 140426192762752] AH00094: Command line: '/usr/sbin/apache2'
[Sat Sep 12 11:28:09.144176 2015] [mpm_event:notice] [pid 2556:tid 140426192762752] AH00491: caught SIGTERM, shutting down
[Sat Sep 12 17:47:35.637827 2015] [mpm_event:notice] [pid 2184:tid 140615815001984] AH00489: Apache/2.4.7 (Trisquel_GNU/Linux) configured -- resuming normal operations
[Sat Sep 12 17:47:35.648909 2015] [core:notice] [pid 2184:tid 140615815001984] AH00094: Command line: '/usr/sbin/apache2'
[Sat Sep 12 18:04:44.925573 2015] [mpm_event:notice] [pid 2184:tid 140615815001984] AH00491: caught SIGTERM, shutting down
[Sun Sep 13 07:25:47.380276 2015] [mpm_event:notice] [pid 2167:tid 140170334656384] AH00489: Apache/2.4.7 (Trisquel_GNU/Linux) configured -- resuming normal operations
[Sun Sep 13 07:25:47.388692 2015] [core:notice] [pid 2167:tid 140170334656384] AH00094: Command line: '/usr/sbin/apache2'
[Sun Sep 13 07:32:40.636163 2015] [mpm_event:notice] [pid 2167:tid 140170334656384] AH00493: SIGUSR1 received. Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Those last two pairs are different from each other. They are also brief, in contrast to the verbose logs found in the many other places to which I've been directed.
Why is apache2 running and should I care ?
It's not a great idea to run servers you don't need. (Eats resources and gives attackers a vector in.) When you mark apache for uninstall, it might suggest you some other package that depends on apache to also be uninstalled.
Here's what I just did:
user@user-ThinkPad-T420:~$ sudo apt-get remove apache2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
apache2
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 473 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 550142 files and directories currently installed.)
Removing apache2 (2.4.7-1ubuntu4.5+7.0trisquel2) ...
* Stopping web server apache2 *
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for ufw (0.34~rc-0ubuntu2) ...
Now let's see whether those mysterious textual glimpses (a.k.a. dire warnings) vanish forever ...
(1) The white text on black background blinks continue; when they occur, it's just before the Plymouth screen.
(2) Even though I've removed apache2, I'm still seeing user www-data activity:
> user@user-ThinkPad-T420:~$ grep "Sep 14" /var/log/auth.log
... snippage ...
> Sep 14 07:29:28 user-ThinkPad-T420 su[2950]: Successful su for www-data by root
> Sep 14 07:29:28 user-ThinkPad-T420 su[2950]: + ??? root:www-data
> Sep 14 07:29:28 user-ThinkPad-T420 su[2950]: pam_unix(su:session): session opened for user www-data by (uid=0)
> Sep 14 07:29:28 user-ThinkPad-T420 systemd-logind[989]: Removed session c1.
> Sep 14 07:29:28 user-ThinkPad-T420 systemd-logind[989]: New session c3 of user www-data.
> Sep 14 07:29:28 user-ThinkPad-T420 su[2950]: pam_unix(su:session): session closed for user www-data
> Sep 14 07:29:34 user-ThinkPad-T420 systemd-logind[989]: Removed session c3.
Which program needs user www-data ? I checked /var/www/dwww and /var/www/html and there's only generic boilerplate there.
The pam_unix sessions were too short to accomplish anything ...
Upon running sudo apt-get update and sudo apt-get upgrade immediately after the post just above, I was greeted with the admonition to run apt-get autoremove to get rid of apache2-data ... which I dutifully did.
Upon restarting (just to see if the blinky screen persists) ... sure enough ... another blinky with a little different unreadable message appeared at the usual place ... and I still cannot find where that is located in the multitude of logs.
However, grep "Sep 14" /var/log/auth.log produced _NO_ instances of activity by www-data after doing the sudo apt-get autoremove apache2-data task. So apt-get was right: apache2-data wasn't needed ... but it was trying anyway. That appears to dispose of user www-data once and for all.
I looked into "man shutdown" and "man halt": There appears to be no possibility of forcing a verbose shutdown log.
If it appears on what looks like a console screen, it must be stored _somewhere_ on the hard drive, because HDD activity continues after the appearance of the Plymouth screen and before the computer shuts itself off.
If you edit /etc/default/grub (e.g., with 'gksu gedit /etc/default/grub'), turn 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"' into 'GRUB_CMDLINE_LINUX_DEFAULT="text"', save and execute 'sudo update-grub', then the boot/shutdown should be textual.
Following Magic Banana's suggestion to the letter, I found that, although there was no blink text before the Plymouth screen appeared during shutdown this time, the next startup was indeed textual (to the Nth degree) but it all scrolled by too fast to be read until things neared the end of the boot process, leaving me in the console, from which I escaped by reversing the update-grub process so that I could start looking for the promised "text" file.
Where might that "text" file be ?
Can I force its location by replacing "text" with "/home/User/Documents/ShudownBlinkies/text.txt"
The word text is not the name of a file but just instruction to not display some fancy schmancy graphical bootup but instead show the classic bootup messages. I guess you could try taking pictures of the screen. There might be some even more sophisticated method...
Not being one to give up easily, I attempted a redirect maneuver:
> GRUB_CMDLINE_LINUX_DEFAULT="text" >> /home/User/Documents/ShutdownBlinkies/text.txt (typo corrected !)
And ... sure enough, there's a file at the appointed place (text.txt) but it's empty ... sigh.
However, there has been progress:
When I exited the console with sudo shutdown -h now, the elusive blinkie text appeared for what seemed an eternity, long enough for me to "read" it, but not long enough for me to memorize it (maybe 1/4 second). It contained a reference to www-data, a user whom I thought I had sent to /dev/null, which is still disturbing me, if not anyone else ...
If only I could redirect that "sudo shutdown -h now" output to a file of its own ...
Why not ? I'll try "sudo shutdown -h now >> /home/User/Documents/ShutdownBlinkies/text.txt"
Here's what ensued:
> sudo shutdown -h now >> /home/User/Documents/ShutdownBlinkies/text.txt
> bash: /home/User/Documents/ShutdownBlinkies/text.txt: Permission denied
Anyone with the syntax that should write this file ?
Here's a start on the solution:
> script --command "sudo shutdown -h now" --append /home/user/Documents/ShutdownBlinkies/text.txt
And the first result is:
> Script started on Tue 15 Sep 2015 08:56:42 AM EDT
> [sudo] password for user:
>
> Script done on Tue 15 Sep 2015 08:56:58 AM EDT
Of course, we'll have to wait & see, as during _this_ shutdown, nothing momentarily appeared as white text on a black background just before the Plymouth screen, and nothing made it into that text file, not even my password.
It's important that the --command option appear before the --append option; the reverse order gets an error message and won't execute. Also, in contrast to "man script", the command must be enclosed in quotes, not carats as in .
Alas, the momentary text is not captured by this "technique" because it appears on a new console screen, not the one from which the shutdown script is entered.
However, by combining MagicBanana's suggestion to get a verbose startup script, I end up in the console (only - no GUI), from which I can enter:
> script -c "sudo shutdown -h now" -a /home/user/Documents/ShutdownBlinkies/text.txt
And then the ephemeral text appeared long enough for me to photograph it:
> * Starting ClamAV virus database updater freshclam
>Starting GNUstep distributed object mapper: gdomap.
> * speech-dispatcher disabled: edit /etc/default/speech-dispatcher
> * Starting tor daemon...
> * Starting MD monitoring service mdadm --monitor
> * Starting web server apache2
> *
> * The apache2 configtest failed.
>Output of config test was:
>env: apache2ct1: No such file or directory
Another line or two relating to the actual shutdown step appeared after I made the photograph.
Other short outputs different than this have appeared during shutdowns from GUI, and so I still need to capture them for debugging purposes.
What's that "next" console screen's identifier so I can redirect the output of its text to a file with the script command ?
Here's what "find /etc/rc* -name '*apache*'" produces:
/etc/rc0.d/K09apache2
/etc/rc1.d/K09apache2
/etc/rc2.d/S91apache2
/etc/rc3.d/S91apache2
/etc/rc4.d/S91apache2
/etc/rc5.d/S91apache2
/etc/rc6.d/K09apache2
An Internet search reveals this link:
http://serverfault.com/questions/250270/apache-starts-automatically-on-ubuntu-needs-to-be-stopped-to-restart-lighttpd
Which suggests cleaning things up a bit:
Accordingly, I ran "sudo update-rc.d apache2 disable" with these perplexing results:
update-rc.d: warning: start runlevel arguments (none) do not match apache2 Default-Start values (2 3 4 5)
update-rc.d: warning: stop runlevel arguments (none) do not match apache2 Default-Stop values (0 1 6)
Disabling system startup links for /etc/init.d/apache2 ...
Removing any system startup links for /etc/init.d/apache2 ...
/etc/rc0.d/K09apache2
/etc/rc1.d/K09apache2
/etc/rc2.d/S91apache2
/etc/rc3.d/S91apache2
/etc/rc4.d/S91apache2
/etc/rc5.d/S91apache2
/etc/rc6.d/K09apache2
Adding system startup for /etc/init.d/apache2 ...
/etc/rc0.d/K09apache2 -> ../init.d/apache2
/etc/rc1.d/K09apache2 -> ../init.d/apache2
/etc/rc6.d/K09apache2 -> ../init.d/apache2
/etc/rc2.d/K09apache2 -> ../init.d/apache2
/etc/rc3.d/K09apache2 -> ../init.d/apache2
/etc/rc4.d/K09apache2 -> ../init.d/apache2
/etc/rc5.d/K09apache2 -> ../init.d/apache2
Now I ran "find /etc/rc* -name '*apache*'" again:
/etc/rc0.d/K09apache2
/etc/rc1.d/K09apache2
/etc/rc2.d/K09apache2
/etc/rc3.d/K09apache2
/etc/rc4.d/K09apache2
/etc/rc5.d/K09apache2
/etc/rc6.d/K09apache2
And trying the "sudo update-rc.d apache2 disable" trick yet again:
update-rc.d: warning: start runlevel arguments (none) do not match apache2 Default-Start values (2 3 4 5)
update-rc.d: warning: stop runlevel arguments (none) do not match apache2 Default-Stop values (0 1 6)
Disabling system startup links for /etc/init.d/apache2 ...
Removing any system startup links for /etc/init.d/apache2 ...
/etc/rc0.d/K09apache2
/etc/rc1.d/K09apache2
/etc/rc2.d/K09apache2
/etc/rc3.d/K09apache2
/etc/rc4.d/K09apache2
/etc/rc5.d/K09apache2
/etc/rc6.d/K09apache2
Adding system startup for /etc/init.d/apache2 ...
/etc/rc0.d/K09apache2 -> ../init.d/apache2
/etc/rc1.d/K09apache2 -> ../init.d/apache2
/etc/rc6.d/K09apache2 -> ../init.d/apache2
/etc/rc2.d/K09apache2 -> ../init.d/apache2
/etc/rc3.d/K09apache2 -> ../init.d/apache2
/etc/rc4.d/K09apache2 -> ../init.d/apache2
/etc/rc5.d/K09apache2 -> ../init.d/apache2
Which brings us full circle with Trisquel still trying to run the unwelcome apache2.
Originally I removed apache2 with "sudo apt-get remove apache2" and "sudo apt-get remove apache2-data" and re-running these two commands shows that they're still "away" as in "thrown away."
Should I run "sudo apt-get purge apache2 apache2-data" ? I have no need for a server and do not want the dubious activity of any surreptitious activation of apache. Which is why I'm still perplexed about those blinky messages that appear now & then on this laptop as well as on three other Trisquel 7 installations of mine. Are they telling me that Trisquel is calling the mother ship like Windows 3.11 used to do ? I still remember hearing my modem up and calling who-knows-whom while Windows 3.11 was sitting there on my desk with no intervention that I knew about twenty-some years ago ...
You can indeed purge any package with "apache2" in its name. I have no Web server and none of those packages are installed on my system. They are not part of the default install either. I guess you either explicitly installed Apache or some package depending on this Web server. That is why, before confirming the removal, you had better check whether this removal does not trigger the removal of applications you actually use.
I do not know why the init script remained after the deletion of the "apache2" package. Executing the following command would stop the init system from trying to start/stop Apache:
$ sudo rm /etc/rc*/*apache2
It is about removing the symbolic links to the apache2 init script (not the init script itself... although it should not be on your system anyway!).
Being leery of executing "sudo rm /etc/rc*/*apache2" with the wildcard rc*, instead I went to each /etc/rc?.d directory in turn (rc0.d through rc6.d) and executed "sudo mv K09apache2 /dev/null" after which "find /etc/rc* -name '*apache*'" produced no output. Then, being curious, I executed "find /*/* -name '*apache*'" which I do not recommend that anyone do unless they have the time to undo the result, which is a near infinite list of files, scripts, "permission denied" and the like. It did reach a conclusion, after which I closed the console. Preparing to come here to report my success in ridding the system of apache, I found that the terminal could not be re-opened. Upon executing a restart I was greeted with the biggest blinky screen of all, detailing every aspect of my transgression. After the restart everything works OK again.
However, the README file in each /etc/rc?.d directory provides a clue to the mechanism by which a shutdown log could be created: "The scripts in this directory are executed once when entering runlevel "?". The scripts are all symbolic links whose targets are located in /etc/init.d/ . Generally it is not necessary to alter the scripts in this directory. Their purpose is to stop all services and to make the system ready for shutdown." I added the wildcard "?" to signify "0" through "6". There is also a directory /etc/rcS.d/ but that is for startup scripts, and it had no reference to apache.
Poking around on the Internet, I found this page:
http://askubuntu.com/questions/416299/execute-command-before-shutdown-reboot
Where it says in part:
> To execute a script at shutdown or reboot:
>
> save your script in /etc/rc6.d
> Make it executable: sudo chmod +x K99_script
>
> Notes:
>
> The script in rc6.d must be with no .sh extension
> The name of your script must begin with K99 to run at the right time.
> The scripts in this directory are executed in alphabetical order.
This advice was in reference to the need to shut down forgotten VM's in an orderly fashion. What I need to do will probably require that the script open a file at the beginning of shutdown for input during the shutdown, meaning that such script should be named with the prefix K01_script.
Now I just need to dream up that script ... with the caveat that saving the input from freshclam to a log file has to be suppressed. I'll start here: http://askubuntu.com/questions/471285/how-to-create-execute-a-script-file
Solved !
With some professional nudging it turns out that the "subliminal" messages that have been appearing during shutdown are mostly the output murmurings of applications that were somehow started by the Boot-Up Manager (bum) and which I wasn't using. I've already mentioned apache2 and related software (which I purged) ... the others are used occasionally but are not needed during boot-up.
Unchecking those applications in Boot-Up Manager doesn't banish them, but it at least discourages them from piping up during shutdown.
For example, I really do want ClamAV and FreshClam to be running, and when I have been moving large files around in Icedove, enough memory is used that the shutdown process is slowed down sufficiently that I can actually read the remaining messages put into that momentary white-text-on-black screen: They are from ClamAv and its daemon, etc. ! ... And they are also mirrored in the ClamAV logs.
In the words of that famous psychiatric patient: after great expenditures of time and money, whenever the surreptitious messages appear during shutdown, they don't bother me any more.
- Login o registrati per inviare commenti