On Wed 01 Jun 2016 at 14:47:11 (-0000), Dan Purgert wrote: > Mark Fletcher wrote: > > --001a114056c6437ae5053437ad41 > > Content-Type: text/plain; charset=UTF-8 > > > > On Wed, Jun 1, 2016 at 9:10 PM Dan Purgert <d...@djph.net> wrote: > > > >> Lisi Reisz wrote: > >> > On Tuesday 31 May 2016 23:56:02 Richard Hector wrote: > >> >> On 01/06/16 07:31, Lisi Reisz wrote: > >> >> > Now to do what I really wanted to do all along, and ssh in to run > >> level > >> >> > one as root:
Could I take the liberty of requoting an earlier version of this statement: "Now to do what I really wanted to do all along, and ssh in to run level one as root: [...] "[...] This was the point of the whole exercise. I want CLI only (no X running) access to the Ubuntu installation on Hermes." AIUI one can configure a box to run X in all runlevels but 1; however, there's no need to do it that way. None of my machines run X automatically at runlevel 2: I have to use startx. > >> >> > lisi@Tux-II:~$ ssh root@192.168.0.5 > >> >> > ssh: connect to host 192.168.0.5 port 22: No route to host > >> >> > lisi@Tux-II:~$ ssh lisi@192.168.0.5 > >> >> > >> >> Run level one? AKA single user mode? I wouldn't expect to find sshd > >> >> running in single user mode. Without checking, I'm not sure I'd even > >> >> expect networking to be up. > >> >> > >> >> Richard > >> > > >> > Yes, I had come to the conclusion that that was probably the problem. > >> > Networking does appear to be up since nmap found a host having scanned > >> > the ports. > >> > >> You'll need to reset the init script to fire at runlevel 1. Not sure > >> how you go about this in a systemd setup. > >> > >> That being said, the 'init' manpage has the following warning: > >> > >> # On a Debian system, entering runlevel 1 causes all processes to be > >> # killed except for kernel threads and the script that does the killing > >> # and other processes in its session. As a consequence of this, it isn't > >> # safe to return from runlevel 1 to a multi-user runlevel: daemons that > >> # were started in runlevel S and are needed for normal operation are no > >> # longer running. The system should be rebooted. > >> > >> I'm not sure if this holds for systemd-init though. > >> > >> > >> > > To add to that, and not to make value judgements, but the point of > > Runlevel 1 is that it is single user mode. The whole point is that > > there is only one person logged in, _via the console_, and no one else > > can be logged in doinanything, and therefore it is safe to perform > > maintenance like taking disks offline to back them up (back in the > > days when that was the main / only way to do it) or other similar > > maintenance tasks. > > > > So, running the ssh daemon in Runlevel 1 is like, well, like trying to fit > > brake blocks to a tomato. It just doesn't make a lot of sense. I think I > > missed what you were actually trying to do but does it really need to be > > done in Runevel 1? Because Runlevel 1 and remote access to the machine > > aren't concepts that belong in the same sentence, at least without a > > negative. > > > > Sorry, probably not what you wanted to hear but... > > I came "late" to the party myself, and missed the post where I imagine > why Lisi is after runlevel 1. > > Personally, with the exception of my laptop, everything starts in > runlevel 3 here. IIRC Debian has always left it to the admin to make runlevels 2 and 3 distinct from one another. (OTOH I've never thought about how to implement that in either sysvinit or systemd.) I have a couple of other queries for Lisi though. Is it particularly important that X is not running at all on host A when logging in as root from host B? (After all, you still get a CLI on host B.) And if it is, would it be sufficient for root to pkill xinit (or, as I do: pkill xinit; sleep 5; kill -KILL xinit) if and when required? Cheers, David.