Date: Mon, 18 Apr 2011 15:57:19 +0200 From: Paul Schenkeveld <freebsd@psconsult.nl> To: freebsd-hackers@freebsd.org Subject: Re: Add SUM sysctl Message-ID: <20110418135719.GA89086@psconsult.nl> In-Reply-To: <20110418.115215.546.1@DEV> References: <8CDCA9824BFE47E-176C-A720@web-mmc-d04.sysops.aol.com> <alpine.BSF.2.00.1104161634150.5936@wonkity.com> <20110416233839.GA72223@DataIX.net> <E1QBQoh-000EDX-AP@kabab.cs.huji.ac.il> <20110418.115215.546.1@DEV>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 18, 2011 at 01:52:15PM +0200, rank1seeker@gmail.com wrote:
>
> There are 2 ways of going into SUM (Single user mode)
> 1) Rebooting into it
> 2) Drop from MUM
>
> My solution MUST cover both cases, of entering into SUM.
>
> Once I enter SUM, I set it up, via 1 script, which enables deamons and other stuff, that I need, for certain task. (i.e; I wana use mouse, so I activate moused ...)
> Now, after those steps, if that machine is web server, which serves only static content, then enabling apache, makes it fully functional server, in SUM!
> I see now, that both SUM and MUM define BOOTED/STARTED/RUNNING FreeBSD. -> Thx, to Daniel O'Connor, for pointing into this direction.
> So SUM defines basic functionality and MUM ...
> So where is a BORDER of SUM and MUM. How many "stuff" has to be enabled/activated to decalre it as MUM, instead of SUM?
> Where does exactly SUM, becomes MUM. As long as kernel is being asked, it doesn't differentiate between SUM and MUM.
> Kernel "sees" amonut of "pressure" induced by deamones, users, processes.
>
> Now to cut that chatter short, to solution ...
>
> I've tried by looking at init state:
> # ps -U root | grep 'init -s'
> BUT, after exiting into MUM, from SUM:
> SUM->MUM (/sbin/init -s) 'init -s' remained.
> If sys booted directly into MUM, I see (/sbin/init --), which also remains upon drop to SUM.
> So init state can only be used, to determine, how sys has been booted/started.
>
> To cut it even shorter (skipping tried sysctl vars, env, etc ...)
>
>
> Solution, which passed my requirement, was one from J. Hellenthal's advice.
> Thx!
> It works, with both cases of entering into SUM.
> Also covers case, where I enable stuff, that I need in SUM and which could confuse function, into thinking it is in MUM.
>
>
> Here is an resulting function: (/bin/sh)
> --
> # Are we in a SUM
> in_sum ()
> {
> if [ "`/bin/pgrep -x getty`" ]; then
> return 1
> else
> return 0
> fi
> }
> --
Which works in most cases except:
1. You have disable getty in /etc/ttys because the system is headless.
2. You have logged in to all virtual consoles so all getty processes
have been replaced by login shells.
My personal conclusion after 25+ years of UNIX system administration is
that:
1. System V supports runlevels to distinguish between SUM and various
levels of MUM but that is not waterproof. Linux supposedly have
adopted the System V runlevel concept.
2. BSDs traditionally do not have a clear line between SUM and MUM, for
example, when going back from MUM to SUM, some processes that
were started in MUM keep running, filesystems are still mounted
and things configured for MUM are not de-configured. Also during
transition from SUM to MUM, when rc encounters an error, it
will drop into a "twilight zone" kind of SUM where some MUM
initialisation is completed but not all of it.
3. To be really safe, you should check for everything that should not
be running/mounted/configured before doing "dangerous stuff" (TM)
and not rely on a single test that may result in false positives or
false negatives.
Personally I seldomly drop into SUM via shutdown but prefer to reboot
into SUM.
My $0.02
Regards,
Paul Schenkeveld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110418135719.GA89086>