LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 02-06-2009, 07:26 AM   #16
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,646

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828

Quote:
Originally Posted by GazL View Post
In this case, the change is fairly self evident.
Code:
sed -e 's:\. /etc/rc.d/rc.:/bin/sh /etc/rc.d/rc.:g' /etc/rc.d/rc.M
I do not see what is your point here. What is the practical advantage of replacing scripts' sourcing by scripts' running ?
 
Old 02-06-2009, 07:32 AM   #17
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Quote:
Originally Posted by Didier Spaier View Post
I do not see what is your point here. What is the practical advantage of replacing scripts' sourcing by scripts' running ?
The point is that some people may run customised rc scripts. The original poster is a case in point. He used non-standard rc.httpd which included a 'exit' which broke rc.M. By changing them all to run in their own shell process, you protect rc.M from customisations to the files it calls. It's a very minor change, but it's all about resiliency. If you run the standard rc.'s you have no problems with it as long as everything is stock, but I'm a belt and braces guy when it comes to things as important as system starup scripts.
 
Old 02-06-2009, 07:47 AM   #18
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,646

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Quote:
Originally Posted by GazL View Post
The point is that some people may run customised rc scripts. The original poster is a case in point. He used non-standard rc.httpd which included a 'exit' which broke rc.M.
IMHO, if someone replaces or edit a startup script, he/she should be wise and skilled enough to prevent possible unwanted side effects of his/her changes.

Is that so difficult e.g. to type "grep rc.httpd /etc/rc.d/*" and check the output ?

Last edited by Didier Spaier; 02-06-2009 at 07:48 AM.
 
Old 02-06-2009, 07:56 AM   #19
piete
Member
 
Registered: Apr 2005
Location: Havant, Hampshire, UK
Distribution: Slamd64, Slackware, PS2Linux
Posts: 465

Rep: Reputation: 44
Would you not have to replace all the /path/to/binary portions of the rc scripts with `exec /path/to/binary` to stop having a bajillion spawned shell processes?

Also spawning a new shell for everything would affect 'global' variables like PS1, PATH, etc, to the extent that they would never appear in any scope other than the one that was spawned (and has maybe since been exec'd away).

I sympathise with the OP that his rc.M broke, but it broke because of poor understanding of the startup mechanisms. Knowing that (by default) startup scripts are all sourced and modifying your custom scripts to match the default is surely a better method than rewriting the entire init procedure to match some generic scripts that have been written as an example. Likewise, knowing that you can change rc.M where you prefer your own scripts to the 'official' ones is also a valid approach, which has been applied successfully I think to solve the OP's original problem.

For discussions on source vs shell, maybe a new thread would be a plan get the best exposure?

- Piete
 
Old 02-06-2009, 08:48 AM   #20
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by Didier Spaier View Post
I do not see what is your point here. What is the practical advantage of replacing scripts' sourcing by scripts' running ?
1. To prevent namespace pollution. This one benifit is good enough.

2. More friendly to non-sh scripts. For example, "rc.udev" is a bash-only script. I myself would also like to use python, in which case "source" is nonsense. If everything is run directly, the calling command need not be changed even if the interpreter changed, or even if the script is replaced by an ELF program. I have both cases in my /etc/rc.d/

I usually write a new script with sh; then when it grows, if I find difficulty, I change to python; in the end, if I think the script needs no more change, I sometimes re-write it in C. Because I don't use "source", the "rc.*" scripts themselves need not be changed.

Last edited by guanx; 02-06-2009 at 09:07 AM.
 
Old 02-06-2009, 09:17 AM   #21
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,112

Rep: Reputation: Disabled
I think if you decide to mess with the Slackware default scripts, you should be prepared to change anything that prevents total disaster. If you change scripts and add "exit" statements, you are responsible for changing the source-ing to spawning an external shell for the script's execution. Using python during early bootup is certainly not recommended because of the library files it needs in /usr/ ... you can not be certain (when you write scripts to be used on many different computers) that the /usr directory is available that early. It may be on a separate partition which is only mounted later.

Slackware's rc scripts will likely remain as they are, since I have not heard a good reason why they should change. Spawning a subshell will make the boot stage's shell environment unavailable to the script. Variables set of changed inside the script would vanish once the script ends.

Eric
 
Old 02-06-2009, 09:29 AM   #22
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by Alien Bob View Post
I think if you decide to mess with the Slackware default scripts, you should be prepared to change anything that prevents total disaster. If you change scripts and add "exit" statements, you are responsible for changing the source-ing to spawning an external shell for the script's execution.
It was not me who put "exit" into the script ... Nevertheless, you can see in newer versions of Slackware that many startup scripts are really sh-ed instead of source-ed.

I think it will be even better to omit the sh. "/etc/rc.d/SCRIPT_NAME" is enough because some scripts, e.g. "rc.udev", is not sh-compatible (rc.udev is bash-only).

Quote:
Using python during early bootup is certainly not recommended because of the library files it needs in /usr/ ... you can not be certain (when you write scripts to be used on many different computers) that the /usr directory is available that early. It may be on a separate partition which is only mounted later.
Yes. I can be quite sure "/usr" is mounted early enough. You can find a lot of things if you "grep -l /usr/sbin /etc/rc.d/rc.*".

Quote:
Slackware's rc scripts will likely remain as they are, since I have not heard a good reason why they should change. Spawning a subshell will make the boot stage's shell environment unavailable to the script.
Not true. The spawned shell will inherit the environment variables from the calling shell.

Quote:
Variables set of changed inside the script would vanish once the script ends.

Eric
What are these variables? I mean the "useful" ones, i.e. the ones will be used by subsequent scripts.

If you must export variables, I think it's better to do it this way:
Code:
# ******* This is /etc/rc.d/rc.M ********
if [ -x /etc/rc.d/rc.servars ]; then
  `/etc/rc.d/rc.setvars`
fi
Code:
#! /usr/bin/env python
# ******* This is /etc/rc.d/rc.servars *******
import sys, os
sys.stdout.write('export TMP_MAX=%u' % os.TMP_MAX)
sys.stderr.write('This is %s\n' % sys.argv[0])

Last edited by guanx; 02-06-2009 at 10:47 AM.
 
Old 02-06-2009, 09:44 AM   #23
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,646

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Guanx, my guess is you won't convince Slackware team to make the changes you propose.

But nobody prevents you to fork Slackware -- you would not be the first, anyway.

Meanwhile I will stick to the original

Cheers,
 
Old 02-06-2009, 10:36 AM   #24
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by Didier Spaier View Post
Guanx, my guess is you won't convince Slackware team to make the changes you propose.

But nobody prevents you to fork Slackware -- you would not be the first, anyway.

Meanwhile I will stick to the original

Cheers,
I am not talking about what they should do. I am simply suggesting which is better :P

Actually, Slackware has already changed many "source SCRIPT_NAME" commands in "rc.M" and alikes to "sh SCRIPT_NAME". This means there are not so may environment variables to export as Eric thought. Preventing namespace pollution is more important.

Now because the scripts are not source-ed generally, if I want to use python instead sh, I can write the script this way:
Code:
#! /bin/sh

"exec" "python" "$0" "$@"
print 'This is Python'
It works as long as you don't "source" it. Furthermore, if you run it directly without specifying the interpreter, this ugly trick can go away and the code will look more beautiful.

Last edited by guanx; 02-06-2009 at 03:34 PM.
 
Old 02-06-2009, 03:08 PM   #25
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Quote:
Originally Posted by Alien Bob View Post
I think if you decide to mess with the Slackware default scripts, you should be prepared to change anything that prevents total disaster. If you change scripts and add "exit" statements, you are responsible for changing the source-ing to spawning an external shell for the script's execution.
I agree, one should expect people making customisations to get it right, but having a consistent approach, i.e. calling all the sub scripts in the same manner, will help them get it right. As was mentioned above some are currently sourced into the current shell of rc.M and some are run in a new shell. It's a mess. It works, but it's clearly not tidy!

Then you have the issue of fault tolerance. Expecting someone making customisations in sub scripts to get it right is reasonable enough, but what's so wrong with making rc.M able to cope with errors regardless. It's just sound design and good programming practice.

Actually, on reflection, I like guanx idea of not even prefixing them with the shell at all and letting the interpreter string identified within the script file determine what executable is used to run it.



Quote:
Originally Posted by Alien Bob View Post
Using python during early bootup is certainly not recommended because of the library files it needs in /usr/ ... you can not be certain (when you write scripts to be used on many different computers) that the /usr directory is available that early. It may be on a separate partition which is only mounted later.
We're talking specifically about rc.M and the subsystem scripts such as rc.httpd called from it. Filesystems will have already been mounted by this point.

Quote:
Originally Posted by Alien Bob View Post

Slackware's rc scripts will likely remain as they are, since I have not heard a good reason why they should change. Spawning a subshell will make the boot stage's shell environment unavailable to the script. Variables set of changed inside the script would vanish once the script ends.
The rc.whatever sub scripts are all designed to be run individually, so that subsystems can be stopped/started manually. So, passing environment variables back and forth shouldn't be an issue. Wouldn't any requirements to pass environment variables between several scripts break this functionality?


If you want to take the line that: it's 'good enough' as it is and doesn't need changing, then that's fair enough, but that doesn't mean that these suggestions are without merit.

I can see that guanx is on the same wavelength as I am here, I guess I'll have to settle for that.
 
Old 02-11-2009, 03:51 AM   #26
bsurfin
Member
 
Registered: May 2004
Location: Kalispell Montana
Distribution: Kubuntu ( Current Version )
Posts: 112

Rep: Reputation: 15
I Have Slackware 12.1 running really fast and flawlessly on my new Dell laptop, I used the command above: mysql_install_db , and it got my mysql server working pretty much instantly. What script can I use to get the mysql server to boot when I boot the laptop up ?

Does Slackware have a command to run a process manager?

Last edited by bsurfin; 02-11-2009 at 03:57 AM.
 
Old 02-11-2009, 04:14 AM   #27
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,724

Rep: Reputation: 449Reputation: 449Reputation: 449Reputation: 449Reputation: 449
I haven't checked the init scripts in question, but I suspect that the fact that some are simply sourced while others are run in a separate proces (using sh)has to do with whether the called process runs as a backgrounded daemon or not. If you source a script which starts a process which does not background itelf, then the init process would hang right there. Such a process would have to be run with a separate process to allow the normal bott process to continue.
 
Old 02-11-2009, 11:45 AM   #28
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.0, 13.1, 13.37, 14.0, 64-14, -current
Posts: 1,509

Rep: Reputation: 499Reputation: 499Reputation: 499Reputation: 499Reputation: 499
Quote:
Originally Posted by bsurfin View Post
What script can I use to get the mysql server to boot when I boot the laptop up ?

Does Slackware have a command to run a process manager?
Slackware uses BSD-style process management. You manage boot processes primarily by setting the execute status of scripts in /etc/rc.d/, and possibly by edits of /etc/rc.d/rc.local.

To make MySQL start at boot simply make /etc/rc.d/rc.mysqld executable. As root...
Code:
chmod 755 /etc/rc.d/rc.mysqld
To 'turn off' any process...

Code:
chmod 644 /etc/rc.d/rc.script_name
...with the desired script name.
 
  


Reply

Tags
apache, bash, mysql, rc, scripts, server, shell, startup


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Break scripts as a learning tool? GarKing Linux - Newbie 1 06-28-2008 05:46 PM
A lot of agetty, httpd and mysqld processes ilhbutshm Slackware 3 09-04-2006 12:49 PM
disabling mysqld and httpd webinsek Linux - Newbie 3 03-25-2006 12:13 PM
mysqld on startup... dark poet Linux - Newbie 8 10-05-2003 12:16 AM
mysqld fails on startup wiseraptor Linux - Newbie 0 02-07-2003 03:42 PM


All times are GMT -5. The time now is 06:50 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration