IZ564: Unhelpful error message with wrong permissions on bootstrap dir

[torsten]

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=564]

        Issue #:      564          Platform:     All         Reporter: torsten (torsten)
       Component:     hedeby          OS:        All
     Subcomponent:    cli          Version:      1.0            CC:    None defined
        Status:       NEW          Priority:     P4
      Resolution:                 Issue type:    DEFECT
                               Target milestone: 1.0u5next
      Assigned to:    adoerr (adoerr)
      QA Contact:     adoerr
          URL:
       * Summary:     Unhelpful error message with wrong permissions on bootstrap dir
   Status whiteboard:
      Attachments:


     Issue 564 blocks:
   Votes for issue 564:     Vote for this issue


   Opened: Thu Aug 21 01:11:00 -0700 2008 
------------------------


   Description:
   When the sdmadmin user has no read access to the bootstrap configuration
   directory or files within that directory, the sdmadm command error messages are
   not very helpful in pointing to the correct cause of the problem. The wrong
   access permissions might be the result of executing the upgrade_prefs.sh script
   with an incorrectly set umask.

   The error messages given are as follows:

   host% ./sdmadm -d -s sdmtb -p system sbc
   Error: Cannot load system sdmtb from SYSTEM preferences : Failed to upgrade
   preferences from version:  to 0.0

   And for all "normal" commands:

   host% ./sdmadm -s sdmtb -p system sr
   Error: Failed to initialize system context for system sdmtb


   Evaluation:
   This is a minor problem (mainly usability issue) which occurs rarely and has an
   easy workaround.


   Suggested Fix:
   The error message has to be more helpful about the root cause of the problem,
   something like "Failed to initialize system context for system sdmtb: Could not
   access file /etc/sdm/bootstrap/sdmtb/prefs.properties".


   Work Around:
   Adjust the access permissions for the bootstrap directory and the contained
   files so that the sdmadmin user has read access.


   Analysis:
   host% ./sdmadm -d -s sdmtb -p system sr
   Error: com.sun.grid.grm.GrmException: Failed to initialize system context for
   system sdmtb
           at com.sun.grid.grm.cli.AbstractCli.createExecEnv(AbstractCli.java:1667)
           at com.sun.grid.grm.cli.AbstractCli.getExecEnv(AbstractCli.java:1617)
           at com.sun.grid.grm.cli.AbstractCli.getExecutionEnv(AbstractCli.java:1578)
           at
   com.sun.grid.grm.cli.cmd.monitoring.ShowResourceStateCliCommand.execute(ShowResourceStateCliCommand.java:94)
           at com.sun.grid.grm.cli.AbstractCli.run(AbstractCli.java:268)
           at com.sun.grid.grm.cli.SdmAdm.main(SdmAdm.java:160)
           at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
           at
   sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
           at
   sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at
   com.sun.grid.grm.util.MainWrapper$SystemRunThread.run(MainWrapper.java:434)

   For both commands (sbc and any 'normal' command like sr) a
   PreferencesUpgradeException is thrown. For the sbc command this Exception is
   directly propagated to the user, for the sr command this exception is masked by
   a new GrmException (in AbstractCli.java.createExecEnv, line 1667).

   The PreferencesUpgradeException is originally thrown in
   PreferencesUtil.upgradePreferences():434, called from
   ExecutionEnvFactory.createInstanceFromPrefs():308 via PreferencesUtil.getVersion.

   However, the real underlying problem is that FilePreferences.loadCache():423
   catches a FileNotFoundException (which in this case is thrown because of a file
   PERMISSION problem) and only logs a message. A BackingStoreException should be
   thrown but is NOT.


   How to test:
   Write a testsuite test that changes the access permissions of the
   /etc/sdm/bootstrap/<system>/prefs.properties file and tries to execute commands
   on the changed system. Check that the resulting error messages are meaningful.

   Extend unit tests (FilePreferencesTest) to make sure the BackingStoreException
   is thrown in case the preferences file is not accessible.


   ETC:
   0.5 PD fix
   0.5 PD JUnit test
   1.0 PD testsuite test
   ----------------------
   2.0 PD
               ------- Additional comments from adoerr Thu Aug 21 01:21:09 -0700 2008 -------
   New target milestone

               ------- Additional comments from torsten Fri Nov 27 00:40:09 -0700 2009 -------
   changed milestone to 1.0u5next