{"action":"created","issue":{"url":"https://api.github.com/repos/flux-framework/flux-core/issues/395","labels_url":"https://api.github.com/repos/flux-framework/flux-core/issues/395/labels{/name}","comments_url":"https://api.github.com/repos/flux-framework/flux-core/issues/395/comments","events_url":"https://api.github.com/repos/flux-framework/flux-core/issues/395/events","html_url":"https://github.com/flux-framework/flux-core/issues/395","id":105443679,"number":395,"title":"Flux instance shutdown ","user":{"login":"surajpkn","id":9956275,"avatar_url":"https://avatars.githubusercontent.com/u/9956275?v=3","gravatar_id":"","url":"https://api.github.com/users/surajpkn","html_url":"https://github.com/surajpkn","followers_url":"https://api.github.com/users/surajpkn/followers","following_url":"https://api.github.com/users/surajpkn/following{/other_user}","gists_url":"https://api.github.com/users/surajpkn/gists{/gist_id}","starred_url":"https://api.github.com/users/surajpkn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/surajpkn/subscriptions","organizations_url":"https://api.github.com/users/surajpkn/orgs","repos_url":"https://api.github.com/users/surajpkn/repos","events_url":"https://api.github.com/users/surajpkn/events{/privacy}","received_events_url":"https://api.github.com/users/surajpkn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2015-09-08T18:31:34Z","updated_at":"2015-09-09T15:49:56Z","closed_at":null,"body":"I want to be able to initiate a shutdown of a flux instance from within the scheduler service running at rank 0. I figured out that there is a shutdown event and a callback for it. Can I send that message from the scheduler and expect a shutdown of all the brokers associated with a flux instance?"},"comment":{"url":"https://api.github.com/repos/flux-framework/flux-core/issues/comments/138953650","html_url":"https://github.com/flux-framework/flux-core/issues/395#issuecomment-138953650","issue_url":"https://api.github.com/repos/flux-framework/flux-core/issues/395","id":138953650,"user":{"login":"grondo","id":741970,"avatar_url":"https://avatars.githubusercontent.com/u/741970?v=3","gravatar_id":"","url":"https://api.github.com/users/grondo","html_url":"https://github.com/grondo","followers_url":"https://api.github.com/users/grondo/followers","following_url":"https://api.github.com/users/grondo/following{/other_user}","gists_url":"https://api.github.com/users/grondo/gists{/gist_id}","starred_url":"https://api.github.com/users/grondo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grondo/subscriptions","organizations_url":"https://api.github.com/users/grondo/orgs","repos_url":"https://api.github.com/users/grondo/repos","events_url":"https://api.github.com/users/grondo/events{/privacy}","received_events_url":"https://api.github.com/users/grondo/received_events","type":"User","site_admin":false},"created_at":"2015-09-09T15:49:56Z","updated_at":"2015-09-09T15:49:56Z","body":"I am still not entirely sure I fully understand this use case. However, it does seem like a special case (child instances started fully under control of the enclosing instance, instead of started on behalf of user request for resources).\r\n\r\nInstead of writing a unique scheduler for this case, use of a purpose built initial program has merits in that you could load any scheduler implementation to schedule the work instead of relying on a scheduler built with direct parent-child communication path. So, while admitting I may be wrong for this case, the initial program approach does seem to be the more generic approach (I don't really understand the reference to \"tricks\" sorry)\r\n\r\nThis kind of initial program will also be required for a parent-less instance running on a cluster for example, to which external jobs are submitted, perhaps from login nodes of a cluster or users' desktops. This program could support a more universal API (e.g. REST over HTTP) and accept other auth methods easily (krb5), and could therefore support an authorized shutdown request.\r\n\r\nSince we'll likely have to build something like this anyway for real-world usage, it would seem that having a second path, only for parent-child scheduler-specific communication might be duplicating effort. Why not use a similar service for this research?\r\n\r\nFor now, if you really want to support shutdown from any entity in a session, you could run an initial program that blocks until a shutdown event is received. This is a kind of bare services initial program (only takes shutdown event), but could be expanded to accept other requests\r\n\r\n```lua\r\n#!/usr/bin/lua\r\nlocal f,err = require 'flux'.new ()\r\n\r\nif not f then error (err) end\r\n\r\nlocal rc, err = f:subscribe ('program.shutdown')\r\nif not rc then error (err) end\r\n\r\nlocal msg, tag = f:recv_event ()\r\nif msg and msg.exit_code then\r\n    os.exit (msg.exit_code)\r\nend\r\nos.exit (0)\r\n```"}}