* runit pblms on Mandrake @ 2003-07-17 3:10 Karthik M 2003-07-17 6:00 ` Hleil Liu 0 siblings, 1 reply; 24+ messages in thread From: Karthik M @ 2003-07-17 3:10 UTC (permalink / raw) Hello everyone, I am trying to install runit-0.10.0 on Mandrake 9.0. I was facing initial compilation pblms which Gerrit solved it and referred to this mailing list. I saw thru the archives that Hleil Liu has runit-0.10.0 running on a red-hat system. I followed his clearly outlined steps for redhat 7.2. I have daemontools running without any pblms on my system. The first pblm i faced was after i rebooted the system after performing: #mv /sbin/init /sbin/init.sysv #ln -s /sbin/runit-init /sbin/init I got an error message that : ..... "the file runit cannot be found " Kernel panic: ..... Should i copy over all the binaries of runit over to /sbin ?? The i modified the symlink to : #ln -s /sbin/runit /sbin/init [instead of runit-init] The i was able to boot the system and booted fine until: /et/runit: entering stage 2 at which stage it frooze and i did not get a login prompt at all. my /etc/runit/2 is : ------snip------- #!/bin/sh PATH=/command:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin exec env - PATH=$PATH \ runsvdir /service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................' ------snip------- my /service/getty/run is : ---snip--- #!/bin/sh exec /sbin/agetty 38400 tty5 linux ---snip--- I have freed tty5 from /etc/inittab file already. I am stuck up at this point basically. I guess i am wrong in the invocation of the *getty programs. Any suggestions would be really helpful. TIA Karthik __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 3:10 runit pblms on Mandrake Karthik M @ 2003-07-17 6:00 ` Hleil Liu 2003-07-17 6:05 ` Hleil Liu 2003-07-17 16:26 ` Karthik M 0 siblings, 2 replies; 24+ messages in thread From: Hleil Liu @ 2003-07-17 6:00 UTC (permalink / raw) On Wed, 16 Jul 2003 20:10:31 -0700 (PDT) Karthik M <k_mohanas@yahoo.com> wrote: > Hello everyone, > > I am trying to install runit-0.10.0 on Mandrake 9.0. I > was facing initial compilation pblms which Gerrit > solved it and referred to this mailing list. > First at all,you should make getty service running ok use original /sbin/init and daemontools.see http://smarden.org/runit/replaceinit.html step3. And,the best way is pass init=/sbin/runit-init to the kernel instead of replace /sbin/init with /sbin/runit-init directly.If system running as you expect,do replace,then reboot use the new /sbin/init. Make sure you copy runit-init itself into /sbin if you want use symbolic links.I my system,I just cp /admin/package/runit/command/runit-init /sbin/init > The i modified the symlink to : > > #ln -s /sbin/runit /sbin/init [instead of runit-init] > Error.Must replace /sbin/init with runit-init. > I have freed tty5 from /etc/inittab file already. I am > stuck up at this point basically. I guess i am wrong > in the invocation of the *getty programs. Any > suggestions would be really helpful. > /etc/inittab only effected with original /sbin/init.In fact, in oder to test whether getty running fine in step3,you can select another free tty,ex,tty8(RedHat only use tty1-tty6,if you have X,you should not use tty7,so maybe tty8 is better) Regard! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:00 ` Hleil Liu @ 2003-07-17 6:05 ` Hleil Liu 2003-07-17 6:25 ` Laurent Bercot 2003-07-17 16:26 ` Karthik M 1 sibling, 1 reply; 24+ messages in thread From: Hleil Liu @ 2003-07-17 6:05 UTC (permalink / raw) On Thu, 17 Jul 2003 14:00:19 +0800 Hleil Liu <hleil@yahoo.com.cn> wrote: > Make sure you copy runit-init itself into /sbin if you want > use symbolic links.I my system,I just > > cp /admin/package/runit/command/runit-init /sbin/init > sorry, cp /package/admin/runit/command/runit-init /sbin/init and must copy runit itself into /sbin. cp /package/admin/runit/command/runit /sbin/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:05 ` Hleil Liu @ 2003-07-17 6:25 ` Laurent Bercot 2003-07-17 8:51 ` Hleil Liu ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Laurent Bercot @ 2003-07-17 6:25 UTC (permalink / raw) > cp /package/admin/runit/command/runit-init /sbin/init > > and must copy runit itself into /sbin. > > cp /package/admin/runit/command/runit /sbin/ Why perform those steps at all ? Copying binaries into /sbin creates potential problems: - it breaks the rule of "/[s]bin and /usr/[s]bin belong to the OS and its native package manager" - it duplicates binaries - it is non-standard and non-portable. In other words, by copying binaries into /sbin, you're making your system less clean, more error-prone and more difficult to debug. There are two documented, supported, portable, whatever, ways of accessing the runit binaries: in /command and in /package/admin/runit/command. Isn't that enough ? Using " init=/command/runit-init" within your bootloader will start runit-init as process 1 all right, and you don't have to copy it anywhere. You may have chosen to copy the binaries into /sbin because /package is a link to /usr/local/package, or something of the kind, which is not mounted at boot-time. This is not a good idea. Since the runit package is a basic system package, it should reside entirely within the root filesystem. Don't make /package and /command links to something that is not mounted at boot time, but forests of symlinks pointing to the real location of every package. A tool such as http://www.skarnet.org/software/symtools/update-symlinks.html may help you. -- Ska ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:25 ` Laurent Bercot @ 2003-07-17 8:51 ` Hleil Liu 2003-07-17 12:33 ` Laurent Bercot 2003-07-18 10:17 ` Gerrit Pape 2003-07-19 17:25 ` Hleil Liu 2 siblings, 1 reply; 24+ messages in thread From: Hleil Liu @ 2003-07-17 8:51 UTC (permalink / raw) On Thu, 17 Jul 2003 08:25:20 +0200 Laurent Bercot <ska-supervision@skarnet.org> wrote: > Why perform those steps at all ? > Copying binaries into /sbin creates potential problems: > - it breaks the rule of "/[s]bin and /usr/[s]bin belong to the OS > and its native package manager" > - it duplicates binaries > - it is non-standard and non-portable. > yes. > In other words, by copying binaries into /sbin, you're making your > system less clean, more error-prone and more difficult to debug. > > There are two documented, supported, portable, whatever, ways of > accessing the runit binaries: in /command and in > /package/admin/runit/command. Isn't that enough ? no,the reason is what you said below.the /package and /command directorys may be not stay at root partition.Although we can think /pacakge/admin/* as the basic system packages,but what about others?like /package/prog? /package/host?Are they basic?So we have to take all the /package/*,at least all the binaries under /package at root partition? If put runit-init and runit into /sbin,we need not consider those.In stage 1, runit do system init,mount other patitions,so stage 2 can use all the filesystems. if stage 1 failed,it start an emergency shell.If stage 1 exit sucessfully,all symbolic links work.So we can put /package anywhere,for me,I put it another patition. The problem is:after we upgraded runit,we should replace /sbin/init and /sbin/runit with the new version,and these's two copys of runit and runit-init(/sbin/init). > Using " init=/command/runit-init" within your bootloader will start > runit-init as process 1 all right, and you don't have to copy it > anywhere. good idea,we dont need *replace* /sbin/init,thanks!But maybe I use init=/sbin/runit-init in my /etc/grub.conf, :) Regard! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 8:51 ` Hleil Liu @ 2003-07-17 12:33 ` Laurent Bercot 2003-07-17 16:30 ` Karthik M 2003-07-17 19:30 ` Stefan Karrmann 0 siblings, 2 replies; 24+ messages in thread From: Laurent Bercot @ 2003-07-17 12:33 UTC (permalink / raw) > no,the reason is what you said below.the /package and /command directorys > may be not stay at root partition.Although we can think /pacakge/admin/* > as the basic system packages,but what about others?like /package/prog? > /package/host?Are they basic?So we have to take all the /package/*,at least > all the binaries under /package at root partition? No, of course. You can have for instance /rootfs/package, located on the root partition, /usr/local/package, located on another one, and /package being a set of symlinks pointing to the right places. The command update-symlinks /package /rootfs/package /usr/local/package will create the right links in /package. Remember: /package is only an _access_ path, not a physical location path. Nobody cares where your files really are, as long as they can be reliably accessed. You could even have the runit and runit-init binaries on the root partition, and everything else, including the rest of the runit package, in /usr/local - no problem as long as /package and /command still provide the right access paths. > good idea,we dont need *replace* /sbin/init,thanks!But maybe I use > init=/sbin/runit-init in my /etc/grub.conf, :) Don't. Use init=/command/runit-init or init=/package/admin/runit/command/runit-init in your /etc/grub.conf, and make sure it points to the actual runit-init program. -- Ska ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 12:33 ` Laurent Bercot @ 2003-07-17 16:30 ` Karthik M 2003-07-17 17:10 ` Lukas Beeler 2003-07-17 19:30 ` Stefan Karrmann 1 sibling, 1 reply; 24+ messages in thread From: Karthik M @ 2003-07-17 16:30 UTC (permalink / raw) Hello everyone, i forgot to include one more detail in my previous mail.I looked up in the /var/log/messages and found this error message being generated for every respawned mingetty process: -----snip----- Jul 17 11:47:41 /sbin/mingetty[2320]: /dev/vc/5: cannot open tty: Operation not permitted -----snip----- Is this a permissions related pblm ?? Thanks karthik __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 16:30 ` Karthik M @ 2003-07-17 17:10 ` Lukas Beeler 2003-07-17 22:22 ` Karthik M 2003-07-19 1:43 ` Karthik M 0 siblings, 2 replies; 24+ messages in thread From: Lukas Beeler @ 2003-07-17 17:10 UTC (permalink / raw) * Karthik M <k_mohanas@yahoo.com>: > -----snip----- > Jul 17 11:47:41 /sbin/mingetty[2320]: /dev/vc/5: > cannot open tty: Operation not permitted > -----snip----- > Is this a permissions related pblm ?? Not really. But the getty needs to be session leader. Thus change the runfile to read: #!/bin/sh exec pgrphack mingetty /dev/vc/5 -- Today is the first day of the rest of our lives. http://www.suug.ch ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 17:10 ` Lukas Beeler @ 2003-07-17 22:22 ` Karthik M 2003-07-19 1:43 ` Karthik M 1 sibling, 0 replies; 24+ messages in thread From: Karthik M @ 2003-07-17 22:22 UTC (permalink / raw) Hi, I am @ work right now .. will try it out once i get home .. thanx for the reply karthik --- Lukas Beeler <lb-lists@projectdream.org> wrote: > * Karthik M <k_mohanas@yahoo.com>: > > -----snip----- > > Jul 17 11:47:41 /sbin/mingetty[2320]: /dev/vc/5: > > cannot open tty: Operation not permitted > > -----snip----- > > Is this a permissions related pblm ?? > > Not really. But the getty needs to be session > leader. > Thus change the runfile to read: > > #!/bin/sh > exec pgrphack mingetty /dev/vc/5 > > -- > Today is the first day of the rest of our lives. > http://www.suug.ch __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 17:10 ` Lukas Beeler 2003-07-17 22:22 ` Karthik M @ 2003-07-19 1:43 ` Karthik M 2003-07-19 8:02 ` Lukas Beeler 1 sibling, 1 reply; 24+ messages in thread From: Karthik M @ 2003-07-19 1:43 UTC (permalink / raw) Hello everyone, pgrphack did the trick. My daemontools fired up the getty fine and my runit bootup came up smoothly. Thanx for all the suggestions and discussions. I searched thru the man page for mingetty and there was no mentioning that it has to be the process group leader and we had to invoke setsid() if we need to invoke it seperately !! where do we get all these kind of info for debugging such pblms ?? just out of curiosity want to know so that i can search on my own before posting it to mailing lists. thanks karthik --- Lukas Beeler <lb-lists@projectdream.org> wrote: > * Karthik M <k_mohanas@yahoo.com>: > > -----snip----- > > Jul 17 11:47:41 /sbin/mingetty[2320]: /dev/vc/5: > > cannot open tty: Operation not permitted > > -----snip----- > > Is this a permissions related pblm ?? > > Not really. But the getty needs to be session > leader. > Thus change the runfile to read: > > #!/bin/sh > exec pgrphack mingetty /dev/vc/5 > > -- > Today is the first day of the rest of our lives. > http://www.suug.ch __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-19 1:43 ` Karthik M @ 2003-07-19 8:02 ` Lukas Beeler 2003-07-22 21:31 ` Karthik M 0 siblings, 1 reply; 24+ messages in thread From: Lukas Beeler @ 2003-07-19 8:02 UTC (permalink / raw) * Karthik M <k_mohanas@yahoo.com>: > I searched thru the man page for mingetty and there > was no mentioning that it has to be the process group > leader and we had to invoke setsid() if we need to > invoke it seperately !! where do we get all these kind > of info for debugging such pblms ?? just out of > curiosity want to know so that i can search on my own > before posting it to mailing lists. ptrace() mingetty using strace. You'll see that a system call returns EPERM (I don't remember which one). It's seldom that you get EPERM when running a program as root. Thus, i looked through the kernel source for this system call, and found out that EPERM is returned in case the program is not session leader. Finding out how to become session leader was a matter of quick googling. -- Today is the first day of the rest of our lives. http://www.suug.ch ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-19 8:02 ` Lukas Beeler @ 2003-07-22 21:31 ` Karthik M 2003-07-22 21:40 ` Charlie Brady 2003-07-23 18:30 ` clemens fischer 0 siblings, 2 replies; 24+ messages in thread From: Karthik M @ 2003-07-22 21:31 UTC (permalink / raw) Hi, That's very interesting to know that some of the getty like program do invoke setsid() internally and some of them don't. This should be made standardised that all of these programs should invoke setsid() internally. AFAIK there is not mentioning of setsid() needed to be invoked externally in the man pages for mingetty. :( :( I have another question which sprang up when playing around with the scripts. "How does the init process know that a getty process has died and it needs to be respawned ??" possible solution: Getty processes raising a signal such as SIGCHLD when exiting but when a user logins, getty program uses a /bin/login binary for user authentication and when the user login it is either /bin/sh or /bin/bash [or similar] shells that are in control. A getty process cannot be observed from the 'ps -aux' output. So it is not running at all after the user logins into the system. So when the user logs out then it is the shell that exits and not the getty process. But how does init detect that it needs to respawn a getty process for that specific tty ?? thanx for all the help and guidance in my learning process. Karthik --- Lukas Beeler <lb-lists@projectdream.org> wrote: > * Karthik M <k_mohanas@yahoo.com>: > > I searched thru the man page for mingetty and > there > > was no mentioning that it has to be the process > group > > leader and we had to invoke setsid() if we need to > > invoke it seperately !! where do we get all these > kind > > of info for debugging such pblms ?? just out of > > curiosity want to know so that i can search on my > own > > before posting it to mailing lists. > > ptrace() mingetty using strace. You'll see that a > system call > returns EPERM (I don't remember which one). It's > seldom that you > get EPERM when running a program as root. Thus, i > looked through > the kernel source for this system call, and found > out that EPERM > is returned in case the program is not session > leader. Finding > out how to become session leader was a matter of > quick googling. > > -- > Today is the first day of the rest of our lives. > http://www.suug.ch __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-22 21:31 ` Karthik M @ 2003-07-22 21:40 ` Charlie Brady 2003-07-23 18:30 ` clemens fischer 1 sibling, 0 replies; 24+ messages in thread From: Charlie Brady @ 2003-07-22 21:40 UTC (permalink / raw) Cc: supervision On Tue, 22 Jul 2003, Karthik M wrote: > "How does the init process know that a getty process > has died and it needs to be respawned ??" ... > > A getty process > cannot be observed from the 'ps -aux' output. So it is > not running at all after the user logins into the > system. So when the user logs out then it is the shell > that exits and not the getty process. They're the same process. See "man execve". -- Charlie Brady charlie_brady@mitel.com Lead Product Developer Network Server Solutions Group Mitel Networks Corporation http://www.mitel.com/smallbusiness Phone: +1 (613) 592 5660 or 592 2122 Fax: +1 (613) 592 1175 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-22 21:31 ` Karthik M 2003-07-22 21:40 ` Charlie Brady @ 2003-07-23 18:30 ` clemens fischer 1 sibling, 0 replies; 24+ messages in thread From: clemens fischer @ 2003-07-23 18:30 UTC (permalink / raw) Cc: supervision * Karthik M.: > That's very interesting to know that some of the getty like program > do invoke setsid() internally and some of them don't. This should be > made standardised that all of these programs should invoke setsid() > internally. this might not be a good idea. no session is needed in case getty(8) fails, but see below. > "How does the init process know that a getty process has died and it > needs to be respawned ??" it gets a signal (SIGCHLD?), it's as simple as that. i just browsed the sources of init(8), getty(8) and login(1) to find out how freebsd does it. init(8) calls getty(8), this calls login(1), and contained therein is a call to setlogin(2), which requires setsid(2) before it is called. so init(8) fork(2)s and its children do a login_tty(3) call, which does the setsid(2). a NOTES file in inits source directory has this to say (chapter numbers refer to POSIX.1): ,---- | On setsid(): | ----------- | | It appears that neither getty nor login call setsid(), so init must | do this -- seems reasonable. B.4.3.2 p 248 implies that this is the | way that 'init' should work; it says that setsid() should be called | after forking. | | Process group leaders cannot call setsid() -- another reason to | fork! Of course setsid() causes the current process to become a | process group leader, so we can only call setsid() once. Note that | the controlling terminal acquires the session leader's process | group when opened. `---- clemens ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 12:33 ` Laurent Bercot 2003-07-17 16:30 ` Karthik M @ 2003-07-17 19:30 ` Stefan Karrmann 1 sibling, 0 replies; 24+ messages in thread From: Stefan Karrmann @ 2003-07-17 19:30 UTC (permalink / raw) Laurent Bercot (Thu, Jul 17, 2003 at 02:33:32PM +0200): > You can have for instance /rootfs/package, located on the root partition, > /usr/local/package, located on another one, and /package being a set of > symlinks pointing to the right places. The command > update-symlinks /package /rootfs/package /usr/local/package > will create the right links in /package. > > Remember: /package is only an _access_ path, not a physical location path. > Nobody cares where your files really are, as long as they can be > reliably accessed. You could even have the runit and runit-init binaries > on the root partition, and everything else, including the rest of the > runit package, in /usr/local - no problem as long as /package and /command > still provide the right access paths. C.f. <http://multivac.cwru.edu./fs/#tricks>. > [...] Use init=/command/runit-init > or init=/package/admin/runit/command/runit-init > in your /etc/grub.conf, and make sure it points to the actual runit-init > program. -- Stefan ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:25 ` Laurent Bercot 2003-07-17 8:51 ` Hleil Liu @ 2003-07-18 10:17 ` Gerrit Pape 2003-07-19 17:25 ` Hleil Liu 2 siblings, 0 replies; 24+ messages in thread From: Gerrit Pape @ 2003-07-18 10:17 UTC (permalink / raw) On Thu, Jul 17, 2003 at 08:25:20AM +0200, Laurent Bercot wrote: > > cp /package/admin/runit/command/runit-init /sbin/init > > > > and must copy runit itself into /sbin. > > > > cp /package/admin/runit/command/runit /sbin/ > > Why perform those steps at all ? > You may have chosen to copy the binaries into /sbin because /package > is a link to /usr/local/package, or something of the kind, which is not > mounted at boot-time. This is not a good idea. He's following the instructions on how to replace init from the runit web page. Installing runit and runit-init into /sbin is step 2. Of course it would be sufficient if /package/admin/runit/command is on the root filesystem, but I cannot know. The slashpackage concept doesn't provide a concept to ensure this. OTOH /sbin always is on the root filesystem. Regards, Gerrit. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:25 ` Laurent Bercot 2003-07-17 8:51 ` Hleil Liu 2003-07-18 10:17 ` Gerrit Pape @ 2003-07-19 17:25 ` Hleil Liu 2 siblings, 0 replies; 24+ messages in thread From: Hleil Liu @ 2003-07-19 17:25 UTC (permalink / raw) On Thu, 17 Jul 2003 08:25:20 +0200 Laurent Bercot <ska-supervision@skarnet.org> wrote: > Why perform those steps at all ? > Copying binaries into /sbin creates potential problems: > - it breaks the rule of "/[s]bin and /usr/[s]bin belong to the OS > and its native package manager" > - it duplicates binaries > - it is non-standard and non-portable. > But,we use runit instead of init *is* non-standard and non-portable. For OS's native package manager,as RedHat'RPM,if we just *replace* init with runit, we break RPM's action because we haven't remove the original SysVinit,rpm database considers the file /sbin/init belongs to the package SysVinit,but now it's not. We running the box use runit,so,we don't need SysVinit anymore,we can remove it. Although remove SysVinit cleanly is a very big job,we have to fix many many problems, even have to make a new distribution.As a D.J.Bix? :-) Regard! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 6:00 ` Hleil Liu 2003-07-17 6:05 ` Hleil Liu @ 2003-07-17 16:26 ` Karthik M 2003-07-18 10:20 ` Gerrit Pape 1 sibling, 1 reply; 24+ messages in thread From: Karthik M @ 2003-07-17 16:26 UTC (permalink / raw) Hi, To summarize the whole situation now, I had passed /sbin/runit-init as my init program through menu.lst of grub. I tried the symlinking of /sbin/init to the runit binary as a LAST and DESPERATE measure, but obviously it did'nt work as my daemontools is not working properly for some reason. I tried out what Hleil liu had suggested. I could not get a mingetty running on my system using the normal system V init and daemontools. my /etc/inittab looks like: ----- 5:2345:respawn:/sbin/mingetty tty5 ----- So now my /service/getty/run looks like: ----- #!/bin/sh exec /sbin/mingetty tty5 ----- I restarted the system to be sure that everything gets initiated from the beginning and had started daemontools also from inittab. After i booted up, i looked up ps -aux and i get the following results: -----snip----- root 1972 0.0 0.0 0 0 ? Z 11:44 0:00 [mingetty <defunct>] root 1974 0.0 0.1 2748 868 pts/1 R 11:44 0:00 ps -aux -----snip----- There is no controlling tty for mingetty and also it is reported as a Zombie process. I left the system running for a few mins [maybe 10 mins] and my PID's shooted to 2600+. The zombie process was being respawned. I could'nt get much info to debug daemontools and please help me out here to get this running. I guess everything else should work fine once i get daemontools working. Thanks for all your suggestions karthik __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-17 16:26 ` Karthik M @ 2003-07-18 10:20 ` Gerrit Pape 2003-07-18 16:27 ` Lukas Beeler 0 siblings, 1 reply; 24+ messages in thread From: Gerrit Pape @ 2003-07-18 10:20 UTC (permalink / raw) On Thu, Jul 17, 2003 at 09:26:49AM -0700, Karthik M wrote: > I tried out what Hleil liu had suggested. I could not > get a mingetty running on my system using the normal > system V init and daemontools. > my /etc/inittab looks like: > ----- > 5:2345:respawn:/sbin/mingetty tty5 > ----- Did you remove this line from inittab? > So now my /service/getty/run looks like: > ----- > #!/bin/sh > exec /sbin/mingetty tty5 > ----- > > I restarted the system to be sure that everything gets > initiated from the beginning and had started > daemontools also from inittab. > > After i booted up, i looked up ps -aux and i get the > following results: > > -----snip----- > root 1972 0.0 0.0 0 0 ? Z > 11:44 0:00 [mingetty <defunct>] > root 1974 0.0 0.1 2748 868 pts/1 R > 11:44 0:00 ps -aux > -----snip----- > Thanks for all your suggestions I believe mandrake provides several getties. Could you please try with another getty? Regards, Gerrit. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: runit pblms on Mandrake 2003-07-18 10:20 ` Gerrit Pape @ 2003-07-18 16:27 ` Lukas Beeler 2003-07-21 10:01 ` some getties require setsid() (Re: runit pblms on Mandrake) Gerrit Pape 0 siblings, 1 reply; 24+ messages in thread From: Lukas Beeler @ 2003-07-18 16:27 UTC (permalink / raw) * Gerrit Pape <pape@smarden.org>: > I believe mandrake provides several getties. Could you please try with > another getty? mingetty/fgetty only works when you invoke setsid() before exec'ing into the getty. pgrphack can do this, and so can setsid (which is part of util-linux). -- Today is the first day of the rest of our lives. http://www.suug.ch ^ permalink raw reply [flat|nested] 24+ messages in thread
* some getties require setsid() (Re: runit pblms on Mandrake) 2003-07-18 16:27 ` Lukas Beeler @ 2003-07-21 10:01 ` Gerrit Pape 2003-07-21 10:13 ` some getties require setsid() Lukas Beeler 0 siblings, 1 reply; 24+ messages in thread From: Gerrit Pape @ 2003-07-21 10:01 UTC (permalink / raw) On Fri, Jul 18, 2003 at 06:27:24PM +0200, Lukas Beeler wrote: > * Gerrit Pape <pape@smarden.org>: > > I believe mandrake provides several getties. Could you please try with > > another getty? > > mingetty/fgetty only works when you invoke setsid() before > exec'ing into the getty. pgrphack can do this, and so can setsid > (which is part of util-linux). Thanks for the info. Is this specific to these getty implementations, or specific to an OS or Linux distribution? Do you know about the reason why these getties require this? Regards, Gerrit. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: some getties require setsid() 2003-07-21 10:01 ` some getties require setsid() (Re: runit pblms on Mandrake) Gerrit Pape @ 2003-07-21 10:13 ` Lukas Beeler 2003-07-23 17:03 ` clemens fischer 0 siblings, 1 reply; 24+ messages in thread From: Lukas Beeler @ 2003-07-21 10:13 UTC (permalink / raw) * Gerrit Pape <pape@smarden.org>: > Thanks for the info. Is this specific to these getty implementations, > or specific to an OS or Linux distribution? agetty (util-linux) does the setsid() by itself, apparently all getty's need to be session leader to work. mingetty/fgetty (same codebase) require somebody else do to the setsid call for them. mingetty is widely used on linux distributions, all *BSD systems ship with their own gettys. It looks like NetBSD's /usr/libexec/getty does not use setsid. However, iam not sure about this, because iam not really familiar with NetBSD's ktruss, and how getty invocation works on NetBSD. > Do you know about the reason why these getties require this? Not really. -- Today is the first day of the rest of our lives. http://www.suug.ch ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: some getties require setsid() 2003-07-21 10:13 ` some getties require setsid() Lukas Beeler @ 2003-07-23 17:03 ` clemens fischer 2003-07-23 17:23 ` Lukas Beeler 0 siblings, 1 reply; 24+ messages in thread From: clemens fischer @ 2003-07-23 17:03 UTC (permalink / raw) * Lukas Beeler: > It looks like NetBSD's /usr/libexec/getty does not use setsid. > However, iam not sure about this, because iam not really familiar > with NetBSD's ktruss, and how getty invocation works on NetBSD. ... and i'm having big problems following this thread, because none of the *gettys mentioned are in freebsds port collection (a sure sign of i'd like to know what). no setsid(2) in our getty, either. does somebody know if there's something special in the *bsds here? clemens ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: some getties require setsid() 2003-07-23 17:03 ` clemens fischer @ 2003-07-23 17:23 ` Lukas Beeler 0 siblings, 0 replies; 24+ messages in thread From: Lukas Beeler @ 2003-07-23 17:23 UTC (permalink / raw) * clemens fischer <ino-qc@spotteswoode.de.eu.org>: > ... and i'm having big problems following this thread, because none of > the *gettys mentioned are in freebsds port collection (a sure sign of > i'd like to know what). At least agetty, mingetty and fgetty are linux specific. It wouldnt make sense to have them in freebsd's port collection. > no setsid(2) in our getty, either. > does somebody know if there's something special in the *bsds here? No clue about *BSD ;) -- Today is the first day of the rest of our lives. http://www.suug.ch ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-07-23 18:30 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-17 3:10 runit pblms on Mandrake Karthik M 2003-07-17 6:00 ` Hleil Liu 2003-07-17 6:05 ` Hleil Liu 2003-07-17 6:25 ` Laurent Bercot 2003-07-17 8:51 ` Hleil Liu 2003-07-17 12:33 ` Laurent Bercot 2003-07-17 16:30 ` Karthik M 2003-07-17 17:10 ` Lukas Beeler 2003-07-17 22:22 ` Karthik M 2003-07-19 1:43 ` Karthik M 2003-07-19 8:02 ` Lukas Beeler 2003-07-22 21:31 ` Karthik M 2003-07-22 21:40 ` Charlie Brady 2003-07-23 18:30 ` clemens fischer 2003-07-17 19:30 ` Stefan Karrmann 2003-07-18 10:17 ` Gerrit Pape 2003-07-19 17:25 ` Hleil Liu 2003-07-17 16:26 ` Karthik M 2003-07-18 10:20 ` Gerrit Pape 2003-07-18 16:27 ` Lukas Beeler 2003-07-21 10:01 ` some getties require setsid() (Re: runit pblms on Mandrake) Gerrit Pape 2003-07-21 10:13 ` some getties require setsid() Lukas Beeler 2003-07-23 17:03 ` clemens fischer 2003-07-23 17:23 ` Lukas Beeler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).