AEM 6.0 quickstart with systemd service definition?

[steven_walters2]

Is there any known issues with deploying the AEM 6.0 quickstart within a systemd service?

I'm finding that with the AEM 6.0 quickstart, the unpacking does not respect the WorkingDirectory of the systemd service definition, always instead unpacking to the same directory where the quickstart jar file exists.

Unpacking outside of systemd works as expected (respects working directory), but for some reason it's not respecting the working directory that systemd sets the process to.

I've verified with pwd that the working directory is what it's set as in the systemd service definition, so this isn't the issue.

It is problematic that the AEM 6.0 quickstart is attempting to unpack in the same directory as the jar file, as the user we're having AEM execute with does not have write permissions to the folder the quickstart jar lies in.

If the quickstart isn't unpacking to quite exactly the working directory (as would usually be expected) what algorithm is used to determine where to unpack to?

[smacdonald2008]

I would recommend against  changing how AEM unpacking works. Consult AEM install docs. If not supported, you can try and contact Adobe consulting for such modifications. 

[steven_walters2]

Outside of your complete misunderstanding of my post as to why you had a rather overly nonconducive tone to your reply, the conducive response would've been

"Have you tried the -b flag in the quickstart command line? According to the documentation it is described as follows:

-b <string>

         Base folder - defines the path under which the quickstart work folder 

         is created   

This way you can control where the quickstart will unpack to deal with the issue you're having with the automatically determined folder being incorrect in your scenario"

I was provided this information by a coworker as I apparently missed it on my initial review of all the command line options.

I have confirmed that this works for my purpose.

[Jörg_Hoh]

Hi Steven,

thanks for posting your findings. I ask myself: Why can't you put the quickstart JAR file in the directory, where you want to have the crx-quickstart directory as well? That's the standard approach, which works quite well for many projects.

kind regards,
Jörg

[steven_walters2]

This is a byproduct of a standardization of system layout where some such systems (particularly development ones) have multiple AEM instances running on them (particularly simultaneous author and publish).

This layout scheme has all the instances on the system utilize/share the same quickstart jar file, avoiding having multiple unnecessary copies of it for each individual instance running on the system.

Regards,
Steven.

[Jörg_Hoh · Accepted solution]

Hi Steven,

ok, understood.

I don't know, if this parameter is well tested in conjunction with AEM upgrades. The default procedure to upgrade your AEM is replacing the quickstart JAR with the new version and then restarting the instance. I assume, that you use the provided start/stop scripts. Then I don't know if at some location within the instance the location of the quickstart JAR is stored, so the "check for changed quickstart JAR" does work for you.

That's the only drawback I could think of. You could test it when you simply deploy AEM 5.6.1 and then try to upgrade it to AEM 6.0. In terms of quickstart functionality AEM 5.6.1 should be on par with 6.0.

kind regards,
Jörg

[steven_walters2]

I don't usually use the provided start/stop scripts, as this adds a dependency upon things which may not always exist (such as first initialization).
I've also found that they frequently need editing for the options I want, so this creates additional undesired manual work on every deployment.

So with this scenario of always starting through the quickstart jar rather than through the app jar (that the start/stop script does), does this change the upgrade concern you have any?