Found independently ... I did - 3 of them(!)
Reboot wasn't working - I'd was the first thing I tried (a couple of times).
Oddly, whilst the processes had yum running (sort of), they hadn't locked the repositories as a manual run worked and updated and number of items. It was the fact that it ran manually whilst still reporting busy was what had me head-scratching. Very strange. It was the only one of three server exhibiting the problem.
Got something odd - the 'Software Updates' page is stuck on 'busy' ...?
I've checked from the command line and there are no updates waiting, so why would this happen and what can I do to clear it? - it suggests there's a 'variable' somewhere (lock file?) been left laying around.
's ok; I did that as soon as I read your post.
It's odd as my system was completely locked down until I added greylisting!
I'm hoping that somewhere I've an old backup (using the predecessor of kopano .. can't think what it was called off-hand) that I can look back at .. that was solidly locked down .. as was this build(!) before the disk corruption (it's a VM) that screwed it completely (which is what prompted me to expand the BMB system to create backups over a number of days - I backup the entire VM so I can reinstate with no downtime).
Had a bit of an issue ...
I'm using Kopano. Everything was working fine until I installed the Greylisting addon to postfix to try and restrict the amount of garbage coming though.
All works fine when sending from a machine connected to my local network - except for iPhone/Exchange, which kept generating kopano-spooler errors saying 'Recipient address rejected: Greylisting for ...' etc., and 'No valid recipients' .. which is odd because the recipient in question was actually my gmail account (that I use as a fail-safe measure).
I only see(saw) the problem from the iPhone using an Exchange account - a setup that worked quite happily until I added the Greylisting. Stop Geylisting and it all kicks into life again.
Fixed it by adding 'localhost' to 'postgrey_whitelist_clients.local'.
Hope that won't have any knock on effects ...?
That however, doesn't stack with the concept of grandfather/father/son - that methodology is to delete grandfather and replaces it with father, and father with son. The new archive becomes the new 'son'. What you're describing is incremental backups and relies on the (eg) son being in place for (eg) a week and the incrementals being created on top of that, and then restarted when the changeover (son->father) occurs. I've not bothered with that (too much work!) and just a) left the daily backups being the gf/f/s cycle, with the option of extending that to 7 days.
I can quite see that your option could be implemented for home/flexsaves, but configuration not so much (not worth it). I was just creating something of (basically) minimal change, but with the ability to have some form of protection from the single backup corruption - which is the danger as it stands. The update incidentally, won't affect existing installations as the backup that's in place when the update is put in place just becomes the 'father' when the next backup runs.
Delete the file on the USB disk called 'INITIALIZED'. BMB looks for that file; if it finds it, it classes that disk as being one it can use to save backups. If it's not there, BMB ignores the disk. Note that if BMB finds multiple disks with this file on it, it will save backup to both(all) drives.
Ok, I now have a new version that I've just finished testing to my satisfaction and I'll shortly be submitting it for consideration if anyone is interested
2 New Features:
'Rotation scheme'. I've discovered to my cost that the current version is seriously flawed and I lost some important emails as I experienced a disk corruption that was then backed up(!) and I was unable to recover. It's this that prompted me to do something about it. The file being backed up was a VM; the VM's disk was corrupted as a result for the recent power fluctuations/sudden outage during the recent storms hitting the UK and I didn't discover the problem until the following morning by which time it was too late to do anything about it.
The scheme (in the absence of a .config file) defaults to 3 grandfather/father/son), but selectable up to 7 (dailies). 'Disabled' and '1 backup' are effectively the same as the single backup that is the current (potentially fatal!) scheme.
'Backup now' - something I've wanted for a while.
So who's interested?