Hallo Heiner,
multiple levels of answers..
(1st) ... it the directory is not there, the gpfs trace would create it automatically - just like this:
[root@ess5-ems1 ~]# ls -l /tmp/mmfs
ls: cannot access '/tmp/mmfs': No such file or directory
[root@ess5-ems1 ~]# mmtracectl --start -N ems5k.mmfsd.net
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@ess5-ems1 ~]#
[root@ess5-ems1 ~]#
[root@ess5-ems1 ~]# ls -l /tmp/mmfs
total 0
-rw-r--r-- 1 root root 0 Nov 8 10:47 lxtrace.trcerr.ems5k
[root@ess5-ems1 ~]#
ls: cannot access '/tmp/mmfs': No such file or directory
[root@ess5-ems1 ~]# mmtracectl --start -N ems5k.mmfsd.net
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@ess5-ems1 ~]#
[root@ess5-ems1 ~]#
[root@ess5-ems1 ~]# ls -l /tmp/mmfs
total 0
-rw-r--r-- 1 root root 0 Nov 8 10:47 lxtrace.trcerr.ems5k
[root@ess5-ems1 ~]#
(2nd) I think - the cleaning of /tmp is something done by the OS -
please check - systemctl status systemd-tmpfiles-setup.service
or look at this config file
[root@ess5-ems1 ~]# cat /usr/lib/tmpfiles.d/tmp.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp
# Remove top-level private temporary directories on each boot
R! /tmp/systemd-private-*
R! /var/tmp/systemd-private-*
[root@ess5-ems1 ~]#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp
# Remove top-level private temporary directories on each boot
R! /tmp/systemd-private-*
R! /var/tmp/systemd-private-*
[root@ess5-ems1 ~]#
hope this helps -
cheers
Mit freundlichen Grüßen / Kind regards
Olaf Weiser
IBM Systems, SpectrumScale Client Adoption
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
IBM Allee 1
71139 Ehningen
Phone: +49-170-579-44-66
E-Mail: olaf.wei...@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, Norbert Janzen, Markus Koerner, Christian Noll, Nicole Reimer
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940
----- Ursprüngliche Nachricht -----
Von: "Billich Heinrich Rainer (ID SD)" <heinrich.bill...@id.ethz.ch>
Gesendet von: gpfsug-discuss-boun...@spectrumscale.org
An: "gpfsug main discussion list" <gpfsug-discuss@spectrumscale.org>
CC:
Betreff: [EXTERNAL] [gpfsug-discuss] /tmp/mmfs vanishes randomly?
Datum: Mo, 8. Nov 2021 10:35
Hello,
We use /tmp/mmfs as dataStructureDump directory. Since a while I notice that this directory randomly vanishes. Mmhealth does not complain but just notes that it will no longer monitor the directory. Still I doubt that trace collection and similar will create the directory when needed?
Do you know of any spectrum scale internal mechanism that could cause /tmp/mmfs to get deleted? It happens on ESS nodes, with a plain IBM installation, too. It happens just on one or two nodes at a time, it's no cluster-wide cleanup or similar. We run scale 5.0.5 and ESS 6.0.2.2 and 6.0.2.2.
Thank you,
Mmhealth message:
local_fs_path_not_found INFO The configured dataStructureDump path /tmp/mmfs does not exists. Skipping monitoring.
Kind regards,
Heiner
---
=======================
Heinrich Billich
ETH Zürich
Informatikdienste
Tel.: +41 44 632 72 56
heinrich.bill...@id.ethz.ch
========================
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
