runit pblms on Mandrake

runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Hleil Liu]

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!

Re: runit pblms on Mandrake

[Hleil Liu]

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/

Re: runit pblms on Mandrake

[Laurent Bercot]

> 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

Re: runit pblms on Mandrake

[Hleil Liu]

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!

Re: runit pblms on Mandrake

[Laurent Bercot]

> 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

Re: runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Lukas Beeler]

* 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

Re: runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Lukas Beeler]

* 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

Re: runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Charlie Brady]

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

Re: runit pblms on Mandrake

[clemens fischer]

* 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

Re: runit pblms on Mandrake

[Stefan Karrmann]

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

Re: runit pblms on Mandrake

[Gerrit Pape]

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.

Re: runit pblms on Mandrake

[Hleil Liu]

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!

Re: runit pblms on Mandrake

[Karthik M]

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

Re: runit pblms on Mandrake

[Gerrit Pape]

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.

Re: runit pblms on Mandrake

[Lukas Beeler]

* 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

some getties require setsid() (Re: runit pblms on Mandrake)

[Gerrit Pape]

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.

Re: some getties require setsid()

[Lukas Beeler]

* 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

Re: some getties require setsid()

[clemens fischer]

* 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

Re: some getties require setsid()

[Lukas Beeler]

* 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