Running greengrass-cli from a greengrass component; what's going on here?

0

Hi All, my greengrass component needs to do additional health checks and decide to restart another component based on output.

However, it does not do anything, even not an error message. What's going wrong here? I thought that gcc_user context is sufficient? When manually ran, it works. sudo /greengrass/v2/bin/greengrass-cli component restart -n com.MyComponent

When ran from within an existing running GG component, no error, but also no effect?? <--- please advise /greengrass/v2/bin/greengrass-cli component restart -n com.MyComponent

enierop
demandé il y a 2 ans861 vues
4 réponses
1

Hi, have you authorized ggc_user to use the greengrass-cli? You need to do that as described here https://docs.aws.amazon.com/greengrass/v2/developerguide/install-gg-cli.html and https://docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-cli-component.html#greengrass-cli-component-configuration i.e. add the ggc_user to a group and set that group as the AuthorizedPosixGroups in component configuration for aws.greengrass.Cli component through a deployment from your AWS account. Let us know if you face any issues with that or still can't get it to work

AWS
répondu il y a 2 ans
0

Hello,

Yes, ggc_user's profile should be enough to run greengrass-cli component restart in another component's lifecycle.

However, please note that greengrass-cli component restart only works on a non-broken component.

When ComponentA errors, greengrass will retry its lifecycle 3 times and transition it to broken state if all retries fail. After ComponentA is in a broken state, running greengrass-cli component restart -n ComponentA cannot restart the component. The only way to resurrect it is via deployment.

AWS
répondu il y a 2 ans
  • The component is not dead, it responds to SIGTERM. Also, manually running component restart works, but from code, using a a shell from ANOTHER componet, the gcc_user context, does not help. It does nothing, no error, just the log fact that it 'ran'.

0

Thank you but this makes no sense to me. When GreenGrass-cli is installed as a component, it defaults to gcc_user to use that user, also the user greengrass is being managed is say 'myadmin'. Manually I can execute greengrass-cli using sudo and that 'myadmin' account. When my software runs it shells using sudo -u myadmin -S etc so it has exactly the same context and security as when manually. ggc_user is already member of ggc_group and the 'myadmin' is member of ggc_group.

So, greengrass_cli is by default not executed by ggc_user?

enierop
répondu il y a 2 ans
  • Correct, ggc_user is intended for running components. If you want to be able to run the greengrass_cli with ggc_user you should authorize it as described above. This exists because greengrass-cli has more capabilities than components such as deployments and starting/restarting/removing components

0

I'm having a similar issue where I'm not able to use the Greengrass cli. Every time I get a:

Caused by: java.io.IOException: Not able to find auth information in directory: /greengrass/v2/cli_ipc_info. Please run CLI as authorized user or group.

I've been looking everywhere but I can't seem to find a feasible answer for this issue. I tried doing the following:

  • Set the GGC_ROOT_PATH environment variable to /greengrass/v2.
  • Add the --ggcRootPath /greengrass/v2 argument to your command as shown in the following example.

As recommended by AWS documentation (https://docs.aws.amazon.com/greengrass/v2/developerguide/gg-cli-reference.html) but I get nowhere.

Any help would be appreciated!

Ed
répondu il y a un an

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions