AEM 6.0 quickstart with systemd service definition? | Community
Skip to main content
S
steven_walters2
October 16, 2015
Solved

AEM 6.0 quickstart with systemd service definition?

  • October 16, 2015
  • 6 replies
  • 1514 views

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?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

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

6 replies

smacdonald2008
smacdonald2008
Level 10
October 16, 2015

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. 

S
steven_walters2Author
October 16, 2015

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.

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

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

S
steven_walters2Author
October 16, 2015

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.

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

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

S
steven_walters2Author
October 16, 2015

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?

Terms & ConditionsAccessibility statement

Loading footer...