Re: Getting systemd to not use cpuacct cgroup on RHEL 7.2

[Clinton Roy via luv-main]

On 21 December 2015 at 22:10, Chris Samuel via luv-main  wrote:

>
> Anyone got any ideas on how to stop systemd from using it?
>


I don't know slurm at all, but it appears to have a cgroups.conf file, and
something like:

CgroupMountpoint=/sys
CgroupAutomount=no

Might do what you need?

This doesn't stop systmed from mounting the cgroups, it just tells slurm
where they're
already mounted.

-- 
Clinton Roy
Software Developer
Netboxblue.com
Total Internet Management
Control Internet usage within and outside your organisation.
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main

Re: SPF and DKIM checks on mail to the list

[Chris Samuel via luv-main]

On Tue, 22 Dec 2015 03:50:54 PM Russell Coker via luv-main wrote:

> Don't claim that there's something wrong with the LUV server though. 

I'm not, RFC-2822 "Internet Message Format" is (IMHO):

# [...]   The "From:" field specifies the author(s) of the message,
# that is, the mailbox(es) of the person(s) or system(s) responsible
# for the writing of the message.  The "Sender:" field specifies the
# mailbox of the agent responsible for the actual transmission of the
# message. 

It appears to me that what should go in the Sender: field is instead ending up 
in the From: field and that seems to be in clear breach of the RFC.

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main

Re: Getting systemd to not use cpuacct cgroup on RHEL 7.2

[Chris Samuel via luv-main]

On Tue, 22 Dec 2015 06:59:24 PM Clinton Roy via luv-main wrote:

> Might do what you need?

An interesting idea.

> This doesn't stop systmed from mounting the cgroups, it just tells slurm
> where they're already mounted.

To be honest on an HPC node it's the batch system that should be controlling 
the cgroups rather than systemd.

What would be ideal (if you can sacrifice the cores) would be to tell systemd 
to just use a single core for all its stuff and leave everything else 
available for Slurm to manage.

That way there's no OS jitter from system daemons running on the same cores as 
the applications themselves.

I know, I can dream.. ;-)

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main

Re: SPF and DKIM checks on mail to the list

[Russell Coker via luv-main]

On Tue, 22 Dec 2015 11:20:54 PM Chris Samuel via luv-main wrote:
> On Tue, 22 Dec 2015 03:50:54 PM Russell Coker via luv-main wrote:
> > The list server is configured to reject mail that fails DKIM or SPF
> > checks.  It  is not supposed to receive mail from other list servers or
> > forwarding services so there's no reason for mail to fail such checks.
> > 
> > If you have a problem with mail from your ISP going to the list then
> > contact  me off-list and I'll help you file a bug report.
> > 
> > If you have a problem with your own personal domain then I am happy to
> > send  you log entries related to your issue and help you debug it.
> >
> > Don't claim that there's something wrong with the LUV server though.
> 
> I'm not, RFC-2822 "Internet Message Format" is (IMHO):
> 
> # [...]   The "From:" field specifies the author(s) of the message,
> # that is, the mailbox(es) of the person(s) or system(s) responsible
> # for the writing of the message.  The "Sender:" field specifies the
> # mailbox of the agent responsible for the actual transmission of the
> # message.
> 
> It appears to me that what should go in the Sender: field is instead ending
> up in the From: field and that seems to be in clear breach of the RFC.

Chris, my entire point here is to not mix up the issues of DKIM/SPF checks on 
receipt and the issue of how the From: field is used.

No mail has been rejected due to changes to the From: field.

Some mail has been rejected because it doesn't pass DKIM/SPF checks.  When 
someone's mail is rejected due to DKIM/SPF failures then I'm happy to help 
diagnose that problem.  But it's not related to mailing list changes.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main

Re: Getting systemd to not use cpuacct cgroup on RHEL 7.2

[Chris Samuel via luv-main]

On Mon, 21 Dec 2015 02:52:04 PM Jason White via luv-main wrote:

> While this doesn't directly answer your question, does anything on the
> following page provide a clue?
> https://wiki.archlinux.org/index.php/Slurm

Hmm, don't trust any page that links to the LLNL docs, they're really old & no 
longer apply to current versions, that page needs to be fixed to point to 
http://slurm.schedmd.com/ as that's where the developers are now (and yes, 
it's still GPL).

> This doesn't tell us how they worked around the issue. Do you have the Slurm
> unit file for systemd? This might contain the necessary ingredient, but
> that's just a guess on my part.

Yeah, I've got those (they're in the source distribution) but it is a bit more 
involved than that.  I've just got this email on the slurm-devel list that 
essentially confirms and expands on what Clinton mentioned:

http://permalink.gmane.org/gmane.comp.distributed.slurm.devel/9100

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main

Re: Getting systemd to not use cpuacct cgroup on RHEL 7.2

[Robin Humble via luv-main]

Hi Chris,

On Mon, Dec 21, 2015 at 11:10:47PM +1100, Chris Samuel via luv-main wrote:
>I'm trying to get Slurm working on a RHEL7.2 system and I've hit an issue where
>systemd is already using the cpuacct cgroup hierarchy and that prevents Slurm
>from using it as it seems to be the one case where it can only be in use once.
>
>I.e. having this mount create by systemd:
>
>cgroup /sys/fs/cgroup/cpu,cpuacct cgroup 
>rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
>
>causes:
>
>12725 mount("cgroup", "/cgroup/cpuacct", "cgroup", 
>MS_NOSUID|MS_NODEV|MS_NOEXEC, "cpuacct") = -1 EBUSY (Device or resource busy)

I suspect if slurm mounted the cgroup as cpu,cpuacct then it would
work. but it's because it's trying just cpuacct that it's failing.
that's the sort of behaviour I've seen before.

the OS appears to bind mount them if they're the same.

you have the slurm source - care to hack it and give that a go? :)

torque 6's cgroup code uses cpu,cpuacct which I presume is in order to
play nicely with rhel7.

cheers,
robin
___
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main