under which conditions is process orphaned in FreeBSD
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have a network device based on FreeBSD 7
. For some reason, sometimes /usr/sbin/cli
(executable which provides vendor-specific CLI) and its child-process are orphaned(alive, but parent is init
):
# ps -p 7173,7175,1 -o pid,ppid,start,user,command
PID PPID STARTED USER COMMAND
1 0 26Apr17 root /packages/mnt/jbase/sbin/init --
7173 1 31Dec17 test cli -c traceroute 10.10.98.8 as-number-lookup; quit
7175 7173 31Dec17 test /usr/sbin/traceroute -JA 10.10.98.8
#
As seen above, cli
(process status is idle
) was started a month ago. It was started by sshd
(runs under user root
). What signal is sent by sshd
process to cli
process when SSH client time-outs or disconnects? Is cli
process able to ignore this signal? I tried to analyze this with truss
by executing truss -f -p <cli PID>
and then disconnecting the SSH client, but no signals were sent to cli
. Then I took a step back and executed truss -f -p <sshd: freebsd@notty (sshd) PID>
(parent process of cli
process) and killed the SSH client. This provides the following debug output:
1565: select(13, 3 5 7 10 12 , ,0x0,0x0) = 1 (0x1)
1565: sigprocmask(SIG_BLOCK, SIGCHLD , ) = 0 (0x0)
1565: sigprocmask(SIG_SETMASK, ,0x0) = 0 (0x0)
1565: clock_gettime(4, 5568.946095396 ) = 0 (0x0)
1565: read(3,"M^]G)M-=[M^YM-ZM-pDM^OM^]"...,16384) = 60 (0x3c)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,106,0x0,NULL,0x0) = 106 (0x6a)
1565: close(8) = 0 (0x0)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,74,0x0,NULL,0x0) = 74 (0x4a)
1565: close(8) = 0 (0x0)
1565: geteuid() = 1001 (0x3e9)
1565: unlink("/tmp/ssh-2A9AWQYCLZ/agent.1565") = 0 (0x0)
1565: rmdir(0x804024c40) = 0 (0x0)
1565: process exit, rval = 255
freebsd signals
add a comment |Â
up vote
1
down vote
favorite
I have a network device based on FreeBSD 7
. For some reason, sometimes /usr/sbin/cli
(executable which provides vendor-specific CLI) and its child-process are orphaned(alive, but parent is init
):
# ps -p 7173,7175,1 -o pid,ppid,start,user,command
PID PPID STARTED USER COMMAND
1 0 26Apr17 root /packages/mnt/jbase/sbin/init --
7173 1 31Dec17 test cli -c traceroute 10.10.98.8 as-number-lookup; quit
7175 7173 31Dec17 test /usr/sbin/traceroute -JA 10.10.98.8
#
As seen above, cli
(process status is idle
) was started a month ago. It was started by sshd
(runs under user root
). What signal is sent by sshd
process to cli
process when SSH client time-outs or disconnects? Is cli
process able to ignore this signal? I tried to analyze this with truss
by executing truss -f -p <cli PID>
and then disconnecting the SSH client, but no signals were sent to cli
. Then I took a step back and executed truss -f -p <sshd: freebsd@notty (sshd) PID>
(parent process of cli
process) and killed the SSH client. This provides the following debug output:
1565: select(13, 3 5 7 10 12 , ,0x0,0x0) = 1 (0x1)
1565: sigprocmask(SIG_BLOCK, SIGCHLD , ) = 0 (0x0)
1565: sigprocmask(SIG_SETMASK, ,0x0) = 0 (0x0)
1565: clock_gettime(4, 5568.946095396 ) = 0 (0x0)
1565: read(3,"M^]G)M-=[M^YM-ZM-pDM^OM^]"...,16384) = 60 (0x3c)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,106,0x0,NULL,0x0) = 106 (0x6a)
1565: close(8) = 0 (0x0)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,74,0x0,NULL,0x0) = 74 (0x4a)
1565: close(8) = 0 (0x0)
1565: geteuid() = 1001 (0x3e9)
1565: unlink("/tmp/ssh-2A9AWQYCLZ/agent.1565") = 0 (0x0)
1565: rmdir(0x804024c40) = 0 (0x0)
1565: process exit, rval = 255
freebsd signals
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a network device based on FreeBSD 7
. For some reason, sometimes /usr/sbin/cli
(executable which provides vendor-specific CLI) and its child-process are orphaned(alive, but parent is init
):
# ps -p 7173,7175,1 -o pid,ppid,start,user,command
PID PPID STARTED USER COMMAND
1 0 26Apr17 root /packages/mnt/jbase/sbin/init --
7173 1 31Dec17 test cli -c traceroute 10.10.98.8 as-number-lookup; quit
7175 7173 31Dec17 test /usr/sbin/traceroute -JA 10.10.98.8
#
As seen above, cli
(process status is idle
) was started a month ago. It was started by sshd
(runs under user root
). What signal is sent by sshd
process to cli
process when SSH client time-outs or disconnects? Is cli
process able to ignore this signal? I tried to analyze this with truss
by executing truss -f -p <cli PID>
and then disconnecting the SSH client, but no signals were sent to cli
. Then I took a step back and executed truss -f -p <sshd: freebsd@notty (sshd) PID>
(parent process of cli
process) and killed the SSH client. This provides the following debug output:
1565: select(13, 3 5 7 10 12 , ,0x0,0x0) = 1 (0x1)
1565: sigprocmask(SIG_BLOCK, SIGCHLD , ) = 0 (0x0)
1565: sigprocmask(SIG_SETMASK, ,0x0) = 0 (0x0)
1565: clock_gettime(4, 5568.946095396 ) = 0 (0x0)
1565: read(3,"M^]G)M-=[M^YM-ZM-pDM^OM^]"...,16384) = 60 (0x3c)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,106,0x0,NULL,0x0) = 106 (0x6a)
1565: close(8) = 0 (0x0)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,74,0x0,NULL,0x0) = 74 (0x4a)
1565: close(8) = 0 (0x0)
1565: geteuid() = 1001 (0x3e9)
1565: unlink("/tmp/ssh-2A9AWQYCLZ/agent.1565") = 0 (0x0)
1565: rmdir(0x804024c40) = 0 (0x0)
1565: process exit, rval = 255
freebsd signals
I have a network device based on FreeBSD 7
. For some reason, sometimes /usr/sbin/cli
(executable which provides vendor-specific CLI) and its child-process are orphaned(alive, but parent is init
):
# ps -p 7173,7175,1 -o pid,ppid,start,user,command
PID PPID STARTED USER COMMAND
1 0 26Apr17 root /packages/mnt/jbase/sbin/init --
7173 1 31Dec17 test cli -c traceroute 10.10.98.8 as-number-lookup; quit
7175 7173 31Dec17 test /usr/sbin/traceroute -JA 10.10.98.8
#
As seen above, cli
(process status is idle
) was started a month ago. It was started by sshd
(runs under user root
). What signal is sent by sshd
process to cli
process when SSH client time-outs or disconnects? Is cli
process able to ignore this signal? I tried to analyze this with truss
by executing truss -f -p <cli PID>
and then disconnecting the SSH client, but no signals were sent to cli
. Then I took a step back and executed truss -f -p <sshd: freebsd@notty (sshd) PID>
(parent process of cli
process) and killed the SSH client. This provides the following debug output:
1565: select(13, 3 5 7 10 12 , ,0x0,0x0) = 1 (0x1)
1565: sigprocmask(SIG_BLOCK, SIGCHLD , ) = 0 (0x0)
1565: sigprocmask(SIG_SETMASK, ,0x0) = 0 (0x0)
1565: clock_gettime(4, 5568.946095396 ) = 0 (0x0)
1565: read(3,"M^]G)M-=[M^YM-ZM-pDM^OM^]"...,16384) = 60 (0x3c)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,106,0x0,NULL,0x0) = 106 (0x6a)
1565: close(8) = 0 (0x0)
1565: clock_gettime(13, 1517409641.000000000 ) = 0 (0x0)
1565: getpid() = 1565 (0x61d)
1565: socket(PF_LOCAL,SOCK_DGRAM,0) = 8 (0x8)
1565: fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0)
1565: connect(8, AF_UNIX "/var/run/logpriv" ,106) ERR#13 'Permission denied'
1565: connect(8, AF_UNIX "/var/run/log" ,106) = 0 (0x0)
1565: sendto(8,"<38>Jan 31 14:40:41 sshd[1565]: "...,74,0x0,NULL,0x0) = 74 (0x4a)
1565: close(8) = 0 (0x0)
1565: geteuid() = 1001 (0x3e9)
1565: unlink("/tmp/ssh-2A9AWQYCLZ/agent.1565") = 0 (0x0)
1565: rmdir(0x804024c40) = 0 (0x0)
1565: process exit, rval = 255
freebsd signals
asked Jan 31 at 15:07
Martin
3662364120
3662364120
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
I'm not a FreeBSD user, but this is basically a Unix question...
A process is orphaned whenever it's parent process dies. This happens all the time, and is not normally a problem. A parent dying does not automatically kill the child.
In the specific case of SSH (and telnet, etc), the shell would normally receive SIGHUP when the connection is lost. It's that that kills the shell, not being orphaned. If your custom CLI chooses to handle SIGHUP in a non-standard way (i.e. not die) then anything could happen.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I'm not a FreeBSD user, but this is basically a Unix question...
A process is orphaned whenever it's parent process dies. This happens all the time, and is not normally a problem. A parent dying does not automatically kill the child.
In the specific case of SSH (and telnet, etc), the shell would normally receive SIGHUP when the connection is lost. It's that that kills the shell, not being orphaned. If your custom CLI chooses to handle SIGHUP in a non-standard way (i.e. not die) then anything could happen.
add a comment |Â
up vote
1
down vote
I'm not a FreeBSD user, but this is basically a Unix question...
A process is orphaned whenever it's parent process dies. This happens all the time, and is not normally a problem. A parent dying does not automatically kill the child.
In the specific case of SSH (and telnet, etc), the shell would normally receive SIGHUP when the connection is lost. It's that that kills the shell, not being orphaned. If your custom CLI chooses to handle SIGHUP in a non-standard way (i.e. not die) then anything could happen.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I'm not a FreeBSD user, but this is basically a Unix question...
A process is orphaned whenever it's parent process dies. This happens all the time, and is not normally a problem. A parent dying does not automatically kill the child.
In the specific case of SSH (and telnet, etc), the shell would normally receive SIGHUP when the connection is lost. It's that that kills the shell, not being orphaned. If your custom CLI chooses to handle SIGHUP in a non-standard way (i.e. not die) then anything could happen.
I'm not a FreeBSD user, but this is basically a Unix question...
A process is orphaned whenever it's parent process dies. This happens all the time, and is not normally a problem. A parent dying does not automatically kill the child.
In the specific case of SSH (and telnet, etc), the shell would normally receive SIGHUP when the connection is lost. It's that that kills the shell, not being orphaned. If your custom CLI chooses to handle SIGHUP in a non-standard way (i.e. not die) then anything could happen.
answered Feb 7 at 10:43
ams
4,1821123
4,1821123
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%2f420984%2funder-which-conditions-is-process-orphaned-in-freebsd%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