in our case, we set some environmental variables at startup based on process name and time so we get things like nicely dated garbage log files or do more complex configuration like scanning the file system for possible properties files or log4j configs to include -- so doing exec java inside the script affords us additional flexibility. additionally, since supervisorctl requires a stop;start;remove;reread;add programname when you modify the supervisor program configuration, we tend to put our configuration in the shell script so we only need to do a supevisorctl restart process and it picks up new environment variables and configuration
On Wed, Dec 12, 2012 at 2:30 PM, Timothy Jones <[email protected]>wrote: > The easy approach is to set all the environment variables you need in > the shell that starts supervisor. Supervisor doesn’t need most of these > variables, but inherits them anyway, in the normal manner. Supervisor then > passes all these values down to the child processes. As long as all child > processes need the same set of name=value pairs in their environments, this > works quite well.**** > > ** ** > > ** ** > > tlj**** > > ** ** > > *From:* Jason Koppe [mailto:[email protected]] > *Sent:* Wednesday, December 12, 2012 3:08 PM > *To:* Timothy Jones > *Cc:* Chris May; [email protected] > *Subject:* Re: [Supervisor-users] [BULK] terminating spawned java process* > *** > > ** ** > > we use "exec java" in shell scripts for the same reason. there are other > times when we put the command=java ... directly in the supervisor config, > but for the majority of our jvm instances under supervisor, we use a shell > script to add garbage log rotation and other environmental jvm > configuration nice-to-haves**** > > ** ** > > On Wed, Dec 12, 2012 at 1:35 PM, Timothy Jones < > [email protected]> wrote:**** > > Assuming the java command is the last line of the shell script, I would > try 'exec'. > > Instead of: > java -Dsome.prop com.example.Main arg1 arg2 > do > exec java -Dsome.prop com.example.Main arg1 arg2 > > In this way, the pid running the shell process BECOMES the java process, > instead of fork()ing a java process as a child. > > Explanation: The first half of the restart is 'stop', and that means the > sending of a signal to the supervisor's immediate child process. In your > case, the shell script is the immediate child of supervisor, and terminates > correctly, but the java process is the grand-child and becomes an orphan > (parent pid becomes 1). If you do 'exec java', then there is no > grand-child, and java is the recipient of the shutdown signal, which is > probably what you want. > > Note that java does not exit in response to every signal number (-3 writes > a diagnostic thread listing with stack trace for each thread to stderr, for > example)... but I see you're using SIGKILL (-9), and that won't be a > problem. > > > > tlj > ======================= > From: [email protected] [mailto: > [email protected]] On Behalf Of Chris May > Sent: Wednesday, December 12, 2012 12:33 PM > To: [email protected] > Subject: [BULK] [Supervisor-users] terminating spawned java process**** > > > Hi Everyone, > > In supervisor I'm calling a shell script that spawns a java process, but > when I restart the process from supervisorctl, the original java process > remains and a second is started. > > So far I've tried adding the stopasgroup=true, killasgroup=true, > stopsignal=KILL, but the problem persists. Is there a way to terminate both > the process and the spawned process in supervisor? > > Best, > > Chris > > -- > Christopher May > Chief Financial Officer > Lucky Sort Inc. > 7703 SE 13th Ave. Suite 2 > Portland, Or 97202 > Phone: 503 753 4808 > Fax: 503 206 1896**** > > _______________________________________________ > Supervisor-users mailing list > [email protected] > https://lists.supervisord.org/mailman/listinfo/supervisor-users**** > > > > **** > > ** ** > > -- > Jason Koppe > [email protected] > (210) 445-8242**** > -- Jason Koppe [email protected] (210) 445-8242
_______________________________________________ Supervisor-users mailing list [email protected] https://lists.supervisord.org/mailman/listinfo/supervisor-users
