Background process (postgresql) receiving SIGINT from Ctrl-C in shell

Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
I wrote a shell.nix file to build the development environment for one of my projects. I'm using a shellHook to ensure a postgresql server is started when you drop into the nix-shell.
The shellHook is essentially:
export PGDATA=$PWD/nix/pgdata
pg_ctl start --silent --log $PWD/log/pg.log
Despite the fact that pg_ctl starts a server in the background, if I type Ctrl-C in the shell, the server shuts down. If I set up the same scenario outside of nix-shell, this does not happen.
I'm new to strace, but it looks to me like the postgresql process is receiving SIGINT when I type Ctrl-C in my terminal:
$ strace -p $postgres_pid
strace: Process 20546 attached
select(6, [3 4 5], NULL, NULL, tv_sec=51, tv_usec=289149) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGINT si_signo=SIGINT, si_code=SI_KERNEL ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN RT_1], NULL, 8) = 0
write(2, "LOG: received fast shutdown req"..., 37) = 37
kill(20550, SIGTERM) = 0
...
The postgresql process is attached to the same controlling terminal (pts/12) as my nix-shell process (though this is also true when I run it outside of nix-shell):
$ ps -p $postgres_pid,$nixshell_pid -o pid,ppid,wchan,tty,cmd
PID PPID WCHAN TT CMD
14608 18292 core_s pts/12 bash --rcfile /tmp/nix-shell-14608-0/rc
16355 1 core_s pts/12 /nix/store/xxxxxx-postgresql-9.6.8/bin/postgres
What's a good next step in debugging this? Should I read up on process groups?
Update: Trying a tip from another question, I found that this fixes the problem:
set -m
pg_ctl start --silent --log $PWD/log/pg.log
The weird thing is, according to $-, the m option was already set. Running echo $- produces imBH both before and after the set -m.
I noticed that in my interactive shells (whether nix-shell or not), $- is imBHs. The s is not present in the shellHook context, and I can't find an explanation of its meaning in the docs for Bash's set builtin. This may not be related though...
background-process signals process-management
add a comment |Â
up vote
-1
down vote
favorite
I wrote a shell.nix file to build the development environment for one of my projects. I'm using a shellHook to ensure a postgresql server is started when you drop into the nix-shell.
The shellHook is essentially:
export PGDATA=$PWD/nix/pgdata
pg_ctl start --silent --log $PWD/log/pg.log
Despite the fact that pg_ctl starts a server in the background, if I type Ctrl-C in the shell, the server shuts down. If I set up the same scenario outside of nix-shell, this does not happen.
I'm new to strace, but it looks to me like the postgresql process is receiving SIGINT when I type Ctrl-C in my terminal:
$ strace -p $postgres_pid
strace: Process 20546 attached
select(6, [3 4 5], NULL, NULL, tv_sec=51, tv_usec=289149) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGINT si_signo=SIGINT, si_code=SI_KERNEL ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN RT_1], NULL, 8) = 0
write(2, "LOG: received fast shutdown req"..., 37) = 37
kill(20550, SIGTERM) = 0
...
The postgresql process is attached to the same controlling terminal (pts/12) as my nix-shell process (though this is also true when I run it outside of nix-shell):
$ ps -p $postgres_pid,$nixshell_pid -o pid,ppid,wchan,tty,cmd
PID PPID WCHAN TT CMD
14608 18292 core_s pts/12 bash --rcfile /tmp/nix-shell-14608-0/rc
16355 1 core_s pts/12 /nix/store/xxxxxx-postgresql-9.6.8/bin/postgres
What's a good next step in debugging this? Should I read up on process groups?
Update: Trying a tip from another question, I found that this fixes the problem:
set -m
pg_ctl start --silent --log $PWD/log/pg.log
The weird thing is, according to $-, the m option was already set. Running echo $- produces imBH both before and after the set -m.
I noticed that in my interactive shells (whether nix-shell or not), $- is imBHs. The s is not present in the shellHook context, and I can't find an explanation of its meaning in the docs for Bash's set builtin. This may not be related though...
background-process signals process-management
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
I wrote a shell.nix file to build the development environment for one of my projects. I'm using a shellHook to ensure a postgresql server is started when you drop into the nix-shell.
The shellHook is essentially:
export PGDATA=$PWD/nix/pgdata
pg_ctl start --silent --log $PWD/log/pg.log
Despite the fact that pg_ctl starts a server in the background, if I type Ctrl-C in the shell, the server shuts down. If I set up the same scenario outside of nix-shell, this does not happen.
I'm new to strace, but it looks to me like the postgresql process is receiving SIGINT when I type Ctrl-C in my terminal:
$ strace -p $postgres_pid
strace: Process 20546 attached
select(6, [3 4 5], NULL, NULL, tv_sec=51, tv_usec=289149) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGINT si_signo=SIGINT, si_code=SI_KERNEL ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN RT_1], NULL, 8) = 0
write(2, "LOG: received fast shutdown req"..., 37) = 37
kill(20550, SIGTERM) = 0
...
The postgresql process is attached to the same controlling terminal (pts/12) as my nix-shell process (though this is also true when I run it outside of nix-shell):
$ ps -p $postgres_pid,$nixshell_pid -o pid,ppid,wchan,tty,cmd
PID PPID WCHAN TT CMD
14608 18292 core_s pts/12 bash --rcfile /tmp/nix-shell-14608-0/rc
16355 1 core_s pts/12 /nix/store/xxxxxx-postgresql-9.6.8/bin/postgres
What's a good next step in debugging this? Should I read up on process groups?
Update: Trying a tip from another question, I found that this fixes the problem:
set -m
pg_ctl start --silent --log $PWD/log/pg.log
The weird thing is, according to $-, the m option was already set. Running echo $- produces imBH both before and after the set -m.
I noticed that in my interactive shells (whether nix-shell or not), $- is imBHs. The s is not present in the shellHook context, and I can't find an explanation of its meaning in the docs for Bash's set builtin. This may not be related though...
background-process signals process-management
I wrote a shell.nix file to build the development environment for one of my projects. I'm using a shellHook to ensure a postgresql server is started when you drop into the nix-shell.
The shellHook is essentially:
export PGDATA=$PWD/nix/pgdata
pg_ctl start --silent --log $PWD/log/pg.log
Despite the fact that pg_ctl starts a server in the background, if I type Ctrl-C in the shell, the server shuts down. If I set up the same scenario outside of nix-shell, this does not happen.
I'm new to strace, but it looks to me like the postgresql process is receiving SIGINT when I type Ctrl-C in my terminal:
$ strace -p $postgres_pid
strace: Process 20546 attached
select(6, [3 4 5], NULL, NULL, tv_sec=51, tv_usec=289149) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGINT si_signo=SIGINT, si_code=SI_KERNEL ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN RT_1], NULL, 8) = 0
write(2, "LOG: received fast shutdown req"..., 37) = 37
kill(20550, SIGTERM) = 0
...
The postgresql process is attached to the same controlling terminal (pts/12) as my nix-shell process (though this is also true when I run it outside of nix-shell):
$ ps -p $postgres_pid,$nixshell_pid -o pid,ppid,wchan,tty,cmd
PID PPID WCHAN TT CMD
14608 18292 core_s pts/12 bash --rcfile /tmp/nix-shell-14608-0/rc
16355 1 core_s pts/12 /nix/store/xxxxxx-postgresql-9.6.8/bin/postgres
What's a good next step in debugging this? Should I read up on process groups?
Update: Trying a tip from another question, I found that this fixes the problem:
set -m
pg_ctl start --silent --log $PWD/log/pg.log
The weird thing is, according to $-, the m option was already set. Running echo $- produces imBH both before and after the set -m.
I noticed that in my interactive shells (whether nix-shell or not), $- is imBHs. The s is not present in the shellHook context, and I can't find an explanation of its meaning in the docs for Bash's set builtin. This may not be related though...
background-process signals process-management
background-process signals process-management
edited Aug 7 at 12:26
asked Aug 7 at 5:14
ivan
662719
662719
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
The manual says
start mode launches a new server. ... On Unix-like systems, by default, the server's standard output and standard error are sent to pg_ctl's standard output (not standard error). The standard output of pg_ctl should then be redirected to a file or piped to another process such as a log rotating program like rotatelogs; otherwise postgres will write its output to the controlling terminal (from the background) and will not leave the shell's process group. ...Use of either -l or output redirection is recommended.
It seems you need to redirect the output to detatch pg_ctl from the shell.
I'm using the-loption (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.
â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may trynohup,
â RalfFriedl
Aug 7 at 16:58
add a comment |Â
up vote
0
down vote
accepted
It seems the problem was that the postgresql server was running as part of the same process group as the shell that launched it via pg_ctl. Typing propagated a SIGINT to all processes in the group.
One way to fix this is to launch postgresql in its own session using setsid.
setsid pg_ctl start --silent --log $PWD/log/pg.log
That said, I still don't know why this only happens in the context of shellHook.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The manual says
start mode launches a new server. ... On Unix-like systems, by default, the server's standard output and standard error are sent to pg_ctl's standard output (not standard error). The standard output of pg_ctl should then be redirected to a file or piped to another process such as a log rotating program like rotatelogs; otherwise postgres will write its output to the controlling terminal (from the background) and will not leave the shell's process group. ...Use of either -l or output redirection is recommended.
It seems you need to redirect the output to detatch pg_ctl from the shell.
I'm using the-loption (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.
â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may trynohup,
â RalfFriedl
Aug 7 at 16:58
add a comment |Â
up vote
0
down vote
The manual says
start mode launches a new server. ... On Unix-like systems, by default, the server's standard output and standard error are sent to pg_ctl's standard output (not standard error). The standard output of pg_ctl should then be redirected to a file or piped to another process such as a log rotating program like rotatelogs; otherwise postgres will write its output to the controlling terminal (from the background) and will not leave the shell's process group. ...Use of either -l or output redirection is recommended.
It seems you need to redirect the output to detatch pg_ctl from the shell.
I'm using the-loption (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.
â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may trynohup,
â RalfFriedl
Aug 7 at 16:58
add a comment |Â
up vote
0
down vote
up vote
0
down vote
The manual says
start mode launches a new server. ... On Unix-like systems, by default, the server's standard output and standard error are sent to pg_ctl's standard output (not standard error). The standard output of pg_ctl should then be redirected to a file or piped to another process such as a log rotating program like rotatelogs; otherwise postgres will write its output to the controlling terminal (from the background) and will not leave the shell's process group. ...Use of either -l or output redirection is recommended.
It seems you need to redirect the output to detatch pg_ctl from the shell.
The manual says
start mode launches a new server. ... On Unix-like systems, by default, the server's standard output and standard error are sent to pg_ctl's standard output (not standard error). The standard output of pg_ctl should then be redirected to a file or piped to another process such as a log rotating program like rotatelogs; otherwise postgres will write its output to the controlling terminal (from the background) and will not leave the shell's process group. ...Use of either -l or output redirection is recommended.
It seems you need to redirect the output to detatch pg_ctl from the shell.
answered Aug 7 at 5:32
RalfFriedl
3,5601522
3,5601522
I'm using the-loption (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.
â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may trynohup,
â RalfFriedl
Aug 7 at 16:58
add a comment |Â
I'm using the-loption (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.
â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may trynohup,
â RalfFriedl
Aug 7 at 16:58
I'm using the
-l option (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.â ivan
Aug 7 at 11:55
I'm using the
-l option (--log), which supposedly will work as well. I tried using redirection instead (pg_ctl start --silent > $PWD/log/pg.log), but I get the same results. I also tried redirecting stderr as well (2>&1), still no difference.â ivan
Aug 7 at 11:55
I would consider that a bug in pg_ctl. You may try
nohup,â RalfFriedl
Aug 7 at 16:58
I would consider that a bug in pg_ctl. You may try
nohup,â RalfFriedl
Aug 7 at 16:58
add a comment |Â
up vote
0
down vote
accepted
It seems the problem was that the postgresql server was running as part of the same process group as the shell that launched it via pg_ctl. Typing propagated a SIGINT to all processes in the group.
One way to fix this is to launch postgresql in its own session using setsid.
setsid pg_ctl start --silent --log $PWD/log/pg.log
That said, I still don't know why this only happens in the context of shellHook.
add a comment |Â
up vote
0
down vote
accepted
It seems the problem was that the postgresql server was running as part of the same process group as the shell that launched it via pg_ctl. Typing propagated a SIGINT to all processes in the group.
One way to fix this is to launch postgresql in its own session using setsid.
setsid pg_ctl start --silent --log $PWD/log/pg.log
That said, I still don't know why this only happens in the context of shellHook.
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
It seems the problem was that the postgresql server was running as part of the same process group as the shell that launched it via pg_ctl. Typing propagated a SIGINT to all processes in the group.
One way to fix this is to launch postgresql in its own session using setsid.
setsid pg_ctl start --silent --log $PWD/log/pg.log
That said, I still don't know why this only happens in the context of shellHook.
It seems the problem was that the postgresql server was running as part of the same process group as the shell that launched it via pg_ctl. Typing propagated a SIGINT to all processes in the group.
One way to fix this is to launch postgresql in its own session using setsid.
setsid pg_ctl start --silent --log $PWD/log/pg.log
That said, I still don't know why this only happens in the context of shellHook.
edited Aug 10 at 13:32
answered Aug 10 at 13:26
ivan
662719
662719
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460955%2fbackground-process-postgresql-receiving-sigint-from-ctrl-c-in-shell%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password