ATS 9.1.3 permission problems with run file on openEuler20_aarch64

[Tom-python0121]

hello，I meet a problem:ATS 9.1.3 permission problems with run file on openEuler20_aarch64

Steps to reproduce the issue

[root@localhost bin]#./traffic_manager
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver'
FATAL: Can't open server lockfile '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/server.lock' (Permission denied)
[root@localhost trafficserver-9.1.3]#cat var/log/trafficserver/traffic.out
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver'
FATAL: Can't open server lockfile '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/server.lock' (Permission denied)
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver'
FATAL: Can't open server lockfile '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/server.lock' (Permission denied)

Can you tell me how to solve the problem? Run the sh -x bin/trafficserver start command: test.log

[bneradt]

I assume this means there is a permissions issue with access to one of the directories in that path to the lock file. Can you check that each of your directories in /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/ have the read and execute privilege granted to user nobody and that /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/ itself also has write access so that the lock file can be written?

[Tom-python0121]

@bneradt Although I have assigned permissions to /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver, the error is reported in openEuler_aarch64.

[root@localhost bin]# chmod 777 /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/
[root@localhost bin]#
[root@localhost bin]#
[root@localhost bin]# ./traffic_manager
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver'
FATAL: Can't open server lockfile '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/server.lock' (Permission denied)

But in centos8_aarch64, it can be passed.

[root@bigdata bin]# ./traffic_manager
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-centos8-aarch64/gcc-8.5.0/trafficserver'
Traffic Server 9.1.2 Dec 14 2022 16:41:04 bigdata
traffic_server: using root directory '/home/spack/opt/spack/linux-centos8-aarch64/gcc-8.5.0/trafficserver'

Do you have any good ideas?

[bneradt]

@bneradt Although I have assigned permissions to /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver, the error is reported in openEuler_aarch64.

[root@localhost bin]# chmod 777 /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/
[root@localhost bin]#
[root@localhost bin]#
[root@localhost bin]# ./traffic_manager
[E. Mgmt] log ==> [TrafficManager] using root directory '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver'
FATAL: Can't open server lockfile '/home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/server.lock' (Permission denied)

With the message "Permission denied" I still suspect some DAC issue for your path with the Traffic Manager process. Can you verify that each of the directories in the /home/spack/opt/spack/linux-openeuler20-aarch64/gcc-7.3.0/trafficserver/var/trafficserver/ path are readable/executable by the Traffic Manager process? Note that traffic_manager will run as the proxy.config.admin.user_id user (which defaults to user nobody). Using strace might be helpful to determine the specific cause of the EPERM.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.