"Johnny Carson flashes" are frustrating problem analyses
- Inicie sesión ou rexístrese para enviar comentarios
Whenever Johny Carson did his raincoat-flashing routine on late night TV, he always turned away from the camera ...
Recently I've been pleading for the following logs:
1. A shutdown log. It's no longer a bunch of benign messages that appear for fractions of a second; they might be helpful, but I can only read a word or two. What are we afraid of seeing during shutdown ? The messages are so brief that I can capture them with a camera only partially, if at all.
2. A log for Software Updater. I've had to resort to making photographs, and I was only successful recently when the same problem appeared in the Software Updater runs on two successive desktop PC's.
Once the filesystem are unmounted, nothing is logged. As for the log of the Software Updater, I guess you actually want the logs of APT. They are in /var/log/apt.
1. Shutdown messages:
Four years ago, Magic Banana replied in http://trisquel.info/en/forum/trisquel-45-messages-shutdown:
> Indeed, taking a look at /var/log/messages (which is timestamped) is a good idea.
> You can read the logs from a graphical utility in the System/Administration menu.
Where might those messages be now ? I can't find a graphical System/Administration menu.
I'd be happy if there could be a pause button interjected after the last of these ephemeral messages ...
For example: "Are you sure ? [*yes] [*no] " Then I could take a picture of the shutdown messages.
After all, why print them on the screen if they're not for human consumption ?
I've invoked XDiagnose from the Trisquel menu, and that prints shutdown messages to the screen slowly enough that I can read and photograph them, but [significantly] it shows the ClamAV daemon shutting down, but not the FreeClam daemon starting, which is what appears in the ephemeral shutdown messages.
It's impossible to start XDiagnose from the System Settings GUI, because "Refusing to render service to dead parents." appears in a popup console instead.
2. Software Updater messages:
The /var/log/apt/history.log and /var/log/apt/term.log files are too sanitized to be of any help.
1. Those messages are as Magic Banana says in the file /var/log/messages , look at them with
sudo less /var/log/messages
in Terminal
2. If you want more detailed messages use either of the commands apt-get or aptitude with the appropriate parameters. Again from Terminal. You might find using the command 'script' first, so you get all the output in a file is helpful.
Lastly if you search on the Internet you will find plenty of pages where people report their machine not powering off after a shutdown command as a bug. These people would not be very happy with your suggestion of a pause and I suggest that is true for most users. If you absolutely need to capture every last message then get yourself a serial port and build a custom version of the Trisquel kernel package to use the serial port as console and record the output on a second computer attached to it. That's why those messages are there, for the other non-x86 architectures that come with such a console.
1. leny2010 and Magic Banana suggested looking in /var/log/messages, but there is no such file in my Trisquel 7 installation; is "dmesg" another word for "messages" ? Anyway, dmesg doesn't capture those shutdown blinkies, either.
2. I tried "sudo script -c "shutdown -h now" /home/george/Documents/folder/typescript.txt" but that output looks like the standard student project box where you push a button "on" and an arm comes out to push the button "off." For example:
> Script started on Fri 13 Nov 2015 12:52:00 PM EST
>
> Script done on Fri 13 Nov 2015 12:52:00 PM EST
That said, in this particular instance, no ephemeral messages appeared during shutdown (I had turned XDiagnose off).
About that serial console ... yeccch; too much experience with writing scripts for too many obsolete languages.
A DDG search on 'Where is /var/log/messages in ubuntu trusty' turns up
https://askubuntu.com/questions/51265/where-is-var-log-messages
as the first entry. Which says it all goes to syslog, always did just there's no longer any /v/l/messages. Obviously, until the disks are umounted as Magic Banana says.
What do you want to see these messages for? If it's diagnostics at such a low level it's after the disks are umounted, then you should run under the Kernel Debugger and presumably you can set a breakpoint with that. But what are you trying to do here?
Trying to have it both ways ?:
Criticism #1. I didn't look it up before complaining ...
Criticism #2. I'm complaining because I can't look it up ...
Nevertheless, here's my wish: Something in the system is trying to tell me what's going on just before shutdown, but the messages that indicate the good & the bad are lost to view because they're visible for only a small fraction of a second. At one stage, I found that the system's bootup manager was starting services for which I have no need and for which I did not ask, and unchecking those services in bootup manager eliminated those messages, leaving only the message relating to ClamAV, which I did intend to have running. Recently, presumably because of glitches in Software Updater (both the GUI version and the version invoked from the Trisquel main menu) and in the startup process, additional and more verbose messages appeared, but all I have been able to gather have been the words, "make sure." XDiagnose presents some shutdown messages, but those messages pick up _after_ the ones in which I am interested and do not include those ephemeral messages.
DDG: 'Where are the ubuntu boot messages
https://askubuntu.com/questions/91286/how-to-see-log-to-find-a-boot-problem
DDG: 'Where are the ubuntu shutdown messages
https://askubuntu.com/questions/58625/where-is-the-shutdown-log
And
man service
e.g.
sudo service --status-all
Should be what you need for your problem rather than what you're asking for.
Following leny2010's lead, hitting the ESC key during shutdown/restart does indeed lift the Plymouth veil from the ephemeral shutdown messages, but they're still displayed unacceptably briefly. If only there was another key to pause that shutdown.
"Something in the system is trying to tell me what's going on just before shutdown"
No, it's not trying to tell you something. It's not alive. :) Rather, it is mindlessly executing it's pre-programmed steps for brining the system down which involves things like SIGTERM to running processes (the polite way to ask a program to terminate), followed later by SIGKILL if they fail to terminate themselves voluntarily, unmounting file systems, etc.
If you're really interested in seeing what happens after the file systems are unmounted and nothing can be logged further, rather than syncing up a still photograph to be taken at exactly the right moment, what about a video that records the entire shut down process? Then you can pause at any point and advance or rewind -- frame by frame if needed -- and sit on one frame for as long as needed.
I am a translator!
you are wrong jxself. **he** is alive.
Following the suggestion to video the action, I managed to capture [what I thought might be] several different sets of shutdown blinkies, to wit:
1. Press to continue K98mdadm/etc/rc0.d/K98mdadm-waitidle.bak: 16 : read: arg count
Could not acquire the 'org.freedesktop.ModemManager1" service name
2. nm-dispatcher.action: could not acquire the org.freedsktop.nm-dispatcher service.
3. [partial - too fuzzy to read the rest] ... could not get the system bus ... make sure the message bus daemon is running ...
While not exactly back-to-back shutdowns, these are not just normal shutdown boilerplate legalese.
In every case, swap deactivation, unmounting and halting or rebooting take place subsequent to these messages.
Google reveals only that others find messages like these when their systems freeze during shutdown and the above messages are on the black screen until the plug is pulled.
I do not see these unless I press when the last Plymouth screen appears. Nothing about ClamAV or FreeClam, either, so this technique may just be telling me what XDiagnose would say if that were running.
Next I tried activating XDiagnose ... and found that the stuff I report above is just what XDiagnose would have told me, and it's just as difficult to capture ... my video camera won't stay focused on the screen.
So the shutdown blinkies remain as elusive as ever.
"So the shutdown blinkies remain as elusive as ever."
I don't know why you say that: From what you've describe this all seems very standard to me. If you recall one of the things that happens during shutdown is all running processes are sent SIGTERM (To quote from the GNU C Library manual: "The SIGTERM signal is a generic signal used to cause program termination. Unlike SIGKILL, this signal can be blocked, handled, and ignored. It is the normal way to politely ask a program to terminate.") Programs will then begin to clean up after themselves and quit. Different programs will take different amounts of time to handle this. While programs are in the process of quitting, some program that's used by another program might quit before all of the other programs that use it have.
And so, you'll get complaints from those still-surviving programs. Examples include your "could not acquire the 'org.freedesktop.ModemManager" and "could not get the system bus ... make sure the message bus daemon is running" stuff. This message bus stuff is probably from some program that uses dbus, which quit before all of the programs using it did. These still-running programs will soon be quitting themselves, but if not that other part of the shutdown process happens: They'll get SIGKILL. (To quote from the GNU C Library manual: "The SIGKILL signal is used to cause immediate program termination. It cannot be handled or ignored, and is therefore always fatal.") In fact, one of the messages that you say you can't see should also be "Sending SIGKILL to remaining processes...". So these programs are GOING to stop one way or the other. :)
After these complaining programs you say you see stuff about swap deactivation, unmounting file systems and whatnot. That's a normal process once the last programs stopped running.
So all of this stuff seems quite normal to me and nothing out of the ordinary.
"my video camera won't stay focused on the screen."
Try turning off automatic focus. Focus it manually first, and then do a shut down once the focus is perfect.
I remember that a fix to some computers not powering off after you tell them to shut down is to add a acpi_osi=X parameter to Linux in grub.
Apparently X can be *leave blank*, Linux, Windows.
Remember to update-grub after you change the config.
Perhaps we could induce this condition.
In a similar vein perhaps worth trying issudo shutdown -H
(Note the H is capitalized!)
Read the links in my last two posts and you will find where the shutdown & boot messages are stored on disk. Nothing meaningful to your diagnosis occurs after the disks are umounted in shutdown.
leny2010 said:
> Read the links in my last two posts and you will find where the shutdown & boot messages are stored on disk.
> Nothing meaningful to your diagnosis occurs after the disks are umounted in shutdown.
OK; I tried [sudo find /var/log -type f -print0 | xargs -0 sudo zgrep "freeclam"] because I know that one of the ephemeral messages states that the freeclam daemon is starting, with the result:
/var/log/udev /var/log/dpkg.log.6.gz /var/log/apport.log.7.gz /var/log/alternatives.log.1
/var/log/lastlog /var/log/syslog.6.gz /var/log/pm-suspend.log.3.gz /var/log/faillog /var/log/alternatives.log.4.gz
/var/log/auth.log.3.gz /var/log/gnustep-back-common.log /var/log/upstart/container-detect.log.4.gz
/var/log/upstart/console-setup.log.5.gz /var/log/upstart/wait-for-state-plymouth-shutdownlightdm.log.2.gz
/var/log/upstart/dbus.log.2.gz /var/log/upstart/ureadahead-other.log.6.gz /var/log/upstart/systemd-logind.log.4.gz
/var/log/upstart/modemmanager.log.1.gz /var/log/upstart/systemd-logind.log.7.gz /var/log/upstart/ureadahead.log.2.gz
/var/log/upstart/rsyslog.log.3.gz /var/log/upstart/procps-virtual-filesystems.log /var/log/upstart/alsa-state.log.2.gz
/var/log/upstart/systemd-logind.log /var/log/upstart/systemd-logind.log.2.gz
That is, nothing was found.
Then I tried [sudo find /var/log -type f -print0 | xargs -0 sudo zgrep "make sure"] because I occasionally saw those words in a more wordy fleeting glimpse, with a bit more success:
/var/log/udev /var/log/dpkg.log.6.gz /var/log/apport.log.7.gz /var/log/alternatives.log.1 /var/log/lastlog /var/log/syslog.6.gz /var/log/pm-suspend.log.3.gz /var/log/faillog /var/log/alternatives.log.4.gz /var/log/auth.log.3.gz /var/log/gnustep-back-common.log /var/log/upstart/container-detect.log.4.gz /var/log/upstart/console-setup.log.5.gz /var/log/upstart/wait-for-state-plymouth-shutdownlightdm.log.2.gz /var/log/upstart/dbus.log.2.gz /var/log/upstart/ureadahead-other.log.6.gz /var/log/upstart/systemd-logind.log.4.gz /var/log/upstart/modemmanager.log.1.gz /var/log/upstart/systemd-logind.log.7.gz /var/log/upstart/ureadahead.log.2.gz /var/log/upstart/rsyslog.log.3.gz /var/log/upstart/procps-virtual-filesystems.log /var/log/upstart/alsa-state.log.2.gz /var/log/upstart/systemd-logind.log /var/log/upstart/systemd-logind.log.2.gz
/var/log/installer/initial-status.gz: Anacron will make sure that the commands are run at the specified
/var/log/installer/initial-status.gz: powered on 24 hours a day to make sure the maintenance jobs of other
/var/log/lightdm/x-0.log.old: to make sure that you have the latest version.
/var/log/lightdm/x-0.log: to make sure that you have the latest version.
/var/log/boot.log: * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated [ OK ]
/var/log/boot.log: * Stopping Reload cups, upon starting avahi-daemon to make sure remote queues are populated [ OK ]
/var/log/Xorg.0.log: to make sure that you have the latest version.
/var/log/Xorg.0.log.old: to make sure that you have the latest version.
Which seems to "prove" that the ephemeral messages are not getting logged. However, none of these logs record anything during shutdown: only startup.
However, I know from running XDiagnose that it logs the shutting down of the freeclam daemon, which of necessity occurs after it was started; and I know that XDiagnose logs the unmounting of the file systems _after_ logging the shutting down of the freeclam daemon.
Therefore, it is possible to record the shutdown blinkies, but that is not being done.
- Inicie sesión ou rexístrese para enviar comentarios