Bug 1226649

Summary:	numad does not start after Leap 15.6 upgrade
Product:	[openSUSE] openSUSE Distribution	Reporter:	Georg Pfuetzenreuter <georg.pfuetzenreuter>
Component:	Other	Assignee:	Mel Gorman <mgorman>
Status:	NEW ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	suse-beta
Version:	Leap 15.6
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Georg Pfuetzenreuter 2024-06-20 16:14:52 UTC

Hi,

with 15.5:

```
Jun 07 00:20:40 provo-gate systemd[1]: Started numad - The NUMA daemon that manages application locality..
Jun 07 00:20:40 provo-gate numad[573]: Looks like transparent hugepage scan time in /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs is 10000 ms.
Jun 07 00:20:40 provo-gate numad[573]: Consider increasing the frequency of THP scanning,
Jun 07 00:20:40 provo-gate numad[573]: by echoing a smaller number (e.g. 100) to /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs
Jun 07 00:20:40 provo-gate numad[573]: to more aggressively (re)construct THPs.  For example:
Jun 07 00:20:40 provo-gate numad[573]: # echo 100 > /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs
Jun 20 16:03:30 provo-gate systemd[1]: Stopping numad - The NUMA daemon that manages application locality....
Jun 20 16:03:30 provo-gate systemd[1]: numad.service: Deactivated successfully.
Jun 20 16:03:30 provo-gate systemd[1]: Stopped numad - The NUMA daemon that manages application locality..
```

After the upgrade to 15.6, which installed `numad-0.5.20130522-3.2.1`:

```
Jun 20 16:04:16 provo-gate systemd[1]: Started numad - The NUMA daemon that manages application locality..
Jun 20 16:04:16 provo-gate numad[629]: Are CPUSETs enabled on this system?
Jun 20 16:04:16 provo-gate numad[629]: They are required for /usr/sbin/numad to function.
Jun 20 16:04:16 provo-gate numad[629]: Check manpage CPUSET(7). You might need to do something like:
Jun 20 16:04:16 provo-gate numad[629]:     # mkdir <DIRECTORY_MOUNT_POINT>
Jun 20 16:04:16 provo-gate numad[629]:     # mount cgroup -t cgroup -o cpuset <DIRECTORY_MOUNT_POINT>
Jun 20 16:04:16 provo-gate numad[629]:     where <DIRECTORY_MOUNT_POINT> is something like:
Jun 20 16:04:16 provo-gate numad[629]:       - /sys/fs/cgroup/cpuset
Jun 20 16:04:16 provo-gate numad[629]:       - /cgroup/cpuset
Jun 20 16:04:16 provo-gate numad[629]: and then try again...
Jun 20 16:04:16 provo-gate numad[629]: Or, use '-D <DIRECTORY_MOUNT_POINT>' to specify the correct mount point
Jun 20 16:04:16 provo-gate systemd[1]: numad.service: Main process exited, code=exited, status=1/FAILURE
Jun 20 16:04:16 provo-gate systemd[1]: numad.service: Failed with result 'exit-code'.
```

I can of course follow the instructions, but I'm not sure it's right for it to stop working after the upgrade.

Configuration is the default:

```
$ more /etc/numad.conf
# Config file for numad
#
# Default INTERVAL is 15
# modify below to change it
INTERVAL=15
```