<div dir="ltr">Thank you everyone. I seem to have sorted and it was indeed some system config left. <div>And John yes I agree with you and good to see the strategy of having them installed on a network share is the one I was thinking of following. Will probably keep a centralized apt-cache to make sure all the libs installed with apt-get are the same across the cluster so there are no issues using the manually installed software in the shared folder. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 November 2017 at 14:02, John Hearns <span dir="ltr"><<a href="mailto:hearnsj@gmail.com" target="_blank">hearnsj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Forgive me for saying this. I do have a bit of experience in building HPC systems.</div><div>Distro supplied software packages have improved a lot over the years.</div><div>But they do tend to be out of date compared to the latest versions of (say) Slurm.</div><div>I really would say you should consider downloading and installing from the vendors site.</div><div>The same thing goes for compilers, MPI, and many software packages.</div><div><br></div><div>Yes, the distro supplied debs or RPMs are easy to install and will be tested against that distro.</div><div>But (again) they will eb installed locally on the nodes. So again with compilers, MPI , Python modules....</div><div>you tend to instlal these on a network shared drive so that you have one central install.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 16 November 2017 at 14:47, E V <span dir="ltr"><<a href="mailto:eliventer@gmail.com" target="_blank">eliventer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You may need to install a systemd override file if you have some of<br>
the system config left over, it has the path set to /usr/bin/. Example<br>
for slurmd, slurmctld and slurmdbd are the same just changing the<br>
names:<br>
<br>
cat /etc/systemd/system/slurmd.ser<wbr>vice.d/override.conf<br>
[Service]<br>
ExecStart=<br>
ExecStart=/usr/local/sbin/slur<wbr>md $SLURMD_OPTIONS<br>
<div class="m_-7397286677945988800HOEnZb"><div class="m_-7397286677945988800h5"><br>
On Wed, Nov 15, 2017 at 12:37 PM, Bruno Santos <<a href="mailto:bacmsantos@gmail.com" target="_blank">bacmsantos@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
> I am currently trying to install slurm to serve as a job scheduler for a<br>
> research institute. I have installed Debian stretch and initially installed<br>
> and configured slurm from the repos.<br>
> HoweverI then tried to play with a different server serving as node and<br>
> realized that due to the different versions of debian the controller and the<br>
> daemon where running different versions of slurm and so not working.<br>
> I have since done apt-get remove --purge and tried to install slurm from<br>
> src. But it seems that the old configuration is still stuck somewhere as<br>
> when I try to run:<br>
><br>
> #systemctl enable slurmctld<br>
> Synchronizing state of slurmctld.service with SysV service script with<br>
> /lib/systemd/systemd-sysv-inst<wbr>all.<br>
> Executing: /lib/systemd/systemd-sysv-inst<wbr>all enable slurmctld<br>
> Failed to enable unit: Unit file /etc/systemd/system/slurmctld.<wbr>service is<br>
> masked.<br>
> # whereis slurmctld<br>
> slurmctld: /usr/local/sbin/slurmctld<br>
> # slurmctld<br>
> bash: /usr/sbin/slurmctld: No such file or directory<br>
><br>
> Any idea what could be going wrong?<br>
><br>
> Thank you very much in advance.<br>
> Best,<br>
> Bruno<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>