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-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 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-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 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-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 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-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 trynohup
,
â RalfFriedl
Aug 7 at 16:58
add a comment |Â
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 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