And Gen X uses log files to record various operational details.
These logs are useful for monitoring normal operations and tracking down issues if a problem occurs.
Let's start by taking a look inside the main configuration file and an ex-cons inside this file.
If we search for log, we can find two entries access, underscore, log, and error underscore log.
The access log is where Engine X records each request that it serves, whether the request is served
successfully or not.
Each request can be recorded along with various metadata, like the date and time of the request, the
IP address of the requester, and the path to the document that was served.
Engine X uses the error log to store operational details ranging from debug information to warnings
and critical errors.
If Engine X is set up to serve multiple sites but the default logging configuration is used, then all
the requests for all the sites will be written to the same logs.
This can become an issue if, for example, you need to find the access logs for one specific site.
Fortunately, logging can be configured in the server and location contexts.
Let's set up logging for our demo site.
First, let's edit our configuration file.
Now we can add access logs in error log specifically for this virtual host with the access log and error
log directives followed by the paths to the file.
And I like to add these close to the top of the configuration.
And just for demonstration purposes, let's also add access and error logs in the images location.
Now let's save this test our configuration and reload it.
Bummer.
It looks like we forgot to add semicolons after some of the statements that we just added.
Let's fix that.
Okay, one more time.
Let's test this configuration.
Looks good.
So now let's reload it.
If we change to the log directory, we can see that our new log files have been created.
But they're empty because no requests have come through.
Instead of loading the page in the browser, we can use a for loop to curl local host ten times while
sending the output to slash dev slash null.
And now if we look inside the access log for our site, we can see ten records that correspond to the
ten curls that we just made.
We can do the same thing for the images location because we're requesting a directory location.
We need to add a trailing slash in this case.
And now if we check the contents of the images access log, we can see the logs for each request.
Seeing the content in the access files for both of these locations lets us know that our custom logging
directives are configured properly.
As you're working with Gen X, there may come a time when things just aren't working the way you think
they should.
Here are a few tools and ideas you can use to troubleshoot and resolve some of the typical problems
you might encounter.
We can catch configuration errors with Engine x TX after making changes.
If there's a typo in your configuration file and Gen X TX will identify the error and the file it occurs
in along with the line number.
In this example, I've misspelled the server keyword online, one of the configuration file.
This is an easy fix.
Also check for typos in your route and server name directives.
In some cases, these typos won't be flagged when you test the configuration.
In this example, TM one should really be HTML and w w w dot example.com should be w w w dot example.com.
Keep an eye out for illusive errors like these.
But what about problems that occur after you know the configuration is good?
Let's say for instance, you've made some changes to your site, but the changes aren't showing up where
you can't reach your site at all.
The first thing you can do is make sure Engine X is running the system.
CTL status Engine X command give output that confirms whether Engine X is running or not.
Then you might also want to reload the configuration with sys CTL reload engine x.
This command doesn't produce any output if it runs successfully.
So check the site afterward to see if your changes are now being applied.
If engine x.
If up and running but you aren't seeing anything served, you'll want to check that the standard ports
for HTTP and HTTPS traffic are open.
Ports 80 and 443.
You can check the status of these ports using the sub and net stat commands.
Less of which is short for list open files, lists, all the files and network ports that are open on
the system using the ice, which we can check to see if Engine X is listening on ports 80 and 443.
Another way to confirm in Gen X is listening on these ports is with the network status or net stat command.
Net stat gives us information on all of the network connections for the system using the right switches
dash plan and grouping for Engine X, we can also get net stack to give us the idea of the process that's
listening to the port.
If your configuration is good and Engine X is up running and listening on the right ports, but something
is still out of place, it's time to turn to the logs.
You can use the tail command with the f switch to follow the engine X logs as they're being written
to the disk while following the log.
You can try to access various parts of your site and see if the accesses are being recorded.
If they are, you can check for 400 errors which might lead to problems like files not being in the
right place or directories that don't have the correct permissions.
If all else fails, seek help.
You can turn to a search engine or http colon slash slash StackOverflow dot com to research the error
or problem that you're seeing.
Hopefully someone else has encountered the same problem and provided a solution.
Finding solutions to your problems might take a while at first, but as you gain more experience with
Engine X, your troubleshooting will become much more efficient.