Logging information in Linux
In the zip file you will notice logikallogger.cpp and its header file. This is a class I have written over and over through the years, even before I got into Qt. Any time you are developing for an OS which has a central log system as Linux does you should have a class like this in your application.
Yes, I know many in the C++ world decry the use of a singleton class, but they, like the much maligned goto statement, have a purpose. Even Java did not get rid of the goto statement, they just gave it different names. Even a switch statement is a variation of BASIC’s “ON GOTO” statement. When you enter a switch you goto the case matching the conditional value and when you encounter the break statement you goto the code immediately following the switch.
I will be the first to admit both the singleton class and the goto statement have been viciously abused in production code around the world. When it comes to a singleton class you know you hosed its creation when you feel a need to derive from it. Tsk, tsk, tsk. When it comes to something like application access to a central error logger a singleton class makes perfect sense. No, I’m not going to paste and dissect the code. That is something I do in my books. I will cut and paste the very short main.cpp module. It looks like most every other Qt application main module with the addition of 2 lines for the logger. You really need to set the application name so you can find your messages in syslog.
/*********************************************************************
* Copyright (c) 2016, Logikal Solutions All Rights Reserved.
*
* File: main.cpp
*
* Creation date: 2016
* Author: Roland Hughes
*
* Description: Main module for SerialKeypad example
*********************************************************************/
#include "mainwindow.h"
#include "logikallogger.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
LogikalLogger::Instance().setAppName("SerialKeypad");
w.show();
return a.exec();
}
Before the application runs it is best to open a terminal window and type:
sudo tail -f /var/log/syslog
After it completes hit return a couple of times. Most of the messages appearing after the blank space should come from your run. Connecting the cable to the serial port of my Pi with the device powered on yields a screen like the one below.
Clicking enter after using the mouse to type my name yields this resulting screen.
If you don’t see the same result you most likely also don’t see your mini-tester looking like this with the application open and connected to the Pi.
Your terminal window should also should also show something which looks much like the following:
Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Result of connecting signal mapper 1 Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Testing: ttyS0 manufacturer: description: serial number: baud: 9600 data: 8 parity: 0 stop: 1 Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: port ttyS0 chosen as device Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Testing: ttyS4 manufacturer: description: serial number: baud: 9600 data: 8 parity: 0 stop: 1 Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Attempting to open ttyS0 Jul 26 14:17:47 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Serial Device ttyS0 opened on first attempt Jul 26 14:18:02 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Sending message: ROLAND Jul 26 14:18:02 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: SerialThread writing message: ROLAND Jul 26 14:18:02 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: SerialThread received data: ROLAND Jul 26 14:18:02 roland-HP-Compaq-8100-Elite-SFF-PC LogikalLogger: Received message: ROLAND
Why is it better to use the OS logger than your own log file? Because if something else happened on the system causing your program to misbehave it “should” show up in the system log. Entries are in timestamp sequence. If some device driver or piece of hardware throws an error the driver “should” report it here. I say should because all bets are off if the system disk is throwing errors on its way to that big recycling pile in the sky.
Why does this test work? We haven’t done anything to the Pi other than boot it with Raspbian and connect our serial cable. It shouldn’t work.
Well, it does and this is why I told you not to bludgeon forward. The Pi has a process running called mgetty which expects an ASCII terminal supporting a stripped down VT100 interface. Not a real VT100 interface as defined by OpenVMS but what Linux users call VT100. As such, it echos back characters sent to it until it recognizes something such as a login attempt.
