Re: Changing a running process' cmd name/argv[0]
On 07/15/14 23:55, Philip Guenther wrote: On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. It does not. If you mean daemon() I run it from inside a fork() so the main process never exits. You're making me uncertain so I will check this out better later. So you're saying that the process that the .xinitrc ksh executes calls fork() and the child of that fork() then calls daemon()? If so, what does the *parent* of the fork(), the original process executed by ksh, do after forking? It's child will exit from the daemon() call, so if it calls wait() it won't block long. Then what? Exit? If so, you've created a self-backgrounding process (in a very complicated fashion) which means it cannot be the process that keeps the .xinitrc script from exiting. Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. So let's try that question directly: what process (*not* program) directly executed in the foreground by the .xinitrc script will run and not exit until your X session is complete? The answer CANNOT be the child of this program which fork()s, because it is the original process which matters. Nor can the answer be this program which calls daemon(), because the original process exits then too. Not a process in .xinitrc, .xinitrc itself. This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. You should ask your legal department what they think that means other than we're idiots when attached to messages to archived mailing lists. The legal department knows what a mailing list is. Mails are sent out to consumers, those are the (final) recipients. Philip Guenther -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On 2014/07/16 09:53, Gustav Fransson Nyvell wrote: Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. Do you mean that you have replaced .xinitrc, which is documented as a file that should be a shell script, with binary object code? If so, the solution is obvious. You should ask your legal department what they think that means other than we're idiots when attached to messages to archived mailing lists. The legal department knows what a mailing list is. Mails are sent out to consumers, those are the (final) recipients. The mailing list is sent not just to people, but also gateways, list archives and maybe other strange things. I see no attempt to prevent that (x-no-archive) so perhaps you are in violation of your company's own rules?
Re: Changing a running process' cmd name/argv[0]
On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/15/14 23:55, Philip Guenther wrote: On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. It does not. If you mean daemon() I run it from inside a fork() so the main process never exits. You're making me uncertain so I will check this out better later. So you're saying that the process that the .xinitrc ksh executes calls fork() and the child of that fork() then calls daemon()? If so, what does the *parent* of the fork(), the original process executed by ksh, do after forking? It's child will exit from the daemon() call, so if it calls wait() it won't block long. Then what? Exit? If so, you've created a self-backgrounding process (in a very complicated fashion) which means it cannot be the process that keeps the .xinitrc script from exiting. Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. So let's try that question directly: what process (*not* program) directly executed in the foreground by the .xinitrc script will run and not exit until your X session is complete? The answer CANNOT be the child of this program which fork()s, because it is the original process which matters. Nor can the answer be this program which calls daemon(), because the original process exits then too. Not a process in .xinitrc, .xinitrc itself. I don't understand your answer. Since I apparently cannot guess what you're doing, I'll suggest that you show it, such as by simply including your complete .xinitrc. Philip Guenther
Re: Changing a running process' cmd name/argv[0]
On 07/16/14 10:31, Stuart Henderson wrote: On 2014/07/16 09:53, Gustav Fransson Nyvell wrote: Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. Do you mean that you have replaced .xinitrc, which is documented as a file that should be a shell script, with binary object code? If so, the solution is obvious. No, I've patched /usr/src/bin/ksh. You should ask your legal department what they think that means other than we're idiots when attached to messages to archived mailing lists. The legal department knows what a mailing list is. Mails are sent out to consumers, those are the (final) recipients. The mailing list is sent not just to people, but also gateways, list archives and maybe other strange things. I see no attempt to prevent that (x-no-archive) so perhaps you are in violation of your company's own rules? Of course computer system recipients may archive as do human brains when they receive an e-mail, I guess. It's brief, I know, the point is to prevent abuse and NSA-like surveillance. Third party ... eyes. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On 07/16/14 10:31, Philip Guenther wrote: On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: On 07/15/14 23:55, Philip Guenther wrote: On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. It does not. If you mean daemon() I run it from inside a fork() so the main process never exits. You're making me uncertain so I will check this out better later. So you're saying that the process that the .xinitrc ksh executes calls fork() and the child of that fork() then calls daemon()? If so, what does the *parent* of the fork(), the original process executed by ksh, do after forking? It's child will exit from the daemon() call, so if it calls wait() it won't block long. Then what? Exit? If so, you've created a self-backgrounding process (in a very complicated fashion) which means it cannot be the process that keeps the .xinitrc script from exiting. Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. So let's try that question directly: what process (*not* program) directly executed in the foreground by the .xinitrc script will run and not exit until your X session is complete? The answer CANNOT be the child of this program which fork()s, because it is the original process which matters. Nor can the answer be this program which calls daemon(), because the original process exits then too. Not a process in .xinitrc, .xinitrc itself. I don't understand your answer. Since I apparently cannot guess what you're doing, I'll suggest that you show it, such as by simply including your complete .xinitrc. Philip Guenther couth. ~$ cat .xinitrc urxvtd -o xrdb ~/.Xresources echo $$ exec wmaker -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On Wed, Jul 16, 2014 at 3:45 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/16/14 10:31, Philip Guenther wrote: On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/15/14 23:55, Philip Guenther wrote: ... So let's try that question directly: what process (*not* program) directly executed in the foreground by the .xinitrc script will run and not exit until your X session is complete? The answer CANNOT be the child of this program which fork()s, because it is the original process which matters. Nor can the answer be this program which calls daemon(), because the original process exits then too. Not a process in .xinitrc, .xinitrc itself. I don't understand your answer. Since I apparently cannot guess what you're doing, I'll suggest that you show it, such as by simply including your complete .xinitrc. couth. ~$ cat .xinitrc urxvtd -o xrdb ~/.Xresources echo $$ exec wmaker So the process which is run and that doesn't exit until your X session is complete is the process that started as .xinitrc but then execed wmaker. At that point, there should be no process executing the .xinitrc script at all, as it has execed something else. Since you exec'ed wmaker instead of running it in the foreground, the urxvtd process will be a child process of wmaker. If that's confusing wmaker, then just stop using exec. No, I've patched /usr/src/bin/ksh. I suggest you copy the source and install your modified version under some other name, so that you can be confident that your changes aren't the source of questions you're asking on the lists. We can't support Gustav-ksh. Oh, I see, that's exactly what's happened: you've hacked ksh to call a library that forks and your .xinitrc stopped working as a result. Doctor, it hurts when I poke myself with a fork() So don't do that! Philip Guenther
Re: Changing a running process' cmd name/argv[0]
Oh, I see, that's exactly what's happened: you've hacked ksh to call a library that forks and your .xinitrc stopped working as a result. Doctor, it hurts when I poke myself with a fork() So don't do that! Philip Guenther No wonder you don't have time to code. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On Wed, Jul 16, 2014 at 4:26 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: Oh, I see, that's exactly what's happened: you've hacked ksh to call a library that forks and your .xinitrc stopped working as a result. Doctor, it hurts when I poke myself with a fork() So don't do that! No wonder you don't have time to code. You know, you're right: I should have spent this time writing up my hackathon report. I hope you find a solution to your problem. Philip Guenther
Re: Changing a running process' cmd name/argv[0]
On Mon, Jul 14, 2014 at 1:52 PM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/14/14 09:42, Philip Guenther wrote: On Mon, Jul 14, 2014 at 4:25 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: I'm looking at 5.5-current. I'm forking inside a lib and I want to change the forks cmd or argv[0]. I mean, what you see as command in ps or top. I've looked at setproctitle. There are two different things that ps will display with a title command: the args format and the ucomm format. The former is used by ps -u and ps -l and can be modified by setproctitle(). The latter is the final path component of the argv[0] passed to execve and can only be modified by exec. I see, too bad. Any plans on making it possible? kvm_setargv? No. Since it has doesn't appear to be related to the problem you're experiencing, I don't know why you ask. I've gotten a dozen questions why I'm doing this and the reason is X runs my lib or a program that runs my lib and thus gets fork, which it can't handle. I think this is because it has the same command name (probably not.) Thus gets fork? What does that mean? What is the actual error that occurs? Well, it gets a forked child on it's hand, which it wasn't expecting. Sorry, I read a lot of poetry. When I run startx from the login shell after boot (no xdm etc) X starts up with a frozen cursor and sort of overlays the background with itself, it looks weird. Or it flicks and then goes back to console with dots . . . until it goes back to the prompt. I looked at what happens when ksh (which uses my lib) runs .xinitrc and it gets 3 children (my assertion.) All but the original will die. Does this confuse X11 to think that .xinitrc yielded or ended and thus shut down the session? (As it does if you don't exec mywm on the last line on .xinitrc.) When the process that's executing your .xinitrc exits, startx/xinit will shutdown the X server and then itself exit, taking you back to the non-X shell prompt. Your .xinitrc should end with execution on some program which will not exit until you want to exit X; many people have it be their window manager. This is described in the startx(1) manpage: The .xinitrc is typically a shell script which starts many clients according to the user's preference. When this shell script exits, startx kills the server and performs any other session shutdown needed. Most of the clients started by .xinitrc should be run in the background. The last client should run in the foreground; when it exits, the session will exit. People often choose a session manager, window manager, or xterm as the ''magic'' client. Since I don't understand what problem you are trying to solve by double forking or using daemon(), I cannot comment on those. Philip Guenther
Re: Changing a running process' cmd name/argv[0]
On 07/15/14 09:48, Philip Guenther wrote: When the process that's executing your .xinitrc exits, startx/xinit will shutdown the X server and then itself exit, taking you back to the non-X shell prompt. Your .xinitrc should end with execution on some program which will not exit until you want to exit X; many people have it be their window manager. This is described in the startx(1) manpage: The .xinitrc is typically a shell script which starts many clients according to the user's preference. When this shell script exits, startx kills the server and performs any other session shutdown needed. Most of the clients started by .xinitrc should be run in the background. The last client should run in the foreground; when it exits, the session will exit. People often choose a session manager, window manager, or xterm as the ''magic'' client. I know all of this. The problem is why does X lose .xinitrc when .xinitrc (ksh) forks. Since I don't understand what problem you are trying to solve by double forking or using daemon(), I cannot comment on those. To yield from a call and let the call run in the background. Philip Guenther -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. :Since I don't understand what problem you are trying to solve by :double forking or using daemon(), I cannot comment on those. :To yield from a call and let the call run in the background. you can't let it run in the background. it MUST run in the foreground : : :Philip Guenther : : : :-- :This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. : -- A truly wise man never plays leapfrog with a unicorn.
Re: Changing a running process' cmd name/argv[0]
On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. It does not. If you mean daemon() I run it from inside a fork() so the main process never exits. You're making me uncertain so I will check this out better later. :Since I don't understand what problem you are trying to solve by :double forking or using daemon(), I cannot comment on those. :To yield from a call and let the call run in the background. you can't let it run in the background. it MUST run in the foreground ksh keeps running in the foreground but it spawns children which with daemon() tries to branch off (can't find the right word) and run in the background. So the first ksh that's running .xinitrc never dies and never goes into background. I'll probably dig around the X code later. : : :Philip Guenther : : : :-- :This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. : -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Changing a running process' cmd name/argv[0]
On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:48, Philip Guenther wrote: :When the process that's executing your .xinitrc exits, startx/xinit :will shutdown the X server and then itself exit, taking you back to :the non-X shell prompt. Your .xinitrc should end with execution on :some program which will not exit until you want to exit X; many :people have it be their window manager. : :This is described in the startx(1) manpage: : The .xinitrc is typically a shell script which starts many clients : according to the user's preference. When this shell script exits, : startx kills the server and performs any other session :shutdown needed. : Most of the clients started by .xinitrc should be run in the : background. The last client should run in the foreground; when it : exits, the session will exit. People often choose a session :manager, : window manager, or xterm as the ''magic'' client. : :I know all of this. The problem is why does X lose .xinitrc when :.xinitrc (ksh) forks. : because the process you called stopped running. It does not. If you mean daemon() I run it from inside a fork() so the main process never exits. You're making me uncertain so I will check this out better later. So you're saying that the process that the .xinitrc ksh executes calls fork() and the child of that fork() then calls daemon()? If so, what does the *parent* of the fork(), the original process executed by ksh, do after forking? It's child will exit from the daemon() call, so if it calls wait() it won't block long. Then what? Exit? If so, you've created a self-backgrounding process (in a very complicated fashion) which means it cannot be the process that keeps the .xinitrc script from exiting. So let's try that question directly: what process (*not* program) directly executed in the foreground by the .xinitrc script will run and not exit until your X session is complete? The answer CANNOT be the child of this program which fork()s, because it is the original process which matters. Nor can the answer be this program which calls daemon(), because the original process exits then too. This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. You should ask your legal department what they think that means other than we're idiots when attached to messages to archived mailing lists. Philip Guenther
Re: Changing a running process' cmd name/argv[0]
On Mon, Jul 14, 2014 at 4:25 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: I'm looking at 5.5-current. I'm forking inside a lib and I want to change the forks cmd or argv[0]. I mean, what you see as command in ps or top. I've looked at setproctitle. There are two different things that ps will display with a title command: the args format and the ucomm format. The former is used by ps -u and ps -l and can be modified by setproctitle(). The latter is the final path component of the argv[0] passed to execve and can only be modified by exec. I've gotten a dozen questions why I'm doing this and the reason is X runs my lib or a program that runs my lib and thus gets fork, which it can't handle. I think this is because it has the same command name (probably not.) Thus gets fork? What does that mean? What is the actual error that occurs? Philip Guenther
Changing a running process' cmd name/argv[0]
Hi, Bit of a programming question/inquiry... I'm looking at 5.5-current. I'm forking inside a lib and I want to change the forks cmd or argv[0]. I mean, what you see as command in ps or top. I've looked at setproctitle. And I lurked around kvm_getprocs and kvm_getargv, but these functions only give readable data, nothing can be changed, correct? I've gotten a dozen questions why I'm doing this and the reason is X runs my lib or a program that runs my lib and thus gets fork, which it can't handle. I think this is because it has the same command name (probably not.) What I really want to do is a double fork, as you say... I want to fork and completely disconnect the child from the parent so it's just gone without a trace for anything anywhere to see, capisce? I've tried using daemon(3) for this and yes, it disconnects it but then this new problem with X appeared. It's a little hard to follow maybe... It seems like in this area there is something of a lack of API in the kernel. I haven't researched double fork but I suspect it's most likely daemon(3) being used. If you understand what I've written then any suggestions are welcome. Thanks. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Don't get funny with me.
