3 shell scripts to help you manage AEM Instances

The Problem
Every AEM developer's career starts by double-clicking the AEM jar file. And that’s where you can do your first mistake. AEM might shout at to you “Hey NOOB you need a license!”. You forgot to copy the license file next to the jar… *sigh*. But don’t worry, this happens to everybody. 

After copying the license file, AEM will start and you will get a nice little GUI.

Congratulations! You are ready to go! You know where AEM is running (localhost:4502) and you even have a little stop button in the bottom left corner. But this is probably the only time you see this GUI. All the cool kids start AEM with the start script in crx-quickstart/bin/. But how do you know if AEM is running? How can you find out which port is used and how do you stop the instance?

This blogpost will provide you with three little shell scripts to address these problems and help you to manage your AEM instances without the need for a GUI.

#1 Get information about running AEM instances
To figure out which AEM instances are currently running you might smash something like this into your terminal window:

This method has several disadvantages. The command is hard to remember and the output is very hard to read.

Here’s a little challenge for you: Can you figure out the port, debug port and runmodes in the gif above before it loops? Give it a try.

And anyway, what does this command even mean?

Bonus Tip – Great page to explain shell commands (bookmark it!): https://explainshell.com/explain?cmd=ps+aux+%7C+grep+cq

Back to the topic. Our first script (“aeminfo”) provides a simple overview of all running AEM instances. It turns the complicated output into a readable form:

Nice! All you have to do is adding this script to your .bash_profile. The script does not use any external dependencies and should run many Unix/Linux based systems (tested on OSX and CentOS).

# Displays all running AEM instances

function aeminfo(){

 

    if [ "$(ps aux | grep q | grep crx)" ]

        then

 

            count=0;

            echo ""

            ps auxeww | grep q | grep sling | while read -r line ; do

 

                ((count++));

                params=($line);

 

                username=(${params[0]});

                pid=(${params[1]});

                port="not found";

                debugPort="not found";

                xmx="not found";

                runmodes="not found";

                path="not found";

 

                portRegex="-p ([0-9]+)";

                debugPortRegex="address=([0-9]+)";

                xmxRegex="-Xmx([^[:space:]]+)";

                runmodesRegex="-Dsling.run.modes=([^[:space:]]+)";

                pathRegex="PWD=([^[:space:]]+)";

 

                [[ $line =~ $portRegex ]] && port="${BASH_REMATCH[1]}";

                [[ $line =~ $runmodesRegex ]] && runmodes="${BASH_REMATCH[1]}";

                [[ $line =~ $debugPortRegex ]] && debugPort="${BASH_REMATCH[1]}";

                [[ $line =~ $pathRegex ]] && path="${BASH_REMATCH[1]}";

                [[ $line =~ $xmxRegex ]] && xmx="${BASH_REMATCH[1]}";

 

                echo "----------------------";

                echo "AEM Instance" $count;

                echo "----------------------";

                echo "username:  "$username;

                echo "pid:       "$pid;

                echo "port:      "$port;

                echo "debugPort: "$debugPort;

                echo "memory:    "$xmx;

                echo "runmodes:  "$runmodes;

                echo "path:      "$path;

                echo "----------------------";

                echo "";

 

            done

 

        else

            echo "";

            echo "No running AEM instances found";

            echo "";

        fi

}

#2 Death to all AEM instances!
Our next script (“killaem”) is pretty small. It just shuts down a running AEM instance:

function killaem() {
    kill $(ps aux | grep 'rx-quickstart' | awk '{print $2}')
}

But experienced AEM developers might know that asking AEM politely to stop is sometimes not enough.

Especially when it’s Friday evening and you’re looking forward to a cold beer in your local pub. For this emergency situation, you could use a slight variation of the script (“KILLAEM”) (notice the capitalization!). This will kill your instance definitely. No matter what. The consequences might be that the instance will be in the same condition as you are after too many beers in said pub. Broken and unable to work. So be careful with this command (and with drinking for that matter!)

function KILLAEM() {
    kill -9 $(ps aux | grep 'rx-quickstart' | awk '{print $2}')
}

#3 Improved debugging
So you destroyed your instance and it won’t start properly? What to do next? Have a look at your log files!

If you use the regular “tail -f error.log” command you will quickly notice that AEM logs a lot of stuff. How could you ever find that one useful log entry in the haystack of unnecessary INFO logs? This “aemlog” script might help you! It displays different log levels with different colours:

function aemlog() {

    tail -fn 128 "$@" | awk '

    /SEVERE/ {print "\033[35m" $0 "\033[39m"}

    /ERROR/ {print "\033[31m" $0 "\033[39m"}

    /WARN/ {print "\033[33m" $0 "\033[39m"}

    /DEBUG/ {print "\033[30m" $0 "\033[39m"}

    !/SEVERE|ERROR|WARN|DEBUG/ {print $0 }

';}

You could even observe multiple log files at once. Just pass them as parameters to the command:aemlog error.log access.log audit.log

Conclusion
The three little scripts might not do very much but they are easy to set up, don’t need any third-party software, and provide some useful functionalities.

Just copy all shell scripts from this page into your ~/.bash_profile and you are ready to go!

If you have any suggestions for improvements feel free to leave a comment!

Source: https://www.north-47.com/knowledge-base/3-shell-scripts-to-help-you-manage-aem-instances/