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 2 of 2 — ← Prev page 1 [2]

#57093

Il 21/06/19 20:26, Carlos E.R. ha scritto:
> 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.

I wrote the wrong question : I actually meant, TO WHICH PID 
(and where to get it)

> 
> ps ax | grep dd

I'll search about this command

> 
> 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

but kill can also send signals by process name besides by PID ?

> 
> for instance.
> 
> 
> 
> 


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

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

#57109

On 22/06/2019 00.02, Soviet_Mario wrote:
> Il 21/06/19 20:26, Carlos E.R. ha scritto:
>> On 21/06/2019 20.07, Soviet_Mario wrote:

...


>>> 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.
> 
> I wrote the wrong question : I actually meant, TO WHICH PID (and where
> to get it)
> 
>>
>> ps ax | grep dd
> 
> I'll search about this command

It is two commands connected through a pipe.



>> 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
> 
> but kill can also send signals by process name besides by PID ?

Not 'kill', but 'killall'.

But it will kill all processes named "dd", not a single one. And yes, it
can also send arbitrary signals by name.

-- 
Cheers, Carlos.

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

#57113

On 2019-06-22 at 13:17, Carlos E.R. wrote:
>>> killall dd
>> 
>> but kill can also send signals by process name besides by PID ?
> 
> Not 'kill', but 'killall'.
> 
> But it will kill all processes named "dd", not a single one. And yes, it
> can also send arbitrary signals by name.

You can use 'pkill -f' to match the whole command line of the process
of interest (and 'pgrep -f' before that to make sure you catch the
one you really want ;-)).


-- 
mrg

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

#57183

Il 22/06/19 13:32, marrgol ha scritto:
> On 2019-06-22 at 13:17, Carlos E.R. wrote:
>>>> killall dd
>>>
>>> but kill can also send signals by process name besides by PID ?
>>
>> Not 'kill', but 'killall'.
>>
>> But it will kill all processes named "dd", not a single one. And yes, it
>> can also send arbitrary signals by name.
> 
> You can use 'pkill -f' to match the whole command line of the process
> of interest (and 'pgrep -f' before that to make sure you catch the
> one you really want ;-)).
> 
> 

thanks.


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

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

#57085

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 ?
> 
> 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

Let's say the disk drive has a bad sector.

The operation you were doing, might take as long
as 15 seconds to return a result to the kernel.
(On a TLER drive, it might be less than seven
seconds.)

During that time, it's possible the task cannot
be killed, because it's still in a kernel call.

Another thing that might matter, is whether the
port is in an IDE mode or an AHCI mode. With AHCI,
there is effectively disconnect/reselect, like in
SCSI. Commands are tagged. You can "kick off" a
command, and the command comes back when it is
good and ready. This means the process should not
be blocked on I/O, because an event will be raised
to it when the I/O eventually comes back (it
either worked or it threw an error).

When "dd" won't respond, that hints to me that
the disk drive is bad. And you should be using
package "gddrescue" and the ddrescue executable
instead.

    man ddrescue

I think ddrescue can be faster, because it
can dynamically adjust the block size for
best transfer rate (but only on the good parts
of the disk -- sectors that are bad, are always
as slow to resolve, no matter what).

    Paul

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

#57089

On 2019-06-21, Paul <nospam@needed.invalid> 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
>> 
>> 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 ?
Depends on what program does. It can be noop it can be exit or something
else...


>> to whom should I have sent the signal and how to get the PID of the 
>> subprocess ?

Same way as you found for terminal...
>> 


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#57094

Il 21/06/19 21:14, Paul ha scritto:
> 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 ?
>>
>> 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
> 
> Let's say the disk drive has a bad sector.
> 
> The operation you were doing, might take as long

which operation in particular ?
After sending SIGUSR1 the terminal itself responded in zero 
time, the child remained active forever

> as 15 seconds to return a result to the kernel.
> (On a TLER drive, it might be less than seven
> seconds.)

the disk is a SSD encased in a box and connected to a slow 
USB 2.0 (I had to select that as the more performant 3.0 was 
the only port able to power another mechanical USB seagate 
drive. The SSD worked also in a dupe hub in parallel with 
the mouse, it seem to consume very little)

> 
> During that time, it's possible the task cannot
> be killed, because it's still in a kernel call.

I never wanted to kill anything actually
I used the command KILL as I had the impression it could 
also deliver other signals.

Dan Purgert is underlying  that I had mistyped the signal 
itself (I dunno the expected behaviour when sending unknown 
signals). Actually I had found them in a web page (saying 
kill would accept both numerical values and some spell variants)

> 
> Another thing that might matter, is whether the
> port is in an IDE mode or an AHCI mode.

dunno. It's a case converting the SATA interface in an USB, 
and I connected to a 2.0 port.
The partitions were unmounted (well ... it is still copying 
in the other room, I hope the cats will let it work without 
incidents, the CD-ROOM from time to time awakes for no 
particular reasons and the lights blink ... and the table is 
very low :) but my cats are normally very well behaved)

> With AHCI,
> there is effectively disconnect/reselect, like in
> SCSI. Commands are tagged. You can "kick off" a
> command, and the command comes back when it is
> good and ready. This means the process should not
> be blocked on I/O, because an event will be raised
> to it when the I/O eventually comes back (it
> either worked or it threw an error).

well, I avoided to specify some blocking or non blocking, 
sync or non sync options in "dd" in doubt, leaving the defaults


> 
> When "dd" won't respond,

but is it true it did not respond ?
I mean, a message sent to its parent process (terminal) was 
really the correct procedure to have it received by the child ?
After that, without window, I was no longer able to 
communicate with dd (the commands suggested by Carlos were 
unknown to me)

> that hints to me that
> the disk drive is bad. 

no no, its very recent and used for just 9 months. I am 
trying to clone it because it had a working system 
preconfigured and I had doubled the size of SSD (the "old" 
one was 500 GB, now I have put in one of 1 TB, always SSD).

I hope later GPArted would be able to expand the partition 
and to restore the previous UUID with tune2fs

> And you should be using
> package "gddrescue" and the ddrescue executable
> instead.
> 
>     man ddrescue

I'll wait for dd to exit and if it logs some error on stderr.
Might the copy meet read errors SILENTLY too ? I hope not 
.... And I also hope it would not simply abort, in case, but 
print a msg and try to put forth

> 
> I think ddrescue can be faster, because it

ah to clone also ?

I submit some more options

I got the total number of sectors from GParted (from the 
source drive, the one of 500 GB in size) and found the 
maximum block fitting exactly in the partition size was 2 MB 
(2*1024*1024) so I set the block size to 2 MB and count to 
the total size divided 2 MB.
The target drive is larger.
Was it effective in your opinion ?
I'd have preferred to read 16 MB blocks, but then it would 
have read beyond the physical end at last read, or I'd have 
had to split the command in two and calculate the offset of 
the second "dd" ... a bit complex to try for me

> can dynamically adjust the block size for
> best transfer rate (but only on the good parts
> of the disk -- sectors that are bad, are always
> as slow to resolve, no matter what).
> 
>     Paul


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

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

#57108

On 22/06/2019 00.23, Soviet_Mario wrote:
> Il 21/06/19 21:14, Paul ha scritto:
>> Soviet_Mario wrote:

> the disk is a SSD encased in a box and connected to a slow USB 2.0 (I 
> had to select that as the more performant 3.0 was the only port able to 
> power another mechanical USB seagate drive. The SSD worked also in a 
> dupe hub in parallel with the mouse, it seem to consume very little)

Don't matter how fast your SSD, it's that slow USB 2.0 disk which 
decides how long time it will take and also having two dd running at the 
same time will of course cause the USB disk to slow down even more.


>> When "dd" won't respond,
> 
> but is it true it did not respond ?

No, it's not true, you just killed the process from where you started it 
without it killed the child.


> I mean, a message sent to its parent process (terminal) was really the 
> correct procedure to have it received by the child ?

Not necessarily the parent tells anything to the child, to be sure you 
have to look at the source code of the terminal and also the code of dd 
as it can ignore signals too.


>> And you should be using
>> package "gddrescue" and the ddrescue executable
>> instead.
>>
>>     man ddrescue
>>
>> I think ddrescue can be faster, because it
> 
> ah to clone also ?

It's a dd like tool which is more forgiving if your hard drive has 
errors, it writes an empty block if it can't read a block, while dd may 
get stuck on the block or exit.



On 22/06/2019 00.02, Soviet_Mario wrote:
 > Il 21/06/19 20:26, Carlos E.R. ha scritto:

 >> killall dd
 > but kill can also send signals by process name besides by PID ?

No, it's the killall takes a name and it will kill all processes with 
that name, if you had 10 dd running, it would kill them all.

A thing you must keep in mind, Unix has a killall command too, but it 
does what it says, kills all processes, so be careful with that one if 
you are unsure about if you use Linux or Unix.


-- 
   //Aho

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

#57143

In article <gn64toFjchtU1@mid.individual.net>,
J.O. Aho <user@example.net> wrote:
...
> >> killall dd
> > but kill can also send signals by process name besides by PID ?
>
>No, it's the killall takes a name and it will kill all processes with 
>that name, if you had 10 dd running, it would kill them all.

This is the usual risk with "killall" - that you might kill processes other
than the one you are actually interested in.

However, in this case, the risk is pretty much irrelevant, because we are
sending specifically the USR1 signal, specifically to "dd" processes (of
which there could in theory, though unlikely in practice, be more than one
of) which is documented as being a supported action.  I.e., "dd" is
documented as catching the USR1 signal and displaying a status report upon
receipt of this signal.  This is a pretty innocuous thing for it to do.

Therefore, there's no real risk of something bad happening.  At worst,
unrelated "dd" processes may display their status.

-- 
I love the poorly educated.

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

#57149

On 22/06/2019 21.13, Kenny McCormack wrote:
> In article <gn64toFjchtU1@mid.individual.net>,
> J.O. Aho <user@example.net> wrote:
> ...
>>>> killall dd
>>> but kill can also send signals by process name besides by PID ?
>>
>> No, it's the killall takes a name and it will kill all processes with
>> that name, if you had 10 dd running, it would kill them all.
> 
> This is the usual risk with "killall" - that you might kill processes other
> than the one you are actually interested in.
> 
> However, in this case, the risk is pretty much irrelevant, because we are
> sending specifically the USR1 signal, specifically to "dd" processes (of
> which there could in theory, though unlikely in practice, be more than one
> of) which is documented as being a supported action.  I.e., "dd" is
> documented as catching the USR1 signal and displaying a status report upon
> receipt of this signal.  This is a pretty innocuous thing for it to do.
> 
> Therefore, there's no real risk of something bad happening.  At worst,
> unrelated "dd" processes may display their status.

The risk is mainly if you switch to an Unix system, killall literally 
means kill all processes, not like in Linux where it means send a 
process signal to a subset of processes.

-- 

  //Aho

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

#57112

On 22/06/2019 00.23, Soviet_Mario wrote:
> Il 21/06/19 21:14, Paul ha scritto:
>> Soviet_Mario wrote:


>> I think ddrescue can be faster, because it
> 
> ah to clone also ?

If you use dd with the default block size, yes. But its main use is if
you fear there might be damaged sectors. Or "just in case", because if
it is the case that there are bad sectors and you did not know, you'd
have to abort dd and restart with dd*rescue (there are two variants at
least).

> 
> I submit some more options
> 
> I got the total number of sectors from GParted (from the source drive,
> the one of 500 GB in size) and found the maximum block fitting exactly
> in the partition size was 2 MB (2*1024*1024) so I set the block size to
> 2 MB and count to the total size divided 2 MB.

You do not have to specify a size to dd when cloning a disk or
partition: it will simply stop at the end with a message that there is
no more data. I think it complains of error, but you know what it is, so
no prob.

What you have to do is assign a big "enough" chunk size. Yes, 16 MB or a
hundred is just fine, see above :-)

If the chunk is the default 512 it goes too slow. Too big and the
machine goes out of ram (and swaps). But yes, otherwise you can say "10
GB chunk".

(yes, dd with a big chunk can be used as a trick to create used ram for
a while)

> The target drive is larger.
> Was it effective in your opinion ?
> I'd have preferred to read 16 MB blocks, but then it would have read
> beyond the physical end at last read, or I'd have had to split the
> command in two and calculate the offset of the second "dd" ... a bit
> complex to try for me

Bah, no calculations needed :-)


-- 
Cheers, Carlos.

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

#57086

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

dd don't output until it's finished.

> 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).

The terminal ain't the same as dd, you should have sent the signal to dd 
instead.

pidof dd

woudl have given you all the pid's of running dd's on your system.


> 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 then you get the terminal react on the kill, not dd, it's like you 
are supposed to slice a piece of an apple but instead you slice a piece 
of the orange.


> 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).

You can still kill the process, just give the right pid.



> 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 ....

If you want to see the ps output nested, then use the f flag, but as you 
already know which program you want to affect, then pidof is faster to use.

-- 

  //Aho

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

#57095

Il 21/06/19 21:39, J.O. Aho ha scritto:
> 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
> 
> dd don't output until it's finished.
> 
>> 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).
> 
> The terminal ain't the same as dd, you should have sent the 
> signal to dd instead.

mmm, I was afraid so :\

> 
> pidof dd

this is the cmq I lacked ...

> 
> woudl have given you all the pid's of running dd's on your 
> system.

I'll launch one at a time, not to be insecure which is who :)

> 
> 
>> 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 then you get the terminal react on the kill, not dd, 

yes ... as I feared. I did it not having another PID, and 
hoping a non recognized signal could be ignored if 
mis-addressed.

I'll try to keep in mind of PIDOF !

ah ... the spell USR1 vs SIGUSR1 is really that relevant ? I 
read a webpage saying some alternate spells were supported 
(but I did not care to understand if the information might 
be distro-specific or so)

> it's like you are supposed to slice a piece of an apple but 
> instead you slice a piece of the orange.
> 
> 
>> 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).
> 
> You can still kill the process, just give the right pid.


mmm, now it's more difficult ! I have queued (overlapping) 
another dd instance. Can I rely on the fact that the highest 
PID is assigned to the later of the two ?

> 
> 
> 
>> 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 ....
> 
> If you want to see the ps output nested, 

ehm ... I don't know what you are talking about. I was 
referring to the window of Process Monitor/Manager.
In XFCE version (I suspect it uses GNOME sw) on debian the 
processes can be shown in TREE-like style (and also the 
command line is shown).
But There I was using the live MX distro and the installed 
SW seems more skinny and poor of subtleties

> then use the f 
> flag, but as you already know which program you want to 
> affect, then pidof is faster to use.
> 

I promise I'll try to understand "PS" :\

thanks


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

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

#57107

On 22/06/2019 00.33, Soviet_Mario wrote:
> Il 21/06/19 21:39, J.O. Aho ha scritto:
>> 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
>>
>> dd don't output until it's finished.
>>
>>> 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).
>>
>> The terminal ain't the same as dd, you should have sent the signal to 
>> dd instead.
> 
> mmm, I was afraid so :\
> 
>>
>> pidof dd
> 
> this is the cmq I lacked ...

This command is part of the same package as ps, both provided by procps 
and is part of default installed packages in most distributions except 
embedded ones where they may or may not use busybox instead.


>>> 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 then you get the terminal react on the kill, not dd, 
> 
> yes ... as I feared. I did it not having another PID, and hoping a non 
> recognized signal could be ignored if mis-addressed.
> 
> I'll try to keep in mind of PIDOF !
> 
> ah ... the spell USR1 vs SIGUSR1 is really that relevant ? I read a 
> webpage saying some alternate spells were supported (but I did not care 
> to understand if the information might be distro-specific or so)

Alternative spelling can be version depending, so yes it's important to 
check what yours support like "man kill" can be a good thing to do before.


>>> 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).
>>
>> You can still kill the process, just give the right pid.
> 
> 
> mmm, now it's more difficult ! I have queued (overlapping) another dd 
> instance. Can I rely on the fact that the highest PID is assigned to the 
> later of the two ?

No, with traditional pid numbering, the pid's do start over after a 
while and with the random pid numbering it's quite random, so it's 
better to use the ps u flag, so you get the start time.


>>> 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 
>>> ....
>>
>> If you want to see the ps output nested, then use the f flag
> 
> ehm ... I don't know what you are talking about. I was referring to the 
> window of Process Monitor/Manager.
> In XFCE version (I suspect it uses GNOME sw) on debian the processes can 
> be shown in TREE-like style (and also the command line is shown).
> But There I was using the live MX distro and the installed SW seems more 
> skinny and poor of subtleties

Not my fault you don't use the power tool but some poor GUI tool.


-- 

  //Aho

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

#57114

On 22/06/2019 00.33, Soviet_Mario wrote:
> Il 21/06/19 21:39, J.O. Aho ha scritto:


>> If you want to see the ps output nested, 
> 
> ehm ... I don't know what you are talking about. I was referring to the
> window of Process Monitor/Manager.
> In XFCE version (I suspect it uses GNOME sw) on debian the processes can
> be shown in TREE-like style (and also the command line is shown).
> But There I was using the live MX distro and the installed SW seems more
> skinny and poor of subtleties
> 
>> then use the f flag, but as you already know which program you want to
>> affect, then pidof is faster to use.
>>
> 
> I promise I'll try to understand "PS" :\

I mentioned the 'f' in my post as well. Try:

ps afx | less

And notice that "PS" is another thing that also exists.

-- 
Cheers, Carlos.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web