Monday, August 7, 2017

systemd action 9 suspended


getting systemd action 9 suspended.

Hint here:

https://askubuntu.com/questions/108924/missing-dev-xconsole-causes-rsyslog-to-stop-as-well-as-all-other-services

https://unix.stackexchange.com/questions/168215/create-several-dev-xconsole-files-automatically-upon-boot

https://devcentral.nasqueron.org/T806
"Root cause: rsyslog was trying to use xconsole, a program not installed, to send some logs to."

seems to have vanished after installing xterm, though not clear why.

/etc/init.d/rsyslogd has code to create /dev/xconsole (which is supposedly the problem it's missing) by linking /run/xconsole to /dev/xconsole.

After installing xterm they are both still missing.

Note: this system is a server configured system with xfce4 xrdp and tightvnc installed to give remote access.  Suggestion that xterm was missing is in other online hints.

Sunday, August 6, 2017

XRDP failure log message: connecting to 127.0.0.1 5910 error - problem connecting


The messages

connecting to sesman ip 127.0.0.1 port 3350
sesman connect ok
sending login info to sesman
login successful for display 10
started connecting
connecting to 127.0.0.1 5910
error - problem connecting


Printed in the dialog box when attempting to connect to an XRDP enabled system.

The latter problem implies a connectivity problem, which couldn't be further from the cause.

Many sites insist that installing XRDP, vncserver (of some sort) in one order or another is the problem.  Also misleading.

Then you look in xrdp-sesman-log in /var/log, you will see this

[INFO ] starting Xvnc session...
[ERROR] X server for display 10 startup timeout
[INFO ] starting xrdp-sessvc - xpid=3531 - wmpid=3530
[ERROR] X server for display 10 startup timeout
[ERROR] another Xserver is already active on display 10
[DEBUG] aborting connection...[20130627-08:55:49]
[INFO ] ++ terminated session:  username root, display :10.0, session_pid 3529, \
      ip 192.168.0.227:59050 - socket: 7

Indicating that somehow your RDP session has two Xservers active.  What happens when you log in is that a login method is performed to authenticate, and the top dialog indicates the progress of that.

Then it will spawn some VNC server session for the X session (uses 10, 11, etc.) to connect.

If you read the symptoms here, there is already a session or server on 5910.  Completely wrong.

To find the problem, one has to try running the window manager.  I don't know if this would happen for other than xfce4, which I use, but it produces the root problem.  run:

If you try running vncserver, you will see at the end of the startup this:

[dix] Could not init font path element /usr/share/fonts/default/Type1, removing from list!
[dix] Could not init font path element built-ins, removing from list!

Fatal server error:
could not open default font 'fixed'

Turns out that if any failure occurs in the chain of events between the authentication after the RDP login and getting the session going, you get the " Xserver is already active on display" message in the var log sesman log.

Other errors I suspect produce the same nonsense, someone reported when the vnc server and client couldn't agree on a geometry, the same error occurred.

This is probably the solution to all the load order issues and which vnc server (real or tight) package you use.

quoting:
I have solved it by installing xfonts-base

This also solved my problem.

set static IP from command line gui Armbian / Debian 7 Orange Pi Zero 512


Recently I acquired a couple of OrangePi Zero 512's, with a network phy, and dual usb.  The latter is not terribly useful because w/o modification to physically drive in more +5 there isn't much 5 v to spare on either port of this board.  It is powered by a USB OTG micro port, which at most will draw 2.1A.

The armbian comes up with the root password set to "1234" and a script to force changing the password at first login.  One can log in to either the serial port (presented on the OTG as a USB serial), you may wire in a serial port, or ssh into the unit once you find it.

The latter is a bit of a problem, however.  For whatever reason the current armbian is set up to assign a random crap MAC address to the board.  There is no retention of a MAC in any storage, so that isn't a huge problem.  However, the MAC must be being set early enough that there isn't any of the static storage of the root available, so no static address.

Against my desire and policy here, I decided to set a static IP to the board, which skirts the need for a static MAC.  I usually like to have everything DHCP so I can change any device by the dhcp server, but static IP will work to get round this.

to set the IP, one has to edit the ip with the network manager.  the network manager may be edited with the nmgui command.  Edit the ip from automatic to manual, and set up the IP.

The only caveat that needs to be recalled is that there is no netmask.  The gui uses the format of
192.168.0.1/24 or such to set the netmask.  Kind of against command line and file standards, but that took some hunting for when the setup failed for me a few times.  And there is no netmask prompt.

One can either reboot the system, or restart the network manager.  Seems like on a systemd type system this does that task

sudo service network-manager restart

********* on the topic of armbian  ****

this method didn't work for the orangepi to change the configuration.  Should work on some form of debian, but somewhere else must be some network code setup on armbian that ignores the settings in the /etc/networking directory configuration files.  Has no effect at all.

https://kuziel.nz/notes/2017/01/orange-pi-zero-armbian-setup.html