Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #57080 > unrolled thread

misterious behavior of either kill or terminal

Back to article view | Back to alt.os.linux

Contents

  misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-21 20:07 +0200
    Re: misterious behavior of either kill or terminal Dan Purgert <dan@djph.net> - 2019-06-21 18:21 +0000
      Re: misterious behavior of either kill or terminal marrgol <marrgol@address.invalid> - 2019-06-22 13:27 +0200
      Re: misterious behavior of either kill or terminal Jasen Betts <jasen@xnet.co.nz> - 2019-06-23 05:31 +0000
        Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-28 10:54 +0200
          Funny... (Was: misterious behavior of either kill or terminal) gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-28 09:15 +0000
          Re: misterious behavior of either kill or terminal Georges <georges@prout.com> - 2019-06-28 11:35 +0200
            Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-28 11:50 +0200
              Re: misterious behavior of either kill or terminal Georges <georges@prout.com> - 2019-06-28 12:21 +0200
              Re: misterious behavior of either kill or terminal Richard Kettlewell <invalid@invalid.invalid> - 2019-06-28 13:26 +0100
                Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-28 14:51 +0200
                  Re: misterious behavior of either kill or terminal Richard Kettlewell <invalid@invalid.invalid> - 2019-06-28 14:10 +0100
                    Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-28 20:06 +0200
                      Re: misterious behavior of either kill or terminal Georges <georges@prout.com> - 2019-06-28 20:54 +0200
                  Re: misterious behavior of either kill or terminal owl <owl@rooftop.invalid> - 2019-06-28 14:51 +0000
                  Re: misterious behavior of either kill or terminal "F. Russell" <frussell@random.info> - 2019-06-28 17:40 +0000
                Re: misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-28 16:45 +0200
          Re: misterious behavior of either kill or terminal Jasen Betts <jasen@xnet.co.nz> - 2019-06-28 10:29 +0000
            Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-28 14:54 +0200
    Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-21 20:26 +0200
      Re: misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-22 00:02 +0200
        Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 13:17 +0200
          Re: misterious behavior of either kill or terminal marrgol <marrgol@address.invalid> - 2019-06-22 13:32 +0200
            Re: misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-23 17:57 +0200
    Re: misterious behavior of either kill or terminal Paul <nospam@needed.invalid> - 2019-06-21 15:14 -0400
      Re: misterious behavior of either kill or terminal Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-21 20:42 +0000
      Re: misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-22 00:23 +0200
        Re: misterious behavior of either kill or terminal "J.O. Aho" <user@example.net> - 2019-06-22 09:50 +0200
          Re: misterious behavior of either kill or terminal gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-22 19:13 +0000
            Re: misterious behavior of either kill or terminal "J.O. Aho" <user@example.net> - 2019-06-22 23:41 +0200
        Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 13:30 +0200
    Re: misterious behavior of either kill or terminal "J.O. Aho" <user@example.net> - 2019-06-21 21:39 +0200
      Re: misterious behavior of either kill or terminal Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-22 00:33 +0200
        Re: misterious behavior of either kill or terminal "J.O. Aho" <user@example.net> - 2019-06-22 09:28 +0200
        Re: misterious behavior of either kill or terminal "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 13:34 +0200

Page 1 of 2  [1] 2  Next page →

#57080 — misterious behavior of either kill or terminal

I had launched a very long "dd" proc. un the laptop in a 
TERMINAL (500 gb to transfer).
The light of the drive blinked but no sign of progress were 
reported on screen

the copy operation, if relevant, was partition to partition 
(I used no offset for data even if first starting sector of 
each was reported 2048 but I figured out that offset was the 
start sector of the partition itself relative to the 
beginning of the disk, hence indicating the partitions and 
not the disk as "if=" and "of=" I thought 0 offset).
The problem though was the absence of progression

I have read the manual of dd anyway noticing that it claimed 
: on receiving signal USR1 the process would have printed to 
stderr some stats of activity and then autoresume the work


So I collected the PID of the terminal windows where the 
subprocess "dd" was running (I picked up that PID for no 
"dd" process was mentioned in the Process Manager or Monitor 
I can't recall the name, I was using a Live distro, and no 
hierarchical info was available).

then I did (in another terminal, taking note it was assigned 
a higher PID)

"sudo kill -SIGUSR1 44356"
the 44356 was original Terminal  PID containing dd

and the window just closed.
SIGUSR1 is so mortal ?
to whom should I have sent the signal and how to get the PID 
of the subprocess ?

a part from that : the disk activity kept going on as if 
there was a parentless process still alive in back ground 
(which I had no way to abort, not having any longer a window 
to receive some CTRL+C to cancel, and did not show up in 
process manager to be manually terminated).

Now I have relaunched the command (hours later), hoping that 
would simply OVERWRITE again ... and I won't try to send 
signal to the process

but I'd like to understand what would be the right mode to 
locate a child nested process in the PID list or how to pass 
signal to the container (terminal) in order for it to pass 
the signal to its child ....

I'm sorry I'm sort of flooding with questions, but even the 
things that apparently seem simple and intuitive result in 
disaster :\

If the question annoys you, then skip it
It's just a try


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [next] | [standalone]

#57081

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Soviet_Mario wrote:
>
> I had launched a very long "dd" proc. un the laptop in a 
> TERMINAL (500 gb to transfer).
> The light of the drive blinked but no sign of progress were 
> reported on screen

This is normal.  

> [...]
> "sudo kill -SIGUSR1 44356"
> the 44356 was original Terminal  PID containing dd

You sent the wrong signal 'SIGUSR1' is (as I recall) 'kill -USR1 <pid>'.

> [...]
> Now I have relaunched the command (hours later), hoping that 
> would simply OVERWRITE again ... and I won't try to send 
> signal to the process

It'll overwrite, yes.

> [...]
> but I'd like to understand what would be the right mode to 
> locate a child nested process in the PID list or how to pass 
> signal to the container (terminal) in order for it to pass 
> the signal to its child ....

You send the signal to DD, not anything else.


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0NIB0ACgkQjhHd8xJ5
ooGvRAgAsBh8qO1jopKr9B1esSOV5yt8ZbI0JN6/F8YSsfoGXQU1U6KOaVdxhjKi
0m7p1r2y9QZ0XbAldhkt4p5HUPD7VqsoV6sSAHJAVSdn88s56XmWac3RZqZV+DsG
09YuWQlTZNK2XJzSq25X0o0yGPCENh2ilfMLIYVJohJre3In3Sj30/sHGCeQQ3Sl
0LmhQ2R1Vw+ljGFpcO7TOdavgW3RVIZ9eNP7CAksM/BOsbUIvsVs8jBqj779bkTk
6es9h6m6ICoKJu8iVDwBd0cFJ2UCvhcDV35mxVCop1poVFUGN89Zi4YRGiS4ccEy
Ezl5qWeb4rFYj3TFYo6T0doEX6DAFQ==
=j8ok
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#57110

>> I had launched a very long "dd" proc. un the laptop in a 
>> TERMINAL (500 gb to transfer).
>> The light of the drive blinked but no sign of progress were 
>> reported on screen
> 
> This is normal.  

Progress can be seen when dd's 'status=progress' operand is being used.


-- 
mrg

[toc] | [prev] | [next] | [standalone]

#57159

On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
>
> Soviet_Mario wrote:
>>
>> I had launched a very long "dd" proc. un the laptop in a 
>> TERMINAL (500 gb to transfer).
>> The light of the drive blinked but no sign of progress were 
>> reported on screen
>
> This is normal.  
>
>> [...]
>> "sudo kill -SIGUSR1 44356"
>> the 44356 was original Terminal  PID containing dd
>
> You sent the wrong signal 'SIGUSR1' is (as I recall) 'kill -USR1 <pid>'.

Either form works: "SIG" is optional.

>> [...]
>> Now I have relaunched the command (hours later), hoping that 
>> would simply OVERWRITE again ... and I won't try to send 
>> signal to the process
>
> It'll overwrite, yes.
>
>> [...]
>> but I'd like to understand what would be the right mode to 
>> locate a child nested process in the PID list or how to pass 
>> signal to the container (terminal) in order for it to pass 
>> the signal to its child ....
>
> You send the signal to DD, not anything else.

yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
it, if you send it the wrong way: processes die.


-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#57302

On 23/06/2019 07.31, Jasen Betts wrote:
> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
>>
>> Soviet_Mario wrote:
>>>
>>> I had launched a very long "dd" proc. un the laptop in a 
>>> TERMINAL (500 gb to transfer).
>>> The light of the drive blinked but no sign of progress were 
>>> reported on screen
>>
>> This is normal.  
>>
>>> [...]
>>> "sudo kill -SIGUSR1 44356"
>>> the 44356 was original Terminal  PID containing dd
>>
>> You sent the wrong signal 'SIGUSR1' is (as I recall) 'kill -USR1 <pid>'.
> 
> Either form works: "SIG" is optional.
> 
>>> [...]
>>> Now I have relaunched the command (hours later), hoping that 
>>> would simply OVERWRITE again ... and I won't try to send 
>>> signal to the process
>>
>> It'll overwrite, yes.
>>
>>> [...]
>>> but I'd like to understand what would be the right mode to 
>>> locate a child nested process in the PID list or how to pass 
>>> signal to the container (terminal) in order for it to pass 
>>> the signal to its child ....
>>
>> You send the signal to DD, not anything else.
> 
> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
> it, if you send it the wrong way: processes die.

Why should a process die if sent a signal that it doesn't handle?
SIGUSR1,2 are defined by the application. What they mean is entirely up
to the application, there is no default action.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#57303 — Funny... (Was: misterious behavior of either kill or terminal)

In article <171huf-87h.ln1@Telcontar.valinor>,
Carlos E.R. <robin_listas@es.invalid> wrote:
...
>Why should a process die if sent a signal that it doesn't handle?
>SIGUSR1,2 are defined by the application. What they mean is entirely up
>to the application, there is no default action.

Funny.

-- 
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof. 

    - John Kenneth Galbraith -

[toc] | [prev] | [next] | [standalone]

#57304

Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
> On 23/06/2019 07.31, Jasen Betts wrote:
>> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
>>>
>>> Soviet_Mario wrote:
>>>>
>>>> I had launched a very long "dd" proc. un the laptop in a 
>>>> TERMINAL (500 gb to transfer).
>>>> The light of the drive blinked but no sign of progress were 
>>>> reported on screen
>>>
>>> This is normal.  
>>>
>>>> [...]
>>>> "sudo kill -SIGUSR1 44356"
>>>> the 44356 was original Terminal  PID containing dd
>>>
>>> You sent the wrong signal 'SIGUSR1' is (as I recall) 'kill -USR1 <pid>'.
>>
>> Either form works: "SIG" is optional.
>>
>>>> [...]
>>>> Now I have relaunched the command (hours later), hoping that 
>>>> would simply OVERWRITE again ... and I won't try to send 
>>>> signal to the process
>>>
>>> It'll overwrite, yes.
>>>
>>>> [...]
>>>> but I'd like to understand what would be the right mode to 
>>>> locate a child nested process in the PID list or how to pass 
>>>> signal to the container (terminal) in order for it to pass 
>>>> the signal to its child ....
>>>
>>> You send the signal to DD, not anything else.
>>
>> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
>> it, if you send it the wrong way: processes die.
> 
> Why should a process die if sent a signal that it doesn't handle?
> SIGUSR1,2 are defined by the application. What they mean is entirely up
> to the application, there is no default action.
> 

Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
is 'term'(inate) the process.

http://man7.org/linux/man-pages/man7/signal.7.html

;)

-- 
()
/\

[toc] | [prev] | [next] | [standalone]

#57305

On 28/06/2019 11.35, Georges wrote:
> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>> On 23/06/2019 07.31, Jasen Betts wrote:
>>> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
>>>>
>>>> Soviet_Mario wrote:

...

>>> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
>>> it, if you send it the wrong way: processes die.
>>
>> Why should a process die if sent a signal that it doesn't handle?
>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>> to the application, there is no default action.
>>
> 
> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
> is 'term'(inate) the process.
> 
> http://man7.org/linux/man-pages/man7/signal.7.html
> 
> ;)
> 

I looked at the manual before writing. I still do not see it. What it
says is:

       SIGUSR1      P1990      Term    User-defined signal 1
       SIGUSR2      P1990      Term    User-defined signal 2

That's it. However, there is another paragraph I see when searching for
"default":

       Unlike standard signals, real-time signals have no predefined
       meanings: the entire set of real-time signals can be used for
       application-defined purposes.

       The default action for an unhandled real-time signal is to
       terminate the receiving process.


But my question remains: why should the default action be terminate the
program, and not ignore? I find this absurd. What is the logic in
terminating the program on ANY unknown signal?


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#57306

Le 28/06/2019 à 11:50, Carlos E.R. a écrit :
> On 28/06/2019 11.35, Georges wrote:
>> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>>> On 23/06/2019 07.31, Jasen Betts wrote:
>>>> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
>>>>>
>>>>> Soviet_Mario wrote:
> 
> ...
> 
>>>> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
>>>> it, if you send it the wrong way: processes die.
>>>
>>> Why should a process die if sent a signal that it doesn't handle?
>>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>>> to the application, there is no default action.
>>>
>>
>> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
>> is 'term'(inate) the process.
>>
>> http://man7.org/linux/man-pages/man7/signal.7.html
>>
>> ;)
>>
> 
> I looked at the manual before writing. I still do not see it. What it
> says is:
> 
>        SIGUSR1      P1990      Term    User-defined signal 1
>        SIGUSR2      P1990      Term    User-defined signal 2
> 
> That's it. However, there is another paragraph I see when searching for
> "default":
> 
>        Unlike standard signals, real-time signals have no predefined
>        meanings: the entire set of real-time signals can be used for
>        application-defined purposes.
> 
>        The default action for an unhandled real-time signal is to
>        terminate the receiving process.
> 
> 
> But my question remains: why should the default action be terminate the
> program, and not ignore? I find this absurd. What is the logic in
> terminating the program on ANY unknown signal?
> 
> 

Because of conception ;)

M.J. Bach -> page 200/203

http://160592857366.free.fr/joe/ebooks/ShareData/Design%20of%20the%20Unix%20Operating%20System%20By%20Maurice%20Bach.pdf

-- 
()
/\

[toc] | [prev] | [next] | [standalone]

#57308

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 28/06/2019 11.35, Georges wrote:
>> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>>> Why should a process die if sent a signal that it doesn't handle?
>>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>>> to the application, there is no default action.
>>>
>> 
>> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
>> is 'term'(inate) the process.
>> 
>> http://man7.org/linux/man-pages/man7/signal.7.html
>
> I looked at the manual before writing. I still do not see it. What it
> says is:
>
>        SIGUSR1      P1990      Term    User-defined signal 1
>        SIGUSR2      P1990      Term    User-defined signal 2
                                 ^^^^
Here -----------------------------/

> That's it. However, there is another paragraph I see when searching for
> "default":
>
>        Unlike standard signals, real-time signals have no predefined
>        meanings: the entire set of real-time signals can be used for
>        application-defined purposes.
>
>        The default action for an unhandled real-time signal is to
>        terminate the receiving process.

Irrelevant, SIGUSR1 is not a real-time signal.

> But my question remains: why should the default action be terminate the
> program, and not ignore? I find this absurd. What is the logic in
> terminating the program on ANY unknown signal?

You could as easily ask what the point of ignoring any unknown signal
would be.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#57310

On 28/06/2019 14.26, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 28/06/2019 11.35, Georges wrote:
>>> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>>>> Why should a process die if sent a signal that it doesn't handle?
>>>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>>>> to the application, there is no default action.
>>>>
>>>
>>> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
>>> is 'term'(inate) the process.
>>>
>>> http://man7.org/linux/man-pages/man7/signal.7.html
>>
>> I looked at the manual before writing. I still do not see it. What it
>> says is:
>>
>>        SIGUSR1      P1990      Term    User-defined signal 1
>>        SIGUSR2      P1990      Term    User-defined signal 2
>                                  ^^^^
> Here -----------------------------/

What's that? A Terminal related signal? Doesn't say anything to me.
Terminate? Then write "terminate". Nor the p1990. Page, year?  My man
page says value ant it is "30,10,16" and  "31,12,17", not "p1990".

> 
>> That's it. However, there is another paragraph I see when searching for
>> "default":
>>
>>        Unlike standard signals, real-time signals have no predefined
>>        meanings: the entire set of real-time signals can be used for
>>        application-defined purposes.
>>
>>        The default action for an unhandled real-time signal is to
>>        terminate the receiving process.
> 
> Irrelevant, SIGUSR1 is not a real-time signal.

Then it doesn't say the default action is terminate, the default action
is something else.

>> But my question remains: why should the default action be terminate the
>> program, and not ignore? I find this absurd. What is the logic in
>> terminating the program on ANY unknown signal?
> 
> You could as easily ask what the point of ignoring any unknown signal
> would be.

Why? I see it obvious that if my program doesn't want to respond to a
signal, I simply don't program anything for it. No handler, no default
action, nothing done.

It is a user defined signal, it is up to me to do something or ignore
it. Should be.

To kill a program there are specific signals.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#57312

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 28/06/2019 14.26, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 28/06/2019 11.35, Georges wrote:
>>>> http://man7.org/linux/man-pages/man7/signal.7.html
>>>
>>> I looked at the manual before writing. I still do not see it. What it
>>> says is:
>>>
>>>        SIGUSR1      P1990      Term    User-defined signal 1
>>>        SIGUSR2      P1990      Term    User-defined signal 2
>>                                  ^^^^
>> Here -----------------------------/
>
> What's that? A Terminal related signal? Doesn't say anything to me.
> Terminate? Then write "terminate". Nor the p1990. Page, year?  My man
> page says value ant it is "30,10,16" and  "31,12,17", not "p1990".

The Action and Standard columns are both described in the same document.

>>> That's it. However, there is another paragraph I see when searching for
>>> "default":
>>>
>>>        Unlike standard signals, real-time signals have no predefined
>>>        meanings: the entire set of real-time signals can be used for
>>>        application-defined purposes.
>>>
>>>        The default action for an unhandled real-time signal is to
>>>        terminate the receiving process.
>> 
>> Irrelevant, SIGUSR1 is not a real-time signal.
>
> Then it doesn't say the default action is terminate, the default action
> is something else.

You have the information you need, you just have to stop arguing and pay
attention to it.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#57317

On 28/06/2019 15.10, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:


> You have the information you need, you just have to stop arguing and pay
> attention to it.

Not arguing. I'm asking what is the reasoning to have the default action
"kill program".

"The penalty for the mistake sending a signal which is not handled is
death of the recipient"

Why?

It is the law, yes. But why?

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#57318

Le 28/06/2019 à 20:06, Carlos E.R. a écrit :
> On 28/06/2019 15.10, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
> 
> 
>> You have the information you need, you just have to stop arguing and pay
>> attention to it.
> 
> Not arguing. I'm asking what is the reasoning to have the default action
> "kill program".
> 
> "The penalty for the mistake sending a signal which is not handled is
> death of the recipient"
> 
> Why?
> 
> It is the law, yes. But why?
> 

Still considering USR1 et USR2 (not real-time signals)

When a process sends a signal to another one (so kernel_mode), the
kernel notifies the destination process with a simple bit, *without any
killing* because 'it knows' the handler is "in" user_mode.

A kernel_mode later, after the considered process user_mode, the process
is still there, no handler found...

what would have you done ?

"they" decided to kill that process to free that proc_tab entry ;)

it's more or less the same idea behind "why are there external and
internal kill commands ?" (with bash or zsh for instance) ?
To free proc_tab if it is already full...

;)

-- 
()
/\

[toc] | [prev] | [next] | [standalone]

#57314

Carlos E.R. <robin_listas@es.invalid> wrote:
> On 28/06/2019 14.26, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 28/06/2019 11.35, Georges wrote:
>>>> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>>>>> Why should a process die if sent a signal that it doesn't handle?
>>>>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>>>>> to the application, there is no default action.
>>>>>
>>>>
>>>> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
>>>> is 'term'(inate) the process.
>>>>
>>>> http://man7.org/linux/man-pages/man7/signal.7.html
>>>
>>> I looked at the manual before writing. I still do not see it. What it
>>> says is:
>>>
>>>        SIGUSR1      P1990      Term    User-defined signal 1
>>>        SIGUSR2      P1990      Term    User-defined signal 2
>>                                  ^^^^
>> Here -----------------------------/
> 
> What's that? A Terminal related signal? Doesn't say anything to me.
> Terminate? Then write "terminate". Nor the p1990. Page, year?  My man
> page says value ant it is "30,10,16" and  "31,12,17", not "p1990".
> 

Both "Term" and "P1990" are defined at the above link.


>> 
>>> That's it. However, there is another paragraph I see when searching for
>>> "default":
>>>
>>>        Unlike standard signals, real-time signals have no predefined
>>>        meanings: the entire set of real-time signals can be used for
>>>        application-defined purposes.
>>>
>>>        The default action for an unhandled real-time signal is to
>>>        terminate the receiving process.
>> 
>> Irrelevant, SIGUSR1 is not a real-time signal.
> 
> Then it doesn't say the default action is terminate, the default action
> is something else.
> 

It does say that in the table.


>>> But my question remains: why should the default action be terminate the
>>> program, and not ignore? I find this absurd. What is the logic in
>>> terminating the program on ANY unknown signal?
>> 
>> You could as easily ask what the point of ignoring any unknown signal
>> would be.
> 
> Why? I see it obvious that if my program doesn't want to respond to a
> signal, I simply don't program anything for it. No handler, no default
> action, nothing done.
> 
> It is a user defined signal, it is up to me to do something or ignore
> it. Should be.
> 
> To kill a program there are specific signals.
> 

POSIX specifies the default action.

[toc] | [prev] | [next] | [standalone]

#57316

On Fri, 28 Jun 2019 14:51:33 +0200, Carlos E.R. wrote:

> 
> Why? I see it obvious that if my program doesn't want to respond to a
> signal, I simply don't program anything for it. No handler, no default
> action, nothing done.
> 

Read the GNU C Library manual:

"For most kinds of signals, [including SIGUSR1,2], the default action is
to terminate the process."

https://www.gnu.org/software/libc/manual/html_mono/libc.html#Delivery-of-Signal

If you want to ignore the signal then this action must be explicitly
stated:

https://www.gnu.org/software/libc/manual/html_mono/libc.html#Signal-Messages

[toc] | [prev] | [next] | [standalone]

#57313

On 28/06/19 14:26, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 28/06/2019 11.35, Georges wrote:
>>> Le 28/06/2019 à 10:54, Carlos E.R. a écrit :
>>>> Why should a process die if sent a signal that it doesn't handle?
>>>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>>>> to the application, there is no default action.
>>>>
>>>
>>> Hi Carlos, if no handler found, the SIGUSR1 and SIGUSR2 default action
>>> is 'term'(inate) the process.
>>>
>>> http://man7.org/linux/man-pages/man7/signal.7.html
>>
>> I looked at the manual before writing. I still do not see it. What it
>> says is:
>>
>>         SIGUSR1      P1990      Term    User-defined signal 1
>>         SIGUSR2      P1990      Term    User-defined signal 2
>                                   ^^^^
> Here -----------------------------/
> 
>> That's it. However, there is another paragraph I see when searching for
>> "default":
>>
>>         Unlike standard signals, real-time signals have no predefined
>>         meanings: the entire set of real-time signals can be used for
>>         application-defined purposes.
>>
>>         The default action for an unhandled real-time signal is to
>>         terminate the receiving process.
> 
> Irrelevant, SIGUSR1 is not a real-time signal.
> 
>> But my question remains: why should the default action be terminate the
>> program, and not ignore? I find this absurd. What is the logic in
>> terminating the program on ANY unknown signal?
> 
> You could as easily ask what the point of ignoring any unknown signal
> would be.

well, in real world the logic is

I am a worker
Manager A tells me : DO this task ZZ
afterwards
Manager B tells me : @§#!!??G
Me : (not understanding) keep on working on task ZZ (the 
only certain thing)

Well this I was thinking when wrecklessly sending signals in 
a bottle :)

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57307

On 2019-06-28, Carlos E.R. <robin_listas@es.invalid> wrote:
> On 23/06/2019 07.31, Jasen Betts wrote:
>> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:

>>>
>>> You send the signal to DD, not anything else.
>> 
>> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
>> it, if you send it the wrong way: processes die.
>
> Why should a process die if sent a signal that it doesn't handle?

Why not?

> SIGUSR1,2 are defined by the application. What they mean is entirely up
> to the application, there is no default action.

Man 7 signal says SIGUSR1 default action is to terminate the process.

        Signal     Value     Action   Comment
       ──────────────────────────────────────────────────────────────────────
       SIGHUP        1       Term    Hangup detected on controlling terminal
                                     or death of controlling process
       SIGINT        2       Term    Interrupt from keyboard
       SIGQUIT       3       Core    Quit from keyboard
       SIGILL        4       Core    Illegal Instruction
       SIGABRT       6       Core    Abort signal from abort(3)
       SIGFPE        8       Core    Floating-point exception
       SIGKILL       9       Term    Kill signal
       SIGSEGV      11       Core    Invalid memory reference
       SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                     readers; see pipe(7)
       SIGALRM      14       Term    Timer signal from alarm(2)
       SIGTERM      15       Term    Termination signal
       SIGUSR1   30,10,16    Term    User-defined signal 1
       SIGUSR2   31,12,17    Term    User-defined signal 2
       SIGCHLD   20,17,18    Ign     Child stopped or terminated
       SIGCONT   19,18,25    Cont    Continue if stopped
       SIGSTOP   17,19,23    Stop    Stop process
       SIGTSTP   18,20,24    Stop    Stop typed at terminal

-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#57315

On 28/06/2019 12.29, Jasen Betts wrote:
> On 2019-06-28, Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 23/06/2019 07.31, Jasen Betts wrote:
>>> On 2019-06-21, Dan Purgert <dan@djph.net> wrote:
> 
>>>>
>>>> You send the signal to DD, not anything else.
>>>
>>> yeah, SIGUSR1 is, by default, fatal; a process must set a handler for
>>> it, if you send it the wrong way: processes die.
>>
>> Why should a process die if sent a signal that it doesn't handle?
> 
> Why not?

It is obvious to me that if I don't program anything to do for a signal
reserved to the user, it should do nothing. Likewise, if I type "die" at
a program prompt, it does not die unless *I* program it to die on word
"die".

> 
>> SIGUSR1,2 are defined by the application. What they mean is entirely up
>> to the application, there is no default action.
> 
> Man 7 signal says SIGUSR1 default action is to terminate the process.

Why? What is the reasoning?

Don't say why not, I asked first :-)


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#57083

On 21/06/2019 20.07, Soviet_Mario wrote:
> 
> I had launched a very long "dd" proc. un the laptop in a TERMINAL (500
> gb to transfer).
> The light of the drive blinked but no sign of progress were reported on
> screen
> 
> the copy operation, if relevant, was partition to partition (I used no
> offset for data even if first starting sector of each was reported 2048
> but I figured out that offset was the start sector of the partition
> itself relative to the beginning of the disk, hence indicating the
> partitions and not the disk as "if=" and "of=" I thought 0 offset).
> The problem though was the absence of progression
> 
> I have read the manual of dd anyway noticing that it claimed : on
> receiving signal USR1 the process would have printed to stderr some
> stats of activity and then autoresume the work
> 
> 
> So I collected the PID of the terminal windows where the subprocess "dd"
> was running (I picked up that PID for no "dd" process was mentioned in
> the Process Manager or Monitor I can't recall the name, I was using a
> Live distro, and no hierarchical info was available).
> 
> then I did (in another terminal, taking note it was assigned a higher PID)
> 
> "sudo kill -SIGUSR1 44356"
> the 44356 was original Terminal  PID containing dd
> 
> and the window just closed.
> SIGUSR1 is so mortal ?
> to whom should I have sent the signal and how to get the PID of the
> subprocess ?

to 'dd', obviously.

ps ax | grep dd

If you want to see the hierarchy:

ps afx | less

> 
> a part from that : the disk activity kept going on as if there was a
> parentless process still alive in back ground (which I had no way to
> abort, not having any longer a window to receive some CTRL+C to cancel,
> and did not show up in process manager to be manually terminated).

killall dd

for instance.




-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.linux

csiph-web