Hi Ferran,
When you have a CentOS 7 system with the EPEL repo enabled, and you have
installed the munge RPM from EPEL, then things should be working correctly.
Since systemctl tells you that Munge service didn't start correctly,
then it seems to me that you have a problem in the general configuration
of your CentOS 7 system. You should check /var/log/messages and
"journalctl -xe" for munge errors. It is really hard for other people
to guess what may be wrong in your system.
My 2 cents worth: Maybe you could make a fresh CentOS 7.8 installation
on a test system and install the Munge service (and nothing else)
according to instructions in
https://wiki.fysik.dtu.dk/niflheim/Slurm_installation. This *really*
has got to work!
/Ole
On 29-05-2020 10:23, Ferran Planas Padros wrote:
Hello everyone,
Here it comes everything I've done.
- About Ole's answer:
Yes, we have slurm as the user to control munge. Following your comment,
I have changed the ownership of the munge files and tried to start munge
as munge user. However, it also failed.
Also, I first installed munge from a repository. I've seen your
suggestion of installing from EPEL. So I uninstalled and installed
again. Same result
- About SELinux: It is disables
- The output of ps -ef | grep munge is:
root534051530 10:18 pts/000:00:00 grep --color=auto *munge*
- The outputs of munge -n is:
Failed to access "/var/run/munge/munge.socket.2": No such file or directory
- Same for unmunge
- Output for sudo systemctl status --full munge
*●*munge.service - MUNGE authentication service
Loaded: loaded (/usr/lib/systemd/system/munge.service; enabled; vendor
preset: disabled)
Active: *failed*(Result: exit-code) since Fri 2020-05-29 10:15:52 CEST;
4min 18s ago
Docs: man:munged(8)
Process: 5333 ExecStart=/usr/sbin/munged *(code=exited, status=1/FAILURE)*
May 29 10:15:52 roos21.organ.su.se systemd[1]: Starting MUNGE
authentication service...
May 29 10:15:52 roos21.organ.su.se systemd[1]: *munge.service: control
process exited, code=exited status=1*
May 29 10:15:52 roos21.organ.su.se systemd[1]: *Failed to start MUNGE
authentication service.*
May 29 10:15:52 roos21.organ.su.se systemd[1]: *Unit munge.service
entered failed state.*
May 29 10:15:52 roos21.organ.su.se systemd[1]: *munge.service failed.*
- Regarding NTP, I get this message:
Unable to talk to NTP daemon. Is it running?
It is the same message I get in the nodes that DO work. All nodes are
sync in time and date with the central node
------------------------------------------------------------------------
*From:* slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of
Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk>
*Sent:* Friday, May 29, 2020 9:56:10 AM
*To:* slurm-users@lists.schedmd.com
*Subject:* Re: [slurm-users] Problem with permisions. CentOS 7.8
On 29-05-2020 08:46, Sudeep Narayan Banerjee wrote:
also check:
a) whether NTP has been setup and communicating with master node
b) iptables may be flushed (iptables -L)
c) SeLinux to disabled, to check :
getenforce
vim /etc/sysconfig/selinux
(change SELINUX=enforcing to SELINUX=disabled and save the file and reboot)
There is no reason to disable SELinux for running the Munge service.
It's a pretty bad idea to lower the security just for the sake of
convenience!
/Ole
On Fri, May 29, 2020 at 12:08 PM Sudeep Narayan Banerjee
<snbaner...@iitgn.ac.in <mailto:snbaner...@iitgn.ac.in>> wrote:
I have not checked on the CentOS7.8
a) if /var/run/munge folder does not exist then please double check
whether munge has been installed or not
b) user root or sudo user to do
ps -ef | grep munge
kill -9 <PID> //where PID is the Process ID for munge (if the
process is running at all); else
which munged
/etc/init.d/munge start
please let me know the the output of:
|$ munge -n|
|$ munge -n | unmunge|
|$ sudo systemctl status --full munge
|
Thanks & Regards,
Sudeep Narayan Banerjee
System Analyst | Scientist B
Indian Institute of Technology Gandhinagar
Gujarat, INDIA
On Fri, May 29, 2020 at 11:55 AM Bjørn-Helge Mevik
<b.h.me...@usit.uio.no <mailto:b.h.me...@usit.uio.no>> wrote:
Ferran Planas Padros <ferran.pad...@su.se
<mailto:ferran.pad...@su.se>> writes:
> I run the command as slurm user, and the /var/log/munge
folder does belong to slurm.
For security reasons, I strongly advise that you run munged as a
separate user, which is unprivileged and not used for anything else.
--
Regards,
Bjørn-Helge Mevik, dr. scient,
Department for Research Computing, University of Oslo
