[ClusterLabs] Q: HA_RSCTMP in SLES11 SP4 at first start after reboot
jpokorny at redhat.com
Mon Aug 13 15:18:25 UTC 2018
On 13/08/18 09:27 -0500, Ryan Thomas wrote:
> I've had similar problems in the past. In my case, it was because
> pacemaker was running as user 'hacluster' in group 'haclient', so it didn't
> have permission to access the root owned file. So to fix the problem, I
> changed the ownership of the file that was causing the permissions error.
> e.g `chown hacluster:haclient <file>`
> On Fri, Aug 10, 2018 at 11:52 AM, Ulrich Windl <
> Ulrich.Windl at rz.uni-regensburg.de> wrote:
>> A simple question: One of my RAs uses $HA_RSCTMP in SLES11 SP4, and it
>> reports the following problem:
>> WARNING: Unwritable HA_RSCTMP directory /var/run/resource-agents - using
>> However the directory has the following permissions:
>> drwxr-xr-t 2 root root 4096 Aug 10 18:05 /var/run/resource-agents
>> My code to check this is:
>> if [ ! -w "$HA_RSCTMP" -a "$(id -u)" -ne 0 ]; then
>> ocf_log warn "Unwritable HA_RSCTMP directory $HA_RSCTMP - using /tmp"
Honestly, I am baffled that both of you, Ulrich and Ryan, apparently
encountered situations where the resource agent wasn't launched effectively
with root permissions, something I can only explain with a fact these were
actually "alert" handlers rather than the former, and it must have been
prior to the change that even these get run as root (i.e. prior to 1.1.18).
I must be missing something, but the respective daemons responsible
for execution of either themselves normally run as root, which is
then directly inherited in the agents.
>> Did I overlook something obvious? Could it be that the directory is
>> created after the error message?
That would not explain that at the same time, effective user ID is
non-zero (that's what buffles me), so perhaps no point in discussing
hypotheses about the former condition.
>> I suspect that the error is triggered during a parameter validation
>> after the cluster node had been rebooted...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users