Linux-Development-Sys Digest #679, Volume #8 Mon, 30 Apr 01 05:13:09 EDT
Contents:
Re: Startup service ("D. Stimits")
Re: Pipe Problem (eric)
Re: DHCP client broken in 2.4.4 (Guy Geens)
Re: movl %ax,%ds " ?? what does "l" means ??? ("D. Stimits")
Re: File access within a kernel mod (Juha Ruismäki)
Re: Startup service ("Darren")
Re: Startup service ("Darren")
----------------------------------------------------------------------------
Date: Sun, 29 Apr 2001 22:00:54 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Startup service
Someone else already answered this, but I thought it might be useful to
add to it.
Darren wrote:
>
> D. Stimits <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Darren wrote:
> > >
> > > Hello all I am writing a small app that I want to run as a Linux service
> > > when it starts up. Can anyone tell me if I need any special
> consideration
> > > when writing a Linux tsr? also does one know which file it stores the
> info
> > > on startup apps in?
> > >
> > > Thank you
> > >
> > > Darren
> >
> > There isn't really anything called a tsr in linux. It is just a daemon.
>
> that would be typical of linux. so smooth and consistent :-)
It does make programming and debugging easier.
>
> > The typical daemon does a fork and exec after being started by an rc
> > script.
> whats the differece between a fork and an exec?
>
> For redhat, the script samples are in /etc/rc.d/init.d/. For
> > other distributions, they are in an init.d directory, but it might be
> > located somewhere else; I think SuSE uses /sbin/init.d/ or something
> > like that. Programs that are not really system daemons but are desired
> > to start each reboot often are just added in by editing
> > /etc/rc.d/rc.local (again, location will vary with distribution, but it
> > is usually named rc.local). SuSE also has an rc script in /etc/ that
> > yast uses.
>
> aha so it is rc.local i am looking for?
If your only concern is to run some command at startup, yes. If it must
be controlled for start and stop activity at various runlevels, you'd
create a script to go in the init.d subdirectory; then links from the
various runlevel directories would determine whether the script is
called with a start or stop at the given runlevels. inetd is a sample of
something controlled at various runlevels, as well as a few other
daemons. To see a list of what is controlled to start or stop, try this:
chkconfig --list
(chkconfig might not be available under all distributions, I haven't
checked)
>
> >
> > The scripts usually take arguments of "start", "stop", "status", and
> > "restart". Symbolic links from various runlevel directories (e.g.,
> > /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> > process at those levels,
> forgive me for being stupid, but i do not understand
UNIX-style systems do not simply boot up or stop, they start or stop in
stages. Stopped appears to always be runlevel 0, reboot runlevel 6. In
between there is usually a single user mode (console only single user,
good for some forms of disaster recovery), a multi-user console mode,
and a multi-user graphics mode (X11). The exact number used for those in
between levels varies with distribution. Sometimes there is further
breakdown, such as single user console mode without networking, and the
next mode up being single user still but with networking. If you use
something like "ps aux" you will see process ID 1 is the grand parent of
all processes, "init". The runlevel is the argument to init. If root
calls "init 6", it will reboot; if root calls "init 0", it will halt.
The startup scripts are calling init in a series of steps, and at each
step, running scripts from init.d to start or stop services scheduled
for those levels. rc.local is generally the last thing called in the
bootup final runlevel destination, whereas init.d scripts can be
automatically called with start or stop arguments at every level. Thus,
if you only want to end up running something at the final bootup level,
just add it to rc.local; if you want to make sure about a specific start
or stop behaviour at each runlevel, put it in the init.d subdirectory
and create the appropriate links (chkconfig can do this for you, take a
look at the top comments in the init.d scripts).
As an example, on redhat, if you have the cron daemon to run, root can
type any of these:
/etc/rc.d/init.d/crond status
(returns its current status)
/etc/rc.d/init.d/crond stop
(stops cron daemon; error if it wasn't started already)
/etc/rc.d/init.d/crond start
(starts cron daemon; error if it was already started)
/etc/rc.d/init.d/crond restart
(stops then starts the cron daemon; error if it wasn't already started)
On one redhat 6.2 system, "chkconfig --list | grep crond" shows this:
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
This means that at runlevels 0, 1, and 6, crond is turned off, while
runlevels 2, 3, 4, and 5 have it turned on. For redhat, runlevel 4 is
never used, so it is actually irrelevant.
>
> but if the sym link is done with a name
> > starting with "s" it starts it at that level (your mileage may vary
> > depending on distribution). Other complexities are that for security it
> > isn't unusual to arrange for the daemon to start as root but to be
> > transferred for execution as user "nobody" (or some other less
> > privileged user);
> now this i understand. I do have need to have a process start at bootup and
> as all processes need a user connection then i need to create a virual user
> with priviledges to access only the required reources and attach the process
> to that user, if that makes any sense
Yes, a lot of startup daemons are started by root, but transferred to
ownership by a less privileged user. In terms of security, explicit
testing and start or stop at each runlevel is probably the better way to
go, versus rc.local, but as an end result you could do it either way
(with rc.local being less complicated).
D. Stimits, [EMAIL PROTECTED]
>
> and there is often some sort of lock file or pid file
> > to let the system know what pid the process is at.
>
> Thank you for your reply D you have been most kind
>
> >
> > D. Stimits, [EMAIL PROTECTED]
------------------------------
From: eric <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Pipe Problem
Date: Sun, 29 Apr 2001 23:33:55 -0500
Frank wrote:
> "eric" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Frank wrote:
> >
> > > Hi all,
> > >
> > > I'm currently implementing the pipe operator for a custom shell.
> > > Though, it seems that my pipe hangs on the second process when I try to
> > > pipe more than 2 programs. So, I could only assume that I might have
> > > implemented the pipe wrong for all processes in between. So, the only
> > > assumption is the the first process and the last process works
> > > correctly. So, I'm wondering what am I doing wrong with the processes
> > > in between.
> > >
> > > Frank
> > > TIA
> > >
> > > /* NOTE: nPipes is the number of operators present. So, if nPipes = 2,
> > > then 3 programs need to be executed */
> > >
> > > void ExecutePipe(struct CmdLine *pList, int nPipes)
> > > {
> > > int i;
> > > int fidPipe[2];
> > > enum PIPES { READ, WRITE }; /* Constants 0 and 1 for READ and WRITE */
> > > struct CmdLine *pCurrent = pList;
> > >
> > > pipe(fidPipe);
> > >
> > > for(i = 0; i < nPipes + 1; i++) {
> > > if(i == nPipes) {
> > > ...
> > > if( (pid = fork()) == 0
> > > execvp(pCurrent->argv[0], pCurrent->argv);
> > > } else {
> > > waitpid(...)
> > > ...
> > > }
> > > } else {
> > > int pid;
> > > if((pid = fork()) == 0) {
> > > if(i != 0) {
> > > /* if we are in the middle of a pipe, stdin should be closed
> > > and be converted to the read of the pipe. */
> > > close(fileno(stdin));
> > > dup2(fidPipe[READ], fileno(stdin));
> > > }
> > > /* Now, close the read end of the pipe since we don't need it
> > > */
> > > lose(fidPipe[READ]);
> > > /* Close stdout, which would be redircted the the write end of
> > > the pipe */
> > > close(fileno(stdout));
> > > dup2(fidPipe[WRITE], fileno(stdout));
> > > /* Close the write pipe, which we don't need */
> > > close(fidPipe[WRITE]);
> > > execvp(pCurrent->argv[0], pCurrent->argv);
> > > } else {
> > > int status;
> > > waitpid(pid, &status, 0);
> > > }
> > > }
> > > pCurrent = next in link list;
> > > }
> > > return;
> > > }
> >
> > I'd say you actually have two problems. The first is the waitpid in the
> > else clause of the lower fork. This will cause your program to stop and
> > wait until the child process has stopped before it will fire off the next
> > child process. The second problem which looks even hairier is that you
> are
> > trying to assign each of the middle processes the same pipe as their stdin
> > and stdout. You need to have a pipe set for each process (actually
> > I believe you can use n-1 pipe sets) that you fire up. The stdin in for
> > the next process needs to be assigned the stdout of the previous process
> > and it's stdout be one of the new pipes, with the last one having it's
> > stdout be regular stdout (which you do have).
> >
> > Hope this helped,
> >
> > Eric
> > MVP for Unix Programming
> > BrainBench http://www.brainbench.com
> >
>
> Thanks, I figured that it had something to do with using one pipe. And,
> thanks, I didn't think about the queuing effect that I had with the pipes.
> I guess a way to do it is to make an array of pipes, though, wouldn't that
> be an unoptimized method since I might have so many pipes created at once?
> Or, would the performance outweigh the memory I would be allocating for
> those pipes?
>
> Frank
It's not really unoptimized for what you are doing because you don't know how
much output any particular segment is going to have so without having the pipes
open right away you'd have to completely buffer the output (which could be
gigabytes, well depending on what you are allowing your shell to do) before the
next segment started.
Eric
------------------------------
Subject: Re: DHCP client broken in 2.4.4
From: Guy Geens <[EMAIL PROTECTED]>
Date: Mon, 30 Apr 2001 05:12:30 GMT
>>>>> "xstatik" == xstatik <[EMAIL PROTECTED]> writes:
xstatik> could possibly be that RealTek drivers are somehow broke or
xstatik> so radically changed (cannot confirm this). I also have two
The driver has been changed, as well as most of the networking code.
My first suspect was the general network code because the card works
fine if I assign a fixed IP address with ifconfig.
Next attempt: disable rp_spoof. No such luck.
I'm going to try downgrading the card driver and try again.
--
G. ``Iggy'' Geens - ICQ: #64109250
Home: <[EMAIL PROTECTED]> - Work: <[EMAIL PROTECTED]>
WWW: http://users.pandora.be/guy.geens/
``I was thinking about how everyone was dying
and maybe it's time to live.'' - Eels
------------------------------
Date: Sun, 29 Apr 2001 23:36:10 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: movl %ax,%ds " ?? what does "l" means ???
hushui wrote:
>
> movl %ax,%ds " ?? what does "l" means ???
>
> In At&t 's asm , there are many instructions end with "l"
> ,such as movl,pushl??
> what does "l" means ??
> long????
Correct, it means "long". This was one of my questions a couple of
months ago.
D. Stimits, [EMAIL PROTECTED]
------------------------------
From: Juha Ruismäki <[EMAIL PROTECTED]>
Subject: Re: File access within a kernel mod
Date: Mon, 30 Apr 2001 11:02:58 +0300
Kasper Dupont wrote:
> I could have written exactly the same using gotos,
> but that is normally considered bad programming
> practice.
I have nothing to add to original topic, but I have to comment
this one. Using goto to jump forward in error condition is not
or has never been considered bad programming practice. Since
the famous article "GOTOs considered harmful" people have gone
to any lengths to avoid gotos. Now we should make another rule:
DO use gotos when they make your code cleaner and simpler.
Juha
------------------------------
From: "Darren" <[EMAIL PROTECTED]>
Subject: Re: Startup service
Date: Mon, 30 Apr 2001 09:45:50 +0100
D. Stimits <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone else already answered this, but I thought it might be useful to
> add to it.
all input is welcome
>
> Darren wrote:
> >
> > D. Stimits <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Darren wrote:
> > > >
> > > > Hello all I am writing a small app that I want to run as a Linux
service
> > > > when it starts up. Can anyone tell me if I need any special
> > consideration
> > > > when writing a Linux tsr? also does one know which file it stores
the
> > info
> > > > on startup apps in?
> > > >
> > > > Thank you
> > > >
> > > > Darren
> > >
> > > There isn't really anything called a tsr in linux. It is just a
daemon.
> >
> > that would be typical of linux. so smooth and consistent :-)
>
> It does make programming and debugging easier.
yes
>
> >
> > > The typical daemon does a fork and exec after being started by an rc
> > > script.
> > whats the differece between a fork and an exec?
> >
> > For redhat, the script samples are in /etc/rc.d/init.d/. For
> > > other distributions, they are in an init.d directory, but it might be
> > > located somewhere else; I think SuSE uses /sbin/init.d/ or something
> > > like that. Programs that are not really system daemons but are desired
> > > to start each reboot often are just added in by editing
> > > /etc/rc.d/rc.local (again, location will vary with distribution, but
it
> > > is usually named rc.local). SuSE also has an rc script in /etc/ that
> > > yast uses.
> >
> > aha so it is rc.local i am looking for?
>
> If your only concern is to run some command at startup, yes.
it is mainly
If it must
> be controlled for start and stop activity at various runlevels, you'd
> create a script to go in the init.d subdirectory; then links from the
> various runlevel directories would determine whether the script is
> called with a start or stop at the given runlevels. inetd is a sample of
> something controlled at various runlevels, as well as a few other
> daemons. To see a list of what is controlled to start or stop, try this:
> chkconfig --list
> (chkconfig might not be available under all distributions, I haven't
> checked)
i have redhat 5.2
>
> >
> > >
> > > The scripts usually take arguments of "start", "stop", "status", and
> > > "restart". Symbolic links from various runlevel directories (e.g.,
> > > /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> > > process at those levels,
cool.
> > forgive me for being stupid, but i do not understand
>
> UNIX-style systems do not simply boot up or stop, they start or stop in
> stages. Stopped appears to always be runlevel 0, reboot runlevel 6. In
> between there is usually a single user mode (console only single user,
> good for some forms of disaster recovery), a multi-user console mode,
> and a multi-user graphics mode (X11). The exact number used for those in
> between levels varies with distribution. Sometimes there is further
> breakdown, such as single user console mode without networking, and the
> next mode up being single user still but with networking. If you use
> something like "ps aux" you will see process ID 1 is the grand parent of
> all processes, "init". The runlevel is the argument to init. If root
> calls "init 6", it will reboot; if root calls "init 0", it will halt.
aha, now i see :-)
> The startup scripts are calling init in a series of steps, and at each
> step, running scripts from init.d to start or stop services scheduled
> for those levels. rc.local is generally the last thing called in the
> bootup final runlevel destination, whereas init.d scripts can be
> automatically called with start or stop arguments at every level. Thus,
> if you only want to end up running something at the final bootup level,
> just add it to rc.local; if you want to make sure about a specific start
> or stop behaviour at each runlevel, put it in the init.d subdirectory
I get you! this is so cool! Linux is a babe!!!!
> and create the appropriate links (chkconfig can do this for you, take a
> look at the top comments in the init.d scripts).
>
> As an example, on redhat, if you have the cron daemon to run, root can
> type any of these:
> /etc/rc.d/init.d/crond status
> (returns its current status)
>
> /etc/rc.d/init.d/crond stop
> (stops cron daemon; error if it wasn't started already)
>
> /etc/rc.d/init.d/crond start
> (starts cron daemon; error if it was already started)
>
> /etc/rc.d/init.d/crond restart
> (stops then starts the cron daemon; error if it wasn't already started)
>
> On one redhat 6.2 system, "chkconfig --list | grep crond" shows this:
> crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
>
> This means that at runlevels 0, 1, and 6, crond is turned off, while
> runlevels 2, 3, 4, and 5 have it turned on. For redhat, runlevel 4 is
> never used, so it is actually irrelevant.
aha
> >
> > but if the sym link is done with a name
> > > starting with "s" it starts it at that level (your mileage may vary
> > > depending on distribution). Other complexities are that for security
it
> > > isn't unusual to arrange for the daemon to start as root but to be
> > > transferred for execution as user "nobody" (or some other less
> > > privileged user);
> > now this i understand. I do have need to have a process start at bootup
and
> > as all processes need a user connection then i need to create a virual
user
> > with priviledges to access only the required reources and attach the
process
> > to that user, if that makes any sense
>
> Yes, a lot of startup daemons are started by root, but transferred to
> ownership by a less privileged user. In terms of security, explicit
> testing and start or stop at each runlevel is probably the better way to
> go, versus rc.local, but as an end result you could do it either way
> (with rc.local being less complicated).
>
> D. Stimits, [EMAIL PROTECTED]
Thanks you have been very helpful.
> > and there is often some sort of lock file or pid file
> > > to let the system know what pid the process is at.
> >
> > Thank you for your reply D you have been most kind
> >
> > >
> > > D. Stimits, [EMAIL PROTECTED]
------------------------------
From: "Darren" <[EMAIL PROTECTED]>
Subject: Re: Startup service
Date: Mon, 30 Apr 2001 09:46:50 +0100
Cameron Kerr <[EMAIL PROTECTED]> wrote in message
news:RAJG6.1703$[EMAIL PROTECTED]...
> <snip>
>
> > whats the differece between a fork and an exec?
>
> Fork creates a child process. The created process is the
> same as the creating process, with no shared state, and
> same instruction pointers etc.
>
> Exec is used to replace the current process (usually in
> the child) with another process, overwriting the current
> process. No new process is created.
>
> <snip>
>
> > aha so it is rc.local i am looking for?
>
> If you want to create a standalone deamon. If you want
> the internet super-server (inetd or xinetd), it is much
> easier. You just write your program to use stdin and stdout
> as the input/output to the client. You then edit
> /etc/inetd.conf or /etc/xinetd.{conf|d/*} and restart
> the super-server by sending the -HUP signal
>
> killall -HUP inetd
>
> >> The scripts usually take arguments of "start", "stop", "status", and
> >> "restart". Symbolic links from various runlevel directories (e.g.,
> >> /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> >> process at those levels,
> > forgive me for being stupid, but i do not understand
>
> Virtually all GNU/Linux systems have a concept of
> "runlevels" (this is a System V concept). Runlevel
> 0 means "system shutdown", 6 means "system restart",
> 1 means "single user", 3 is typically "multiuser without
> the X Window System", 4 or 5 is usually the same as 3, but
> with GUI. Some of this is distribution independant. Look
> in /etc/inittab for the gory details.
>
> Anyway, on systems with SysV style setups (most), when
> a runlevel is changed, services are started or stopped
> according to the various symlinks. The best way to find
> out would be to look for yourself (try /etc/rc.d/rc[0123456].d/
> in Redhat. The system will automatically append "start"
> or "stop" to services that it needs to start or stop.
>
> In all, I suggest you read the following
>
> The GNU libc manual (ftp.gnu.org/gnu/Manuals/glibc)
> The Linux Programmers Guide (www.linuxdoc.org/guides)
> And constantly be on the lookout for any useful articles
> that teach you about certain things. You might find
> www.ibm.com :: Developer :: Linux :: Linux Articles
> useful. Also www.google.com :: Web directory :: * :: Linux ::
> Resources would be useful to you.
>
> Hope this helps
it does. Thank you Cameron
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
