Bug 1803729

Summary: mapr-zookeepr fails to start (probably related to systemd changes) on recently-updated CentOS/RHEL
Product: Red Hat OpenStack Reporter: Luigi Toscano <ltoscano>
Component: openstack-saharaAssignee: Nobody <nobody>
Status: CLOSED EOL QA Contact: Luigi Toscano <ltoscano>
Severity: high Docs Contact: Andy Stillman <astillma>
Priority: high    
Version: 13.0 (Queens)CC: mimccune, ted.williams
Target Milestone: ---Keywords: Triaged, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-10 17:28:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Luigi Toscano 2020-02-17 10:30:58 UTC
Description of problem:

The mapr-zookeper service, which is initialized during the cluster startup, fails to start with no apparent explanation ("failed because a configured resource limit was exceeded.")

This seems to be related a systemd change/fix which led to: https://github.com/systemd/systemd/issues/8085

In any case, the issue is described by this MapR knowledge base article:

https://mapr.com/support/s/article/MapR-ver-6-x-systemd-incorrect-update

While the title refers to 6.0, the workaround also works on 5.2

The following change should be applied to the zookeeper init script:
(/opt/mapr/)initscripts/zookeeper

--     87     RUN_AS_CMD="su -s $MAPR_SHELL -p $MAPR_USER -c"
++     87     RUN_AS_CMD="runuser -s $MAPR_SHELL -p $MAPR_USER -c"

On a first look, fixing this can't be done by simply patching the executable on the image, because the affected script is extracted when the MapR RPMs are installed, which happens during the deployment.



Version-Release number of selected component (if applicable):
All mapr version when the image is RHEL- it depends on a operating system change.

Comment 1 Luigi Toscano 2020-09-25 17:27:14 UTC
EOL time for 15, but the issue should be visible on 13 too.

Comment 6 Lon Hohberger 2023-07-10 17:28:00 UTC
OSP13 support officially ended on 27 June 2023