Tag Archives: linux

SLURM RPMs on COPR

I’ve started building SLURM RPMs using the Fedora COPR service, which allows Fedora developers to produce packages using the Fedora infrastructure. At the moment, the builds only work for EPEL6, EPEL7 and Fedora 22. There was a change in the RPM defaults for Fedora 23 and above that means the builds aren’t working at the moment. I’ve reported the bug upstream and will investigate it further when I have time.

My repository is at:

https://copr.fedorainfracloud.org/coprs/verdurin/slurm/

I’ve always found it a little strange that the upstream includes an embedded .spec file, but doesn’t provide RPMs themselves, so this is an attempt to work around that omission.

They could probably do with a bit of a cleanup (I doubt rpmlint will be very happy), but that will come later.

Advertisements

Unlikely petabyte network values in rrdtool/ganglia

Of late the networking graphs in our Ganglia monitoring have suffered from irritating, improbable spikes (30PB…) that effectively render them meaningless.  At first I tried the removespikes.pl script that I saw mentioned by other people with the same problem.  This didn’t work all that well, either over- or under-shooting what was required.  It also felt like solving the symptoms rather than the cause.  After all, Ganglia is just plotting what it receives from rrdtool.

Eventually I found a suggestion of applying a maximum value in the header of RRD files with rrdtool.  This way, I could rule out these (pretty much) impossible values.  Here’s an example command:

rrdtool tune bytes_in.rrd --maximum sum:9.0000000000e+09

Clearly care is needed that legitimate values aren’t excluded e.g. interfaces running at 10 gigabit or higher speeds.  It’s been working well for the past week and the network graphs are now meaningful again (after manually removing the outlying values).

Fedora 18 NFS and iptables changes

In previous versions of Fedora, if you wanted add some firewall protection to NFS, you could configure static ports for the various daemons in the file /etc/sysconfig/nfs as follows:

RQUOTAD_PORT=49152
STATD_PORT=49153
MOUNTD_PORT=49154
LOCKD_TCPPORT=49155
LOCKD_UDPPORT=49155
STATD_OUTGOING_PORT=49156

Those arguments don’t appear to have the expected effects on Fedora 18. These are the ports in use if those settings are used:

# systemctl restart nfs-lock.service
# systemctl restart nfs-server.service
# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  47768  status
    100024    1   tcp  36896  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049  nfs_acl
    100227    3   tcp   2049  nfs_acl
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl
    100021    1   udp  49155  nlockmgr
    100021    3   udp  49155  nlockmgr
    100021    4   udp  49155  nlockmgr
    100021    1   tcp  49155  nlockmgr
    100021    3   tcp  49155  nlockmgr
    100021    4   tcp  49155  nlockmgr
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100011    1   udp    875  rquotad
    100011    2   udp    875  rquotad
    100011    1   tcp    875  rquotad
    100011    2   tcp    875  rquotad
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd

Note that mountd and status have random ports, not the ones we specified.
The new system is to use arguments to the various daemons instead:

#
# Optinal options passed to rquotad
RPCRQUOTADOPTS="--port 49152"
#
# Optional arguments passed to in-kernel lockd
LOCKDARG=""
# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=49155
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=49155
#
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
RPCNFSDARGS=""
# Number of nfs server processes to be started.
# The default is 8. 
RPCNFSDCOUNT=8
# Set V4 grace period in seconds
#NFSD_V4_GRACE=90
#
# Optional arguments passed to rpc.mountd. See rpc.mountd(8)
RPCMOUNTDOPTS="--port 49154"
#
# Optional arguments passed to rpc.statd. See rpc.statd(8)
STATDARG="--outgoing-port 49153 --port 49156"
#
# Optional arguments passed to rpc.idmapd. See rpc.idmapd(8)
RPCIDMAPDARGS=""
#
# Optional arguments passed to rpc.gssd. See rpc.gssd(8)
RPCGSSDARGS=""
#
# Optional arguments passed to rpc.svcgssd. See rpc.svcgssd(8)
RPCSVCGSSDARGS=""
#
# To enable RDMA support on the server by setting this to
# the port the server should listen on
#RDMA_PORT=20049 
#
# Optional arguments passed to blkmapd. See blkmapd(8)
BLKMAPDARGS=""

and now the list of ports:

# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  49156  status
    100024    1   tcp  49156  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049  nfs_acl
    100227    3   tcp   2049  nfs_acl
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl
    100021    1   udp  49155  nlockmgr
    100021    3   udp  49155  nlockmgr
    100021    4   udp  49155  nlockmgr
    100021    1   tcp  49155  nlockmgr
    100021    3   tcp  49155  nlockmgr
    100021    4   tcp  49155  nlockmgr
    100005    1   udp  49154  mountd
    100005    1   tcp  49154  mountd
    100005    2   udp  49154  mountd
    100005    2   tcp  49154  mountd
    100005    3   udp  49154  mountd
    100005    3   tcp  49154  mountd
    100011    1   udp  49152  rquotad
    100011    2   udp  49152  rquotad
    100011    1   tcp  49152  rquotad
    100011    2   tcp  49152  rquotad

I saw this in a Bugzilla report

Fedora 18 on Dell XPS 13 Developer edition

My new work laptop, as discussed recently, is the second release of the Dell XPS 13 Developer edition, with the 1920×1080 screen, which fixes my main complaint about the first version. It feels smugly virtuous to buy a machine that doesn’t suffer from the Windows Tax and represents an explicit gesture of support for Linux.  However, Ubuntu isn’t my preferred distribution, so after staying with that for a trip to CERN, I’ve removed it and replaced it with Fedora 18.

Now one of the selling points of Project Sputnik is that special efforts have been made to ensure full hardware compatibility.  These days, Linux’s hardware support is generally very good. It’s not quite clear yet whether all the fixes produced by Dell and Canonical have been submitted upstream, so I knew there might be some regressions.  One thing that did work out of the box in Fedora was the “super” key, which might in other circumstances be better known as the “Windows key”. In both Unity and GNOME Shell it brings up the search and launching interface, so it’s quite important.  There is a package installed in the customised version of Ubuntu 12.04 installed on the XPS 13 that specifically disables this key, as detailed elsewhere. There’s no such problem with Fedora.

Installation of Fedora 18 from a USB stick completed very quickly, testament to the 256GB SSD.

While the brightness keys do bring up the on-screen indicator, screen brightness doesn’t seem to change, while on battery power at least. There is a workaround on the Gentoo wiki here:

echo 0 > /sys/class/backlight/intel_backlight/brightness

[Update: 2013-05-22 – there’s a more automated workaround in this Bugzilla entry, which I haven’t tried yet]

There is a 15W power draw, according to Powertop, without any configuration changes, on full brightness. This decreases to 7.5W when brightness reduced and the various power saving options are activated.

[Update: 2013-05-16 – a couple of times now the battery life indicator in GNOME has been wrong, showing 100% and then suddenly jumping to the correct (much lower) figure – it’s not clear yet whether this is a GNOME problem or something specific to this hardware]

Camera works, sound works, including Fn-key adjustment.

Suspending and resuming works – hibernation not tested yet.

Mini-DisplayPort connection to an external monitor via a VGA adapter works.

I’ll probably try running a newer kernel soon, which is supposed to have various fixes for this hardware, and update the post accordingly.

[Update: 2013-05-16 – today I’ve updated it to the latest Fedora 18 kernel, which is 3.9.2, and should have better touchpad handling]