Am 15.07.2015 um 13:43 schrieb João Jerónimo:
On 15-07-2015 11:21, Reindl Harald wrote:
However, the main question is: why the hell did the openvas installation
get bricked just because one of the processes was killed, and how can I
recover from this without reinstalling the whole guest OS? Isn't it the
job of openvas-check-setup to find this kind of problems?

no it's not the job of "openvas-check-setup" to fix bricked
installations with a completly unknown state after random processes
got killed by the kernel in the middle of operations - no software can
fix that
My understanding is that this "completely unknown state" is stored in de
filesystem in the form of files, so it isn't "completely random" after
all

it is - only god knows which processes where killed at what point in time and what half written data was there in that exactly moment

If openvas stops working and even after a reboot the problem
persists then this must mean that some kind of corruption happened to
openvas-related files as a result of the crash... And isn't it the job
of openvas-check-setup to check openvas-related files, after all?

not in any case

I understand that a simple script can't check and fix everything (some
details must be hidden deep inside thousands of binary files), but in
that case don't tell me that the purpose of openvas-check-setup if not
to find this kind of problems.

it's job is to find *missing configuration* but not random corruption

Normally software can tollerate crashes and don't need a reformat to fix
problems. That's the general rule

try a database server with a full disk...

BTW: you are the only one starts talking about re-format and reinstall the complete OS, everybody else would purge /var/lib/appname, backup it before and restore as much as possible data from that backup like the certs and so on

there is *no general rule* what happens when mutiple processes may write related and connected data to different files and they get *randomly* and *repeatet* killed by the kernel and the state you face is the result of multiple faults on your side:

* complete wrong ressource assignment
* fire up a murderjob without expierience and look at the ressource
  usage of a smaller stop when begin to work with new SW
* don't make a backup before
* in case of a VM don't take a snapshot before


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Openvas-discuss mailing list
[email protected]
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Reply via email to