[MGNLCE-7] Stop the installation if the open-files limits are set too low Created: 19/Oct/15  Updated: 17/Oct/16  Resolved: 02/Nov/15

Status: Closed
Project: Community Edition
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4.3

Type: Improvement Priority: Major
Reporter: Philipp Bärfuss Assignee: Roman Kovařík
Resolution: Fixed Votes: 1
Labels: pm
Remaining Estimate: 0d
Time Spent: 4h 16m
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLCE-60 Remove "too many open files" startup ... Closed
relates to MGNLEE-465 Remove "too many open files" startup ... Closed
relation
is related to MGNLEE-414 Stop the installation if the open-fil... Closed
is related to DOCU-623 Warn that install of Magnolia can fai... Closed
supersession
supersedes MAGNOLIA-6420 Magnolia hangs upon fresh installatio... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Sprint: Kromeriz 17
Story Points: 5

 Description   

We should verify the open-file limit on linux and especially on OSX. Either in the installation scripts or in a install condition.

The problem is that on OSX the user don't get a clear error message as on most Linux distributions.

See https://wiki.magnolia-cms.com/display/WIKI/Too+Many+Open+Files

User should be still able to use --ignore-open-files-limit flag to skip the check.



 Comments   
Comment by Federico Grilli [ 22/Oct/15 ]

According to zdenekskodik's comment here https://wiki.magnolia-cms.com/display/WIKI/Too+Many+Open+Files

Running into this on installation can screw up instance (there won't be corrupted nodes on the repository, but there can be nodes missing completely) so it's better to reinstall afterwards.

The comment is from 2010 and I don't know if that is still the case. If it is, I'd abort installation before it can even start when limit is too low and instruct user on the install screen about how to solve the issue. Btw, what is the minimal threshold for Magnolia installation to run through smoothly?

Comment by Federico Grilli [ 22/Oct/15 ]

One of the options proposed to mitigate the risk of incurring in this issue is to run the two installations sequentially, first author, then public (see czimmermann's comment on MAGNOLIA-6420). We might enforce this at /ce-packs/magnolia-tomcat-bundle/src/release/tomcat/webapps/ROOT.index.html by initially disabling the Public instance install links and then enabling them once author is ready. To accomplish this we might use a little javascript like the following using jQuery and ajax polling

<script type="text/javascript">
    function checkAuthorInstallStatus(){
    $.ajax('/magnoliaAuthor/.magnolia/install/status', {
    statusCode: {
        401: function() {
            console.log('enable public install'); // author install is done
        },
        200: function() {
            //console.log(200);  install ongoing...
            setTimeout(checkAuthorInstallStatus, 3000);
        }
    }});}
    
    checkAuthorInstallStatus();
</script>   
Comment by Tom Wespi [ 26/Oct/15 ]

I use since 1 year the H2 Database, which creates 1 file / workspace for the nodes. Since then i've had no problems with to many open files.

Maybe the CE should delivered by default with H2 instead of Derby.

http://www.h2database.com

Comment by Evzen Fochr [ 29/Oct/15 ]

It works on linux but i think that warning is rly easily overlooked because it is scrolled out quite fast.

Comment by Philipp Bärfuss [ 29/Oct/15 ]

The Installation should stop in this case. Because it might fail.

Comment by Philipp Bärfuss [ 02/Nov/15 ]

@Robert: the users we are concerned about are the non technical users (like our sales team), for them the installation should stop and clearly warn them. They will never go and analyse log files. I am not proud of that solution, but stopping the installation is the best option. If you want you can add a parameter like --ignore-open-files-limit which then won't stop

@Federico: I have the same effect on my machine even if I install sequencially

@Tom: yes we evaluate H2 and most likely will use it for the evaluation bundle in the future but we cannot just change that in 5.4.3 all in a sudden. That is the problem.

Comment by Philipp Bärfuss [ 05/Nov/15 ]

We should test for a good default value for our standard bundle with derby. If we know that it works with 4864 and that this is the standard value of newer MacBook Pros then this is a good threshold. We should not warn/stop if we know it works.

But if the value is too low then it should stop and inform the user. My machine has for instance set a value of 256 and hence it fails consequently.

We should just apply common sense to make the user experience as good as possible.

Generated at Mon Feb 12 00:05:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.