Slurm-wlm depends on X11?
Hello group, hopefully a quick one: I am trying to install the suite of standard slurm packages (slurm, munge, slurmdbd, slurm-wlm-basic-plugins) on a compute node. Ubuntu 22.04.05 LTS just upgraded. *However, these packages now bring down x11 (libx11-6 and all of that other garbage in Ubuntu land). * Does slurm actually depend on x11 now? Or do I need to take a look at my apt config and see what's going on over there, instead. Thanks! Jess -- Jesse Hayward Systems Administrator for High Performance Computing Vassar College 845.437.7521 CIS 207
On 6/25/25 11:39 am, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now?
My guess would be that is coming from the sview package, which is an X11 program. Why that would be getting pulled in is what I think you'd want to look for. https://slurm.schedmd.com/sview.html https://launchpad.net/ubuntu/jammy/+package/sview But if I'm reading that right the version in Ubuntu 22.04 is ancient (21.08.5). All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Berkeley, CA, USA
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at my apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files Looking at the SPEC file in the head of the GitHub repo sources, sees this documented: # build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ... and there's a corresponding %bcond_without x11 statement. That would suggest that "the builder" can turn it off when running the configure To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was. FWIW, If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit) but, sadly, they are all requirements for the "main" slurm package, which deployes sview, and not, as one might hope slurm-contribs where you might hope to find them, or even completely off-side in some (currently non-existing) slurm-contribs-gui package.
Thanks, all! Your advice was all helpful on different levels; especially Kevin's. Christopher, your advice was also helpful, we definitely want to stick to a more minimal setup. Rest assured, we *just* upgraded everything to 22.04. This issue was because of a pre-upgrade purge of the slurm suite due to a botched apt autoremove. Probably some sprinkling of human error there on my part, as well. I'm also building an OHPC-Master server which will host PXE for those same nodes, so in either a pinch or upgrade-approval workflow, we can just change the boot order on the nodes to pick up the chrooted image. Jess, please feel free to reach out to me directly via Email or give me a call. I would like to hear a bit more. Cheers all, Jesse On Thu, Jun 26, 2025 at 6:42 AM Kevin Buckley < kevin.buckley.pawsey.org.au@gmail.com> wrote:
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at my apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files
Looking at the SPEC file in the head of the GitHub repo sources, sees this documented:
# build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ...
and there's a corresponding
%bcond_without x11
statement.
That would suggest that "the builder" can turn it off when running the configure
To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was.
FWIW,
If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits
libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit)
but, sadly, they are all requirements for the "main"
slurm
package, which deployes sview, and not, as one might hope
slurm-contribs
where you might hope to find them, or even completely off-side in some (currently non-existing)
slurm-contribs-gui
package.
Hi all, Unfortunately still struggling. I am not installing x11 on my compute nodes. Especially not anything Ubuntu has to offer. See attached screenshot. [image: 966c96eb-79c4-4f12-ba23-bf099bb9b1c6.png] Best, Jesse On Tue, Jul 1, 2025 at 4:55 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Thanks, all!
Your advice was all helpful on different levels; especially Kevin's.
Christopher, your advice was also helpful, we definitely want to stick to a more minimal setup. Rest assured, we *just* upgraded everything to 22.04. This issue was because of a pre-upgrade purge of the slurm suite due to a botched apt autoremove. Probably some sprinkling of human error there on my part, as well. I'm also building an OHPC-Master server which will host PXE for those same nodes, so in either a pinch or upgrade-approval workflow, we can just change the boot order on the nodes to pick up the chrooted image.
Jess, please feel free to reach out to me directly via Email or give me a call. I would like to hear a bit more.
Cheers all, Jesse
On Thu, Jun 26, 2025 at 6:42 AM Kevin Buckley < kevin.buckley.pawsey.org.au@gmail.com> wrote:
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at my apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files
Looking at the SPEC file in the head of the GitHub repo sources, sees this documented:
# build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ...
and there's a corresponding
%bcond_without x11
statement.
That would suggest that "the builder" can turn it off when running the configure
To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was.
FWIW,
If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits
libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit)
but, sadly, they are all requirements for the "main"
slurm
package, which deployes sview, and not, as one might hope
slurm-contribs
where you might hope to find them, or even completely off-side in some (currently non-existing)
slurm-contribs-gui
package.
Update: Definitely an apt problem, not a slurm one, apologies. Still ancient issues from an old gnome-control-center install a prior admin did years ago. Sheesh. Did many apt rebuilds and it never complained. Dpkg rebuild + reboot solved the issue. Held packaged. Glad we're moving to Rocky for our next rig. Thanks all for your help Best, Jesse On Thu, Jul 10, 2025 at 5:04 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Hi all,
Unfortunately still struggling. I am not installing x11 on my compute nodes. Especially not anything Ubuntu has to offer. See attached screenshot.
[image: 966c96eb-79c4-4f12-ba23-bf099bb9b1c6.png] Best, Jesse
On Tue, Jul 1, 2025 at 4:55 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Thanks, all!
Your advice was all helpful on different levels; especially Kevin's.
Christopher, your advice was also helpful, we definitely want to stick to a more minimal setup. Rest assured, we *just* upgraded everything to 22.04. This issue was because of a pre-upgrade purge of the slurm suite due to a botched apt autoremove. Probably some sprinkling of human error there on my part, as well. I'm also building an OHPC-Master server which will host PXE for those same nodes, so in either a pinch or upgrade-approval workflow, we can just change the boot order on the nodes to pick up the chrooted image.
Jess, please feel free to reach out to me directly via Email or give me a call. I would like to hear a bit more.
Cheers all, Jesse
On Thu, Jun 26, 2025 at 6:42 AM Kevin Buckley < kevin.buckley.pawsey.org.au@gmail.com> wrote:
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at
my
apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files
Looking at the SPEC file in the head of the GitHub repo sources, sees this documented:
# build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ...
and there's a corresponding
%bcond_without x11
statement.
That would suggest that "the builder" can turn it off when running the configure
To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was.
FWIW,
If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits
libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit)
but, sadly, they are all requirements for the "main"
slurm
package, which deployes sview, and not, as one might hope
slurm-contribs
where you might hope to find them, or even completely off-side in some (currently non-existing)
slurm-contribs-gui
package.
Sorry, one last time: Now the same issue is occuring with the package slurmd. What is going on here? On Thu, Jul 10, 2025 at 5:09 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Update: Definitely an apt problem, not a slurm one, apologies. Still ancient issues from an old gnome-control-center install a prior admin did years ago. Sheesh. Did many apt rebuilds and it never complained. Dpkg rebuild + reboot solved the issue. Held packaged.
Glad we're moving to Rocky for our next rig.
Thanks all for your help
Best, Jesse
On Thu, Jul 10, 2025 at 5:04 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Hi all,
Unfortunately still struggling. I am not installing x11 on my compute nodes. Especially not anything Ubuntu has to offer. See attached screenshot.
[image: 966c96eb-79c4-4f12-ba23-bf099bb9b1c6.png] Best, Jesse
On Tue, Jul 1, 2025 at 4:55 PM Jesse Hayward <jhayward@vassar.edu> wrote:
Thanks, all!
Your advice was all helpful on different levels; especially Kevin's.
Christopher, your advice was also helpful, we definitely want to stick to a more minimal setup. Rest assured, we *just* upgraded everything to 22.04. This issue was because of a pre-upgrade purge of the slurm suite due to a botched apt autoremove. Probably some sprinkling of human error there on my part, as well. I'm also building an OHPC-Master server which will host PXE for those same nodes, so in either a pinch or upgrade-approval workflow, we can just change the boot order on the nodes to pick up the chrooted image.
Jess, please feel free to reach out to me directly via Email or give me a call. I would like to hear a bit more.
Cheers all, Jesse
On Thu, Jun 26, 2025 at 6:42 AM Kevin Buckley < kevin.buckley.pawsey.org.au@gmail.com> wrote:
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at
my
apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files
Looking at the SPEC file in the head of the GitHub repo sources, sees this documented:
# build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ...
and there's a corresponding
%bcond_without x11
statement.
That would suggest that "the builder" can turn it off when running the configure
To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was.
FWIW,
If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits
libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit)
but, sadly, they are all requirements for the "main"
slurm
package, which deployes sview, and not, as one might hope
slurm-contribs
where you might hope to find them, or even completely off-side in some (currently non-existing)
slurm-contribs-gui
package.
participants (3)
-
Christopher Samuel -
Jesse Hayward -
Kevin Buckley