Re: [MooseFS-Users] can't rename metadata.mfs -> metadata.mfs.back: ENOENT (No such file or directory)

[Piotr R. K. <pio...@mo...>]

Oh, I forgot to add:

The error you get is because Master during startup first of all renames found metadata.mfs to metadata.mfs.back,
and if it was started, renamed it, then got killed, but file is renamed and in the second startup it can't find metadata.mfs.

(Of course I still assume that this is connected with the problem I described).


Best regards, 

--

  <https://moosefs.com/>
Piotr Robert Konopelko
MooseFS Technical Support Engineer
e-mail : pio...@mo... <mailto:pio...@mo...>
www : https://moosefs.com <https://moosefs.com/>
   <https://twitter.com/MooseFS>    <https://www.facebook.com/moosefs>    <https://www.linkedin.com/company/moosefs>   <https://github.com/moosefs>

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email.


> On 06 Feb 2016, at 4:27 AM, Piotr Robert Konopelko <pio...@mo...> wrote:
> 
> Hello,
> 
> did Master dump the metadata file on disk properly during stop?
> Do you have enough free space in /var/lib/mfs?
> 
> If you're using CentOS with systemd, and have a lot of metadata, it probably is connected with killing mfsmaster during metadata loading.
> It was fixed in 3.0.69 and in "corresponding" fixed version of 2.x branch - 2.0.83
> 
> MooseFS 3.0.60-1 (2015-11-23)
> (systemd) added TimeoutStartSec=1800 to master
> (https://moosefs.com/documentation/changes-in-moosefs-3-0.html <https://moosefs.com/documentation/changes-in-moosefs-3-0.html>)
> 
> 
> We noticed an issue with this in the middle of November 2015.
> 
>> TimeoutStartSec=
>> Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5) <http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>).
> 
> If you have a lot of metadata, it might take too long to load 
> it from disk and not reporting started status, so the daemon just 
> gets stopped prematurely.
> 
> Please take a look at diff between startup scripts:
> 
> [ok][2016-02-06][04:23:58][oxide94][Ionic][~/Desktop/rpm]
> $ diff -ruN 2.0.81/usr/lib/systemd/system/moosefs-master.service 2.0.83/usr/lib/systemd/system/moosefs-master.service
> --- 2.0.81/usr/lib/systemd/system/moosefs-master.service	2015-10-30 06:49:12.000000000 +0100
> +++ 2.0.83/usr/lib/systemd/system/moosefs-master.service	2016-01-08 11:05:15.000000000 +0100
> @@ -10,6 +10,7 @@
>  ExecReload=/usr/sbin/mfsmaster reload
>  PIDFile=/var/lib/mfs/.mfsmaster.lock
>  TimeoutStopSec=1800
> +TimeoutStartSec=1800
>  Restart=no
> 
>  [Install]
> [err][2016-02-06][04:24:07][oxide94][Ionic][~/Desktop/rpm]
> 
> 
> My advice is (first - make sure you have enough free space in /var/lib/mfs)
> to run mfsmaster -a, which creates a metadata.mfs file from last successfully saved metadata.mfs + changelogs and starts Master Server.
> to upgrade your Master Server to the latest stable version, 2.0.84, which resolves the issue.
> 
> 
> By the way: such behaviour will not occur if you run mfsmaster not via starting script, but just issuing a mfsmaster start command.
> 
> 
> Best regards, 
> 
> --
> 
> <Mail Attachment.png> <https://moosefs.com/>
> 
> Piotr Robert Konopelko
> MooseFS Technical Support Engineer
> e-mail : pio...@mo... <mailto:pio...@mo...>
> www : https://moosefs.com <https://moosefs.com/>
> 
> <Mail Attachment.png>  <https://twitter.com/MooseFS><Mail Attachment.png>  <https://www.facebook.com/moosefs><Mail Attachment.png>  <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email.
> 
> 
>> On 06 Feb 2016, at 1:50 AM, WK <wk...@bn... <mailto:wk...@bn...>> wrote:
>> 
>> got this when I restarted mfsmaster on a 2.0.76 cluster very 
>> stock/default config
>> 
>> 
>> can't rename metadata.mfs -> metadata.mfs.back: ENOENT (No such file or 
>> directory)
>> 
>> The data seems ok, but sure enough there is not a metadata.mfs /var/lib/mfs
>> 
>> Changelogs are there.
>> metadata.mfs.back (.1) is there.
>> 
>> Should I be worried?
>> 
>> -wk
>> 
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 <http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140>
>> _________________________________________
>> moosefs-users mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moosefs-users
>