Amiga.org
The "Not Quite Amiga but still computer related category" => Alternative Operating Systems => Topic started by: odin on August 25, 2007, 08:38:04 AM
-
I'm learning more about linux bit by bit, however the filestructure seems to be an overcomplicated mess. I'm looking to add something what I, were it an Amiga would add to s:user-startup.
What is a logical place to stick that on a Linux-based system? /var/lib/initscripts/ perhaps?
-
The main startup scripts are usually in /etc/init.d
Which scripts are called during startup depends on the runlevel (ie. whether you're starting up with a console or GUI, or some other arrangement). Different distributions often have their own 'user-friendly' methods for adding to the startup scripts, because runlevels can get rather confusing.
It's probably a good idea to use your distro's own method for adding a startup-script; if you try to do it yourself, it might not work (or might go wrong).
A busybox-based system (easily set up from scratch) dispenses with runlevels altogether and has a simple initscript: /etc/init.d/rcS
The Linux/Unix file structure actually makes a lot of sense. Don't forget, it's multi-user - if the Amiga was ever like this, you'd inevitably see something similar.
More details at: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
-
On debian or debian based distros (http://www.debian.org/misc/children-distros), man update-rc.d
-
The main startup scripts are usually in /etc/init.d
I'm also a Linux newbie and I'm wondering now what is the meaning of the ".d" extension ...
-
(Just guessing...) the .d extension for init.d indicates that it's a directory containing init scripts.
There are similarly named directories in /etc, such as conf.d and env.d, but I don't think the .d extension is a general rule.
-
Those scripts in turn launch daemons. in UNIX, a daemon is a service that runs in the background, providing a... well, a service. Examples are apache (the web server), dhcpd, etc.
If you see in UNIX (or MacOS, by the way, try Terminal in Finder, then ps -aux) anything ending in 'd', you can tell that's a daemon.
-
In Linux you have runlevels. A runlevel simply defines a group of scripts to be launched at startup. Say you run at runlevel 1. Then, your Linux system will execute all scripts in /etc/rc1.d.
If you have a closer look at /etc, you have the /etc/rc?.d directories. One for every runlevel, from 0 (shutdown) to 6 (reboot). This is the way a SYSTEM V UNIX should work. In those dirs you only have links to the real scripts, stored at /etc/init.d. To add a script in, say, rc3.d,:
cd /etc/rc3.d
ln -s /etc/int.d/
The scripts in /etc/rc?.d have a 'S' or a 'K' and a number. The number is an order number. The S means Start (to be executed when the system fires up) and K means Kill (Stop when the runlevel in ending)
After all this theory, really, the equivalen to User-Startup in the file .bashrc found in your $HOME dir. The other are the equivalent to Startup-Sequence
-
Hey, thanks for that! I didn't associate .d and daemons at first, so here's something new I learned today... :-D
-
.d does not mean daemon... you'll notice plenty of non-daemon .d directories such as php.d or yum.repos.d or profile.d... I dont know what it stands for (if anything at all) but it essentially means a subdirectory where certain similar configs (or subconfigs) are found. For example under /etc/rc.d you find directories for each runlevel configuration (rc).
You will not learn to use Linux by just messing around. At least, you will learn very slowly (as in years) and will get many things only partially right. Linux is, like any other unix, a very complex and powerful operating system. You need to read some manuals.
I *strongly* recommend (as in, if you dont, chances are you will give up in frustration) that you read some of the free online books at: http://tldp.org/guides.html
At the very least look at "Introduction to Linux"... but several of these will make your life MUCH easier.
There are several great print books too, a good start is the book "Running Linux" published by O'Reilly (see www.ora.com)
As for the original question, /etc contains most system-wide configuration and startup scripts. There can be other user-specific configs in your home directory.
-
If you use KDE 3 + and maybe even 2.x in /home/"loginname"/.kde is a directory called Auto Start drag the program you want to start to this directory and requester will come select link. It is exactly like the Amiga "Workbench Startup" directory.
The directoru should also be in your root directory /root/.kde/AutoStart
Hope this helps.
You do have to Show hidden files to see .xxx folders. :-D
-
You will not learn to use Linux by just messing around. At least, you will learn very slowly (as in years) and will get many things only partially right. Linux is, like any other unix, a very complex and powerful operating system. You need to read some manuals.
I would say that Linux is itself a gigantic programming language :-)
As an extra, is a great (robust) OS ;-)
-
@dfreniche,
About your signature : Don't worry about being an Amiga newbie. I visited some other platform forums and by comparison I realised people at amiga.org have none (or very very litle) arrogance. To say the truth (and sorry about this) I specially find the linux forums crowded of little arrogant people (most of them, there are exceptions of course) since some of them find themselfs like part of an elite (yes linux is not for all but that doesn't means linux masters cannot be helpfull and polite).
And thanks for your site and explanations (i'm linux newbie)
And welcome to the Amiga world!
-
The directoru should also be in your root directory /root/.kde/AutoStart
If you are doing most of your daily Linux user activity as root... do yourself a favor and STOP DOING THAT!!! That is perhaps the single stupidest thing you can do on any unix type system and is extremely extremely very super extremely much very dangerous and bad and not smart and dumb.
-
I specially find the linux forums crowded of little arrogant people (most of them, there are exceptions of course) since some of them find themselfs like part of an elite (yes linux is not for all but that doesn't means linux masters cannot be helpfull and polite).
I think the main reason for that is that the First Commandment of unix-like OSes is "RTFM!" Most common problems are due to people who ignore the manuals and just try to figure things out themselves. That doesn't work with Linux. When people show up asking repetetive questions which are clearly explained in various manuals, its sort of like if somebody keeps going to the hospital saying "I keep sticking a fork in my toaster and it keeps electricuting me, how do I keep the toaster from electrocuting me when I stick a fork in it?"
I've found that Linux forums are often very helpful and un-arrogant if you first read the manuals and then phrase your questions in ways that show you took the 5 minutes to read the instructions... assuming you even have a question still after reading the instructions. Chances are, the instructions alone are enough to answer your question.
-
@ptek
I love being a newbie. It's the only state of mind where you want to learn things all the time. I'm Amigan just since 2005 but I've used various flavours of MSDOS, Win, Linux, other UNIXes and MacOS. Why use only one system if you can try a bunch?
That said, i use Linux for everyday work and at home. It makes me feel comfortable. AmigaOS shocked me when I first try multitasking in an A500 unexpanded. I can connect it to my Linux box via serial port ! Then the frenzy started and now I own an A1200, an A600 and the 500. And use them everyday.
One of the biggest problems of "experts" is they take people out of their systems. If I start barking at someone for a basic Linux question, why anyone here should treat me with respect?
-
One of the biggest problems of "experts" is they take people out of their systems. If I start barking at someone for a basic Linux question, why anyone here should treat me with respect?
And why not? Why not a polite "Take a look at this <...> manual section. Hope this helps." ? Is there justification to rudeness? Personally I prefer an ignore attitude to rudeness...
"Basic questions" are of course relative taking in account different persons with different knowledge levels.
Take this example : Suppose one who is not a Linux user although have computer skills and ability to learn *but* (on PC side) prefers Windows since it allows generally do same job taking less time to the user. Suppose he would like to use the DSL distro since it's less than 50MB and run with 64MB RAM. DSL is designed to boot from a CD or USB key so the Internet favorites of the Firefox are not permanently stored. DSL can be installable on HD but in order to store the favourites, it needs some messing with config files, since all by default is saved to ram disk.
Does this person, who just would like to set up DSL for a basic task like surfing safely the Net for his dad (who could have an Windows installation infested by spyware and popups in less than 1 hour of browsing) have not the right to use basic questions about configuration? Considering he has only the sunday free from work and no time to learn the rudiments of linux?
OK, not expecting a full tutorial about it, just some hints to point at a starting direction since he presumly has the ability to think and learn.
PS : Take an example of completly rudeness like the answer of cbagger01 on (no I'm not who started the 60Hz thread)http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;hl=60hz (http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;hl=60hz)
And some guys like Grim find that arrogance pretty funny : http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;st=10 (http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;st=10)
(well I'm getting off-topic... better to shut up)
-
Why not a polite "Take a look at this <...> manual section. Hope this helps." ?
The assumption is that you should read the manual as the very first step in trying to set something up under a unix system. The sort of questions that tend to get rude responses on unix forums are ones which clearly show the person didn't read the manual before asking the question. You see their responses as rude, whereas they see it as rude that you ask questions before reading the manual. Whether or not it is right, in unix circles asking questions before reading the instructions is considered impolite and annoying. The fact is though that many questions are very clearly answered in the documentation for any piece of software you'll get in Linux. The documentation is in predictable places (manpages, source code readme files, etc).
There is also an assumption that you will learn the basics of the OS first. This generally means taking a Unix class in college or through work, or else self-educating yourself by reading some books like the ones I mentioned earlier. As with not reading software instructions, not taking the time to learn basics of the OS is seen as lazy and impolite... "We all had to read the manuals, you're no different." Again, this may not be right, but it is the usual attitude.
Informed and well phrased questions usually do get very polite and helpful responses from Unix people. There is a steep learning curve, but once you learn the stuff, it is incredibly powerful.
-
murple wrote:
I think the main reason for that is that the First Commandment of unix-like OSes is "RTFM!"
And read log files!
I've never EVER had to post on a forum to sort out a problem. Mostly because someone else had had the same problem and there was a solution, or because a comment or observation pointed the way to a solution.
In nearly every case, the answers are already 'out there', or in the manual or a log file.
-
Cutting and pasting logfile error messages to Google has solved 80% of my Linux problems. Good suggestion!
-
Ta for the answers folks.
Urgh. If only C= hadn't died.
-
Get started with the free online books at http://www.tldp.org and you'll get the hang of this real quick.
-
@murple
Not sure about the .d question. That's vital to me!
In the Debian tutorial is clear: everything ending in d is a Daemon.
Note all the commands ending in d --- such as kflushd and inetd --- the d stands for daemon[7]. A daemon is a non-interactive process, that is, it's run by the system and users never have to worry about it. Daemons provide services like internet connectivity, printing, or email.
The link to the quote (http://www.debian.org/doc/manuals/debian-tutorial/ch-basics.html)
By the way, a daemon is a"Disks And Extensions MONitor" :-)
So .d maybe is a reminder of history and evolution of UNIX. In those times, it was hard to send a ls -l and watch the teletype printing. Maybe the .d was used to make clear the dirs... but it's used mostly on dirs where daemon config files resides :lol:
...as it was discussed here (https://forums.gentoo.org/viewtopic-t-411925-view-next.html)
-
dfreniche wrote:
So .d maybe is a reminder of history and evolution of UNIX. In those times, it was hard to send a ls -l and watch the teletype printing. Maybe the .d was used to make clear the dirs... but it's used mostly on dirs where daemon config files resides :lol:
Although I think the .d extension has some history it is not what you think. Previously most of the configuration of the deamons was done in single text files in /etc. For example /etc/crontab used by the crond deamon to list a number of processes to run at certain points in time. This is not very modular as you need to remove/add parts to this file to change it.
Then directories that end in .d were introduced to indicate that the full configuration for the deamon is a concatenation of all the files in that directory (e.g. /etc/cron.d for crond).
This makes the task easier for package managers. If you have a package that contains a command that needs to run every night you only need to add a file in this directory and not run an installation script that adds those lines to /etc/crontab. Uninstalling is the same as you now only have to remove the file and not find the lines you added to /etc/crontab and delete them.
greets,
Staf.
-
@dfreniche
In the Debian tutorial is clear: everything ending in d is a Daemon.
Well, the tutorial is wrong there. There can easily be commands that end with d, and are not daemons. For example:
chmod
dd
ed
lsmod
mkmod
pwd
sed
depmod
insmod
parted
rmmod
cdrecord
find
head
hostid
id
ld
mkpasswd
passwd
groupadd
groupmod
useradd
usermod
So it should say "Note some of the commands ending in d ...", or so.
-
@Piru
Ok, lets blame on the Debian guys ! :-)
...and using
# find / -iname "*d"
is cheating ! :-D
I think in the tutorial they are talking about processes and not programs (you know, a process is a running instance of a program blah, blah).
But you're right, it's not expressed exactly as it is.
And the .d question. I know UNIX evolve from single file configuration (examples are /etc/inittab, /etc/passwd, /etc/group, ...) to multiple file configuration in SYSTEM V. So maybe the .d stands for "directory with configs" or "directory with configs plus daemons".
Are there any venerable UNIX Gurus (>20 years experience) that can help us with the .d mystery ? :-P
-
I've been using Linux (and Solaris, BSD, HP-UX, Irix, etc) for nearly 20 years.
In the Debian tutorial is clear: everything ending in d is a Daemon.
Well, many *programs* that end in d are daemons... for example, crond or dhcpd. Not all daemons end in d though, for example sendmail. And certainly many things end in d which are not daemons, for example sed or ld. Things that end in .d are NEVER daemons, but are configuration directories for the most part... For example, /etc/profile.d has nothing to do with daemons. In fact I would probably go as far as to say that most directories ending in .d are not daemon related.
In my /etc, these are not daemon related: bash_completion.d, dev.d, gre.d, ld.so.conf.d, libpaper.d, logrotate.d, lsb-release.d, makedev.d, modprobe.d, pam.d, profile.d, readahead.d, reader.conf.d, rwtab.d, sane.d, setuptool.d, and yum.repos.d
And these ARE daemon related: cron.d, init.d, rc*.d, netplug.d and xinet.d
I suspect .d is for "default."
Daemons, under the Linux File System Standard, will generally be located in /sbin or /usr/sbin, and while many daemon program names end in d, many do not. While daemon CONFIGS will be in /etc, no daemon or other program should be in /etc (not counting executable scripts).
daemon is a"Disks And Extensions MONitor"
Uhh, no. That is absolutely not true. A daemon is a background system process that does stuff, and comes from the Greek word for servant.
Just a quick glance at that Debian help file tells me you ought to go read the TLDP stuff instead. Not that the Debian file is wrong, but its not very clear and has some things that will be confusing to newbies.
You can tell much more about what kind of file a program is by where it is. The filesystem has a pretty clear structure that is defined in a standards doc. Search the net for Linux filesystem standard.
-
Well, many *programs* that end in d are daemons... for example, crond or dhcpd. Not all daemons end in d though, for example sendmail. And certainly many things end in d which are not daemons, for example sed or ld. Things that end in .d are NEVER daemons, but are configuration directories for the most part... For example, /etc/profile.d has nothing to do with daemons. In fact I would probably go as far as to say that most directories ending in .d are not daemon related.
In my /etc, these are not daemon related: bash_completion.d, dev.d, gre.d, ld.so.conf.d, libpaper.d, logrotate.d, lsb-release.d, makedev.d, modprobe.d, pam.d, profile.d, readahead.d, reader.conf.d, rwtab.d, sane.d, setuptool.d, and yum.repos.d
And these ARE daemon related: cron.d, init.d, rc*.d, netplug.d and xinet.d
I suspect .d is for "default."
Ok. As I answered to Piru, let's Blame the Debian help author. :-D
UNIX is inconsistent in many ways. Maybe the .d issue is just another symptom of a 30 years' old OS.
Daemons, under the Linux File System Standard, will generally be located in /sbin or /usr/sbin, and while many daemon program names end in d, many do not. While daemon CONFIGS will be in /etc, no daemon or other program should be in /etc (not counting executable scripts).
OK. That's described in the FHS. I agree.
daemon is a"Disks And Extensions MONitor"
Uhh, no. That is absolutely not true. A daemon is a background system process that does stuff, and comes from the Greek word for servant.
That is absolutely half true. Look a the WikiPedia definition of daemon. Both are valid.
http://en.wikipedia.org/wiki/Daemon_(computer_software) (http://en.wikipedia.org/wiki/Daemon_(computer_software))
Just a quick glance at that Debian help file tells me you ought to go read the TLDP stuff instead. Not that the Debian file is wrong, but its not very clear and has some things that will be confusing to newbies.
You can tell much more about what kind of file a program is by where it is. The filesystem has a pretty clear structure that is defined in a standards doc. Search the net for Linux filesystem standard.
Ooops! That sound me kind of RTFM ! :lol:
Ok, but I've not seen the .d issue covered anywhere Googling around. I know it's not that important, simply wanted to know why the ".d". I'm using Linux (and previously MINIX and a little AIX) since 1994. I don't consider myself a Linux newbie :lol:
-
I think the spelling mistake threw you off.
I did not tell him to put it in /root/.kde/AutoStart.
I told him to put it in /home/"username"/.kde/AutoStart. You are right but as a newbie he must be notified of the root path in case he does a search. If you read the note again it says to put the link in /home/"username"/.kde/AutoStart.
I never said I was or that he should log in as root (actually pretty hard on new linux dists as most require sudo and can not boot into root). Just telling him there are more than one folder that can have ,kde/AutoStart. Try chilling out. :-) :-)
-
Hi,
According to my Ubuntu Bible Manual,
In the /etc/inittab file, the default run level for your system is identified with a line containing the string initdefault, as in the following example:
id:2:initdefault:
In this case the default run level is 2. An additional entry in the /etc/inittab file identifies a command script that is run to initialize the system itself, as in the following example:
si:sysinit:/etc/init.d/rcs
NOTE: On Ubuntu systems the /etc/init.d/rcs command actually runs the /etc/init.d/rc command with an argument of S, which executes all of the scripts in the directory /etc/rcS.d that begin with the uppercase S.
So I would say that this is just a designation for each run level directory. Lot easier to modify small startup commands in a directory than to have one big glob to mess with.
My job is to make people angry, where did I go wrong on this one?
smerf