[opensuse] Get PID of a process
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Is it possible to get the PID of the previous command launched and finished? Example: fetchmail .... echo "Posible PID of fetchmail was: $!" Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlp/ZCUACgkQtTMYHG2NR9XnTQCdEx4nCiKSrlXp4nxex2ZZ40qT X68An3AzvKXwHgdSYUgyjvX+wOiJzpHn =fAsV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/10/2018 10:29 PM, Carlos E. R. wrote:
Is it possible to get the PID of the previous command launched and finished?
Example:
fetchmail .... echo "Posible PID of fetchmail was: $!"
Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want.
The crucial term for "$!" is: "background process". You send a process to background if you start it with "&" a the end. $ sleep 60 & $ echo $! 14100 So if you need the PID of the previously launched and finished process (whatever this may be good for), then you could e.g. do: sleep 10 & # send process to background pid=$! # get its PID wait $pid # wait for the process to terminate rc=$? # get the exit status of the process echo "PID: $pid, exit status: $rc" Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-10 22:36, Bernhard Voelker wrote:
On 02/10/2018 10:29 PM, Carlos E. R. wrote:
Is it possible to get the PID of the previous command launched and finished?
Example:
fetchmail .... echo "Posible PID of fetchmail was: $!"
Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want.
The crucial term for "$!" is: "background process".
Yes.
You send a process to background if you start it with "&" a the end.
Yes, I know.
$ sleep 60 &
$ echo $! 14100
So if you need the PID of the previously launched and finished process (whatever this may be good for),
To be able to read all it did in its log entries, differentiating from other instances that had a different PID (and some running at the same time, concurrently, so I can not simply "tail -f" the log).
then you could e.g. do:
sleep 10 & # send process to background pid=$! # get its PID wait $pid # wait for the process to terminate rc=$? # get the exit status of the process echo "PID: $pid, exit status: $rc"
Ah, interesting, thanks. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-10 at 22:45 +0100, Carlos E. R. wrote:
On 2018-02-10 22:36, Bernhard Voelker wrote:
On 02/10/2018 10:29 PM, Carlos E. R. wrote:
Is it possible to get the PID of the previous command launched and finished?
Example:
fetchmail .... echo "Posible PID of fetchmail was: $!"
Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want.
The crucial term for "$!" is: "background process".
Yes.
You send a process to background if you start it with "&" a the end.
Yes, I know.
$ sleep 60 &
$ echo $! 14100
So if you need the PID of the previously launched and finished process (whatever this may be good for),
To be able to read all it did in its log entries, differentiating from other instances that had a different PID (and some running at the same time, concurrently, so I can not simply "tail -f" the log).
then you could e.g. do:
sleep 10 & # send process to background pid=$! # get its PID wait $pid # wait for the process to terminate rc=$? # get the exit status of the process echo "PID: $pid, exit status: $rc"
Ah, interesting, thanks.
It is working perfectly! :-) I'm using this code (simplified): fetchmail -v ... & local PID=$! echo "Posible PID of fetchmail $CUAL was: $PID" wait grep fetchmail /var/log/mail | grep $PID | grep "message.*for .* at .*" | cut -d" " -f6- And I get at the end of each run output like this: Posible PID of fetchmail was: 27355 27355 - - 5 messages for my.idename at imap.server.net (folder Inbox). The real code is more complex, because I launch concurrently two fetchmail processes, and there is more debug output. As there are two fetchmail processes, I need to know the PID in order to identify the log entries pertaining to each process. What I get is not the number of fetched emails, but how many are in the folder. There is no single line in fetchmail output that says how many were actually fetched, I would have to parse the output and sum many lines. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlp/lXUACgkQtTMYHG2NR9VYtQCeP33pxamfsEry3HnOOoi3Wov0 E6MAn2sQSRZ8pHyHlVbdN9EVdwVqrwzF =vwMM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/18 04:29 PM, Carlos E. R. wrote:
Hi,
Is it possible to get the PID of the previous command launched and finished?
Example:
fetchmail .... echo "Posible PID of fetchmail was: $!"
Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want.
I don't think this is a good example for reasons of reproducibility. I use KDE to run bash in Konsole and have it set to start fetchmail when I log in, so if I run that command I get anton@main:~> fetchmail & [1] 4170 anton@main:~> fetchmail: background fetchmail at 4032 awakened. [1]+ Done fetchmail or more simply anton@main:~> fetchmail fetchmail: background fetchmail at 4032 awakened. OK, so I stop fetchmail anton@main:~> fetchmail -q fetchmail: background fetchmail at 4032 killed. but when I restart it, even in the foreground, it goes into the background anton@main:~> fetchmail anton@main:~> Why? Because I have that set in my .fetchmailrc: anton@main:~> more .fetchmailrc # Configuration created Sun Feb 2 23:30:38 2014 by fetchmailconf 1.57 set syslog set postmaster "anton" set bouncemail set softbounce ---> set daemon 600 set invisible And while looking for that I find that there is also ~anton/.fetchmail.pid But Oh, Wait, a LOT of programs that go into the background. We need on that doesn't What's very basic... ah right, 'cat' is pretty harmless so long as you pay attention to Rob Pike: anton@main:~> cat - - & [1] 4068 What? The shell has just told us what the PID is. And more anton@main:~> jobs [1]+ Stopped cat - - can we get more info on backgrounded jobs on BASH? he man page says we can; it has a lot of references to handling jobs in the background anton@main:~> jobs -l [1]+ 4068 Stopped (tty input) cat - - I don't know if this is really an answer. I'm not sure what the real problem is. Although this is RTFM solution above, it was one of those things that was sitting in the back of my head though I've never had occasion to use it, sort of like how to change the barrel on a 105 howitzer in the field or navigate using a quadrant and compass. Lots and lot of garbage that I'll never have occasion to use. Like using MS-Windows ... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (note: I have my script now doing what I wanted, the issue is solved). On Sunday, 2018-02-11 at 09:01 -0500, Anton Aylward wrote:
On 10/02/18 04:29 PM, Carlos E. R. wrote:
Hi,
Is it possible to get the PID of the previous command launched and finished?
Example:
fetchmail .... echo "Posible PID of fetchmail was: $!"
Well, the value I get I know it was not the PID. The documentation says that "$!" gets the PID of the previously backgrounded process, so it is not what I want.
I don't think this is a good example for reasons of reproducibility.
Ah, OK I see your point. fetchmail is somewhat special, it can run as daemon. But it happens to be the program I'm interested in ;-) I call it manually, not as daemon.
And while looking for that I find that there is also ~anton/.fetchmail.pid
Ah, I will have to check if it exists in my system when I run fetchmail. [...] No, it doesn't.
But Oh, Wait, a LOT of programs that go into the background. We need on that doesn't What's very basic... ah right, 'cat' is pretty harmless so long as you pay attention to Rob Pike:
anton@main:~> cat - - & [1] 4068
What? The shell has just told us what the PID is. And more
Yes, but I needed that info in a script (note: I have my script now doing what I wanted, the issue is solved - see the rest of the thread).
anton@main:~> jobs [1]+ Stopped cat - -
can we get more info on backgrounded jobs on BASH? he man page says we can; it has a lot of references to handling jobs in the background
anton@main:~> jobs -l [1]+ 4068 Stopped (tty input) cat - -
I don't know if this is really an answer. I'm not sure what the real problem is. Although this is RTFM solution above, it was one of those things that was sitting in the back of my head though I've never had occasion to use it, sort of like how to change the barrel on a 105 howitzer in the field or navigate using a quadrant and compass. Lots and lot of garbage that I'll never have occasion to use. Like using MS-Windows ...
You can see that in the rest of the thread. I wanted, and I got it done, to parse the fetchmail log from only a particular manual session. And as i run two concurrent fetchmails, I had to differentiate each one by its PID. I can post the entire script if you are interested. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqAyZMACgkQtTMYHG2NR9WCygCdGOVUcBXtQI5Omb9Jjcx2zeBA HoMAmgInbX0y6TJisU/YG9wZ5bcgpsad =bzkh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/02/18 05:54 PM, Carlos E. R. wrote:
You can see that in the rest of the thread. I wanted, and I got it done, to parse the fetchmail log from only a particular manual session. And as i run two concurrent fetchmails, I had to differentiate each one by its PID.
I can post the entire script if you are interested.
Actually I'm more curious as to why you need to run two separate fetchmail processes. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-13 03:50, Anton Aylward wrote:
On 11/02/18 05:54 PM, Carlos E. R. wrote:
You can see that in the rest of the thread. I wanted, and I got it done, to parse the fetchmail log from only a particular manual session. And as i run two concurrent fetchmails, I had to differentiate each one by its PID.
I can post the entire script if you are interested.
Actually I'm more curious as to why you need to run two separate fetchmail processes.
Speed. One process fetches from gmail, which is an slow imap server, and another fetches from the rest, that are faster. Speed is more important when I don't have fetchmail running in a time loop, but manually when I want it. Another reason would be a busy server, fetching from hundreds of accounts. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 13/02/18 03:02 AM, Carlos E. R. wrote:
On 2018-02-13 03:50, Anton Aylward wrote:
On 11/02/18 05:54 PM, Carlos E. R. wrote:
You can see that in the rest of the thread. I wanted, and I got it done, to parse the fetchmail log from only a particular manual session. And as i run two concurrent fetchmails, I had to differentiate each one by its PID.
I can post the entire script if you are interested.
Well, I look at the man page for fetchmail and I see you can not only specify the config file on the command line but also the pid file.
Actually I'm more curious as to why you need to run two separate fetchmail processes.
Speed.
Ah. I'm still dubious.
One process fetches from gmail, which is an slow imap server, and another fetches from the rest, that are faster.
I use Thunderbird as my front end. It deals with about 40+ accounts. Almost all of my accounts, and that includes GMail -- which seems to be an obligatory account these days even if you don't use it very much -- are imap based. The one exception is a very old and very critical service at a server that deals only with POP. That, and that alone, I apply fetchmail on. Fetchmail pulls stuff from that old account, runs SpamAssassin -- since its been around for decades it has appeared on many spam distributions by now -- pushes the email through procmail which puts it into disk folders. LOTS OF THEM. I then run Dovecot locally and point it at those folders. Thunderbird runs imap to to talk to Dovecot. So Thunderbird run imap and imap only The overall strategy was to make the remote accounts do the work of email storage, I only download very specific mail items that I want to archive. They go into folders serviced by Doevcot. Speed? I never have problems with speed. Very occasionally I'll wake up the fetchmail daemon from its ten minute cycle.
Speed is more important when I don't have fetchmail running in a time loop, but manually when I want it.
That makes no sense to me. I'd have it running as a deamon with, perhaps, a shorter cycle, perhaps, or a longer cycle. The idea is 'don't forget to fetch mail'. If I need more urgency I can wake it up manually.
Another reason would be a busy server, fetching from hundreds of accounts.
That's not a problem for me. As I said, I run the accounts using imap; Thunderbird polls and the imao protocol indicates if there is any new mail without needing to fetch it. See https://busylog.net/telnet-imap-commands-note/#24 To be honest, Thunderbird doesn't give me the fine tuned imap access that is possible, but then I don't feel like writing my own MUA. Good enough for me. Oh, and there's also the IDLE command. Does Thunderbird use that? If your IMAP server supports that you don't have to manually check for new mail or have Thunderbird poll for new mail every x minutes. https://support.mozilla.org/en-US/questions/1115907 Yes, I see that my version does and I have it set on all my imap accounts. including Gmail. So, yes, I take a more hands-off approach . I'm one of the school of sysadmins who are lazy, make the software do the work without having to do the 'fiddly-bits'. I look at what you've described and blink and wonder why there isn't "one fetchmail process for each account". I just seems like too much work to me, which is why you you asked this question anyway. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-13 15:48, Anton Aylward wrote:
On 13/02/18 03:02 AM, Carlos E. R. wrote:
On 2018-02-13 03:50, Anton Aylward wrote:
On 11/02/18 05:54 PM, Carlos E. R. wrote:
You can see that in the rest of the thread. I wanted, and I got it done, to parse the fetchmail log from only a particular manual session. And as i run two concurrent fetchmails, I had to differentiate each one by its PID.
I can post the entire script if you are interested.
Well, I look at the man page for fetchmail and I see you can not only specify the config file on the command line but also the pid file.
--pidfile <pathname> (Keyword: pidfile; since fetchmail v6.3.4) Override the default location of the PID file. Default: see "ENVIRONMENT" below. I do change the environment (FETCHMAILHOME), it is a "must do" when two or more fetchmail processes run in parallel under the same user. The default PID file should be there but it is not - thus I think it is not created when it doesn't run as daemon.
Actually I'm more curious as to why you need to run two separate fetchmail processes.
Speed.
Ah. I'm still dubious.
One process fetches from gmail, which is an slow imap server, and another fetches from the rest, that are faster.
I use Thunderbird as my front end. It deals with about 40+ accounts. Almost all of my accounts, and that includes GMail -- which seems to be an obligatory account these days even if you don't use it very much -- are imap based. The one exception is a very old and very critical service at a server that deals only with POP. That, and that alone, I apply fetchmail on.
Your use case is very different from mine. I use Thunderbird on at least two computers and several partitions to read email from all the accounts, at the ISP. When I can or want I use fetchmail on all the accounts to get all the email into my local dovecot storage. postfix, procmail, spamassassin, amavis... the lot. I may be several days without running fetchmail, so when I do run it, it can be hundreds of accumulated posts on the accounts that get list mail. And why don't I run it before? You will ask. Well, maybe because I'm not home, maybe because I'm running another partition... Depends. I have been reading them at the ISP imap server, but eventually I want them stored locally. When there are hundreds of posts to fetch from Gmail the fact that it runs at half or less the speed of Telefonica means a difference of several minutes. It may be half an hour till I get all the posts "inside", if running a single fetchmail process. With two processes it is about 10 minutes for Telefonica, 20 for gmail. But at least I get the most important accounts fetched in 10 minutes and I do not have to wait for Gmail to finish. You are using fetchmail on a single server. If you were fetching from several servers, you could consider splitting them; but as you are running fetchmail as a daemon in a time loop, your accumulated mail will never be "hundreds". It is not worth for you. Sample run of my script: cer@Telcontar:~> recogercorreo 2018-02-13T17:44:31,179978468+01:00 Launching two fetchmail processes Waiting for the two fetchmail processes to finish 2018-02-13T17:44:31,183166292+01:00 Launching fetchmail B, iteration 1 of 1 2018-02-13T17:44:31,183289200+01:00 Launching fetchmail A, iteration 1 of 3 2018-02-13T17:44:39,518467663+01:00 Done fetchmail A (PID: 17579) iteration 1 of 3 in 8 seconds 17579 - - 1 message for name@server at server. 17579 - - 43 messages for name1 at imap.telefonica.net (folder Inbox). 17579 - - 1 message for name2 at imap.telefonica.net (folder Inbox). 2018-02-13T17:44:39,543875609+01:00 Launching fetchmail A, iteration 2 of 3 2018-02-13T17:44:44,787940786+01:00 Done fetchmail A (PID: 17829) iteration 2 of 3 in 5 seconds 2018-02-13T17:44:44,810844934+01:00 Launching fetchmail A, iteration 3 of 3 2018-02-13T17:44:46,074377192+01:00 Done fetchmail A (PID: 18007) iteration 3 of 3 in 2 seconds Fetchmail A finished 2018-02-13T17:45:08,256223672+01:00 Done fetchmail B (PID: 17578) iteration 1 of 1 in 37 seconds 17578 - - 35 messages for name3 at imap.gmail.com. 17578 - - 1 message for name4 at imap.gmail.com. 17578 - - 1 message for name5 at imap.gmail.com. Fetchmail B finished 2018-02-13T17:45:08,283238627+01:00 All fetchmails processes have finished (in 37 seconds). -- 201 Kbytes in 12 Requests. cer@Telcontar:~> I got from 2 telefonica acounts, and another server account, a total of 45 emails in 8 seconds. I got from 3 gmail accounts, 37 emails in 37 seconds. Do you see the speed difference? In fact, I poll the Telefonica server 3 times while the gmail poll is running. Why 3? Because sometimes the run aborts due to some error at their server. At some period these aborts were very frequent and I had to restart the poll - but I had to wait first for gmail poll to end. I might have got 100 posts from telefonica, have another 200 left, and could not get them because fetchmail was working on 250 from gmail. *That's* when I decided I wanted two processes in parallel.
So, yes, I take a more hands-off approach . I'm one of the school of sysadmins who are lazy, make the software do the work without having to do the 'fiddly-bits'.
I look at what you've described and blink and wonder why there isn't "one fetchmail process for each account". I just seems like too much work to me, which is why you you asked this question anyway.
Obviously I did not start life doing all this. I have added bits and bits over the years. It is one advantage of upgrading, I don't have to set it all again from scratch ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (3)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R.