Sponsored Content
Full Discussion: Run Level 1, S and small s
Operating Systems Solaris Run Level 1, S and small s Post 302241373 by kumarmani on Monday 29th of September 2008 07:38:09 AM
Old 09-29-2008
Thanks Nua.

As per your definition

S:Single-user, booted to system console only, with only root filesystem mounted (as read-only)

s:Single user, identical to S except the current terminal acts as the system console

1:Single-user with local filesystems mounted (read-write)


if I execute df –h I can see the file system mount which are not part of root file system and after executing the run level as 1 I executing the command df –h I see the same output.

However I go the answer by searching is the forum and as per that if we go down from higher run level to lower run level. Say from init 3 to init 1 or init S/s system never goes to true level S/s. its only go that that level once we boot it from OK prompt with ‘boot –S or boot –s ‘. Also run level 1 need the good /etc/inittab where in same is not required by in the case of run level S/s.

Thanks Experts.
 

10 More Discussions You Might Find Interesting

1. Filesystems, Disks and Memory

Find run-level in solaris 8.

When the solaris 8 have come up, which command can find out the current run-level? thanks. (2 Replies)
Discussion started by: nianzhe
2 Replies

2. Solaris

Confusion In run level...

Dear Friends..!! i am quit confused about the SOLARIES RUN level that is 0 . 1 or s S ... please let me know the diffirence between these run level ... 0,1 and s S... have a great day Uday naikwadi (1 Reply)
Discussion started by: udayn
1 Replies

3. SuSE

Run Level Services file

Hello, I recently updated a test system from Suse 8 to 9.3. Now our runlevel services program doesn't work, but works fine on our other 9.3 boxes. We have a file in /etc/init.d/rc3.d called S99fooprog(not actual name ofcourse). It just has a command to start a program daemon up. Anyways... (3 Replies)
Discussion started by: benefactr
3 Replies

4. Solaris

How to get the initdefault run level in Solaris 10

Hi All, In Solaris 9 and below I will get the init run-level by checking the /etc/inittab entry is:3:initdefault: But in Solaris 10 we are using the smf functionality. Here how I can get the init default run level. Please help me in this problem. Regards, ... (2 Replies)
Discussion started by: kalpeer
2 Replies

5. Solaris

Difference between run level & init level

what are the major Difference Between run level & init level (2 Replies)
Discussion started by: rajaramrnb
2 Replies

6. UNIX for Dummies Questions & Answers

When the run level is changed from 5 to 3?

A Bourne Shell script is placed in /etc/rc.d/rc3.d called S57apache. What will happen with this script when the run level is changed from 5 to 3? many thanks (4 Replies)
Discussion started by: lemon_06
4 Replies

7. Solaris

Solaris 10 - Run Level Modification

Hello, I'm creating a VM Image of Solaris 10 on VM Player. I've completed the installation & I am using the Java Desktop as my default logon. I need to modify the Run Level to Console Mode (permanently). Unlike previous versions or Linux, modifying inittab file is not an option here. Please... (2 Replies)
Discussion started by: DevendraG
2 Replies

8. Shell Programming and Scripting

Perl - what run level

Is there a way to tell what runlevel is currently being used, for example is a user is using the gui or is the have pressed Alt+Ctrl+F1 to drop to the terminal?? (3 Replies)
Discussion started by: ab52
3 Replies

9. Solaris

Run level process when Physical server goes down

Need inputs when physical server is coming down (ex- init 0) . We have a physical server in that there are couple of LDOM's and in LDOM's there are couple of Zones . In zones there are applications running . Physical Server (T4 Server) -> LDOM -> ZONES -> applications There are scripts... (1 Reply)
Discussion started by: ajayram_arya
1 Replies

10. Solaris

Change run level at boot

for solaris 11, how does one change the run level at boot from 3 to 2? i checked "/etc/inittab" file where i usually change it in other *nix but it seems solaris is not using it. (1 Reply)
Discussion started by: badbanana
1 Replies
inittab(4)							   File Formats 							inittab(4)

NAME
inittab - script for init DESCRIPTION
The /etc/inittab file controls process dispatching by init. The processes most typically dispatched by init are daemons. It is no longer necessary to edit the /etc/inittab file directly. Administrators should use the Solaris Service Management Facility (SMF) to define services instead. Refer to smf(5) and the System Administration Guide: Basic Administration for more information on SMF. To modify parameters passed to ttymon(1M), use svccfg(1M) to modify the SMF repository. See ttymon(1M) for details on the available SMF properties. The inittab file is composed of entries that are position dependent and have the following format: id:rstate:action:process Each entry is delimited by a newline; however, a backslash () preceding a newline indicates a continuation of the entry. Up to 512 charac- ters for each entry are permitted. Comments may be inserted in the process field using the convention for comments described in sh(1). There are no limits (other than maximum entry size) imposed on the number of entries in the inittab file. The entry fields are: id One to four characters used to uniquely identify an entry. Do not use the characters "r" or "t" as the first or only character in this field. These characters are reserved for the use of rlogin(1) and telnet(1). rstate Define the run level in which this entry is to be processed. Run-levels effectively correspond to a configuration of processes in the system. That is, each process spawned by init is assigned a run level(s) in which it is allowed to exist. The run levels are repre- sented by a number ranging from 0 through 6. For example, if the system is in run level 1, only those entries having a 1 in the rstate field are processed. When init is requested to change run levels, all processes that do not have an entry in the rstate field for the target run level are sent the warning signal SIGTERM and allowed a 5-second grace period before being forcibly terminated by the kill signal SIGKILL. The rstate field can define multiple run levels for a process by selecting more than one run level in any combination from 0 through 6. If no run level is specified, then the process is assumed to be valid at all run levels 0 through 6. There are three other values, a, b and c, which can appear in the rstate field, even though they are not true run levels. Entries which have these characters in the rstate field are processed only when an init or telinit process requests them to be run (regardless of the current run level of the system). See init(1M). These differ from run levels in that init can never enter run level a, b or c. Also, a request for the execution of any of these processes does not change the current run level. Furthermore, a process started by an a, b or c command is not killed when init changes levels. They are killed only if their line in inittab is marked off in the action field, their line is deleted entirely from inittab, or init goes into single-user state. action Key words in this field tell init how to treat the process specified in the process field. The actions recognized by init are as fol- lows: respawn If the process does not exist, then start the process; do not wait for its termination (continue scanning the inittab file), and when the process dies, restart the process. If the process currently exists, do nothing and continue scanning the inittab file. wait When init enters the run level that matches the entry's rstate, start the process and wait for its termination. All subsequent reads of the inittab file while init is in the same run level cause init to ignore this entry. once When init enters a run level that matches the entry's rstate, start the process, do not wait for its termination. When it dies, do not restart the process. If init enters a new run level and the process is still running from a previous run level change, the pro- gram is not restarted. boot The entry is to be processed only at init's boot-time read of the inittab file. init is to start the process and not wait for its termination; when it dies, it does not restart the process. In order for this instruction to be meaningful, the rstate should be the default or it must match init's run level at boot time. This action is useful for an initialization function following a hard- ware reboot of the system. bootwait The entry is to be processed the first time init goes from single-user to multi-user state after the system is booted. init starts the process, waits for its termination and, when it dies, does not restart the process. powerfail Execute the process associated with this entry only when init receives a power fail signal, SIGPWR (see signal(3C)). powerwait Execute the process associated with this entry only when init receives a power fail signal, SIGPWR, and wait until it terminates before continuing any processing of inittab. off If the process associated with this entry is currently running, send the warning signal SIGTERM and wait 5 seconds before forcibly terminating the process with the kill signal SIGKILL. If the process is nonexistent, ignore the entry. ondemand This instruction is really a synonym for the respawn action. It is functionally identical to respawn but is given a different key- word in order to divorce its association with run levels. This instruction is used only with the a, b or c values described in the rstate field. sysinit Entries of this type are executed before init tries to access the console (that is, before the Console Login: prompt). It is expected that this entry will be used only to initialize devices that init might try to ask the run level question. These entries are executed and init waits for their completion before continuing. process Specify a command to be executed. The entire process field is prefixed with exec and passed to a forked sh as sh -c 'exec command'. For this reason, any legal sh syntax can appear in the process field. SEE ALSO
sh(1), who(1), init(1M), svcadm(1M), svc.startd(1M), ttymon(1M), exec(2), open(2), signal(3C), smf(5) System Administration Guide: Basic Administration NOTES
With the introduction of the service management facility, the system-provided /etc/inittab file is greatly reduced from previous releases. The initdefault entry is not recognized in Solaris 10. See smf(5) for information on SMF milestones, and svcadm(1M), which describes the "svcadm milestone -d" command; this provides similar functionality to modifying the initdefault entry in previous versions of the Solaris OS. SunOS 5.10 9 Dec 2004 inittab(4)
All times are GMT -4. The time now is 05:15 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy