On Sat, 23 Oct 2021 20:52:59 +0200 (CEST)
"Carlos E. R."
Hi,
This afternoon I told this desktop machine to hibernate. My script to hibernate is this:
date --rfc-3339=seconds echo Syncing sync date --rfc-3339=seconds echo "synced. Now screensaver" xscreensaver-command -lock sleep 3 #sudo chvt 10 #sleep 1 sudo /usr/local/sbin/beep sleep 1
#systemctl hibernate sudo /usr/bin/systemctl hibernate sleep 3 sudo /usr/local/sbin/beep #date --rfc-3339=seconds echo
Well, at 19 hours it was still going at it:
Telcontar:~ # hibernate 2021-10-23 15:23:17+02:00 Syncing
It had been attempting to sync the filesystem for 4 hours, unsuccessfully.
I do a separate sync previous to hibernating, because otherwise the hibernate stalls for long time not giving a hint of what is going on.
What is going on? Well, the problem seems to be syncing the metadata of partition sdc9 (reiserfs, rotating rust), which holds /var/spool/news/. It can be a few millions of small files. Not really a news server, just the leafnode proxy. I know it takes very long after it runs /etc/cron.daily/leafnode, which calls "/usr/sbin/texpire":
logger -p cron.warning -t texpire "CER: running leafnode's texpire without ionice" test -x /usr/sbin/texpire && su - news -c "/usr/sbin/texpire" logger -p cron.warning -t texpire "CER: finished texpire" sync -f /var/spool/news/ logger -p cron.warning -t texpire "CER: and synced -f"
That sync can take half an hour normally, but that was not the time it runs:
<9.4> 2021-10-22T23:45:01.361524+02:00 Telcontar texpire - - - CER: running leafnode's texpire without ionice ... <9.4> 2021-10-23T00:35:19.929058+02:00 Telcontar texpire - - - CER: finished texpire <9.4> 2021-10-23T00:37:09.833697+02:00 Telcontar texpire - - - CER: and synced -f
So it should have not interfered.
So what?
Another possibility is that there is a cronjob that every 4 minutes tries to fetch news. So what I have done is disabling that job, and after a while, sync finished.
So now my hibernate script will also need to stop news fetching.
But how is it possible that sync is unable to cope and sync in time the metadata of a hundred new tiny files at most?
Is it some new problem with reiserfs?
Dunno, but I doubt it. I also have reiserfs partitions and my system syncs without trouble, plus I doubt there have been many changes in reiserfs recently (I stand to be corrected :) I would suggest to try running $ strace synce and see what that shows. Is it hanging somewhere, or in an infinite loop? You might be able to see where.