post boot startup scripts

Going into "X", there are ways to run startups for various GUI applications. But what about at boot time? GRUB/LILO's job is only to initialize the kernel and the system: booting apps are not the way to, say, run an app that connects to wifi or runs a cron job. How to do? My ugly solution is a text rc.local file, added with a second step of creating and attaching a systemd service. Prior to systemd, in less complicated Linux years, we could create text app init files inside /etc/init.d/.

/etc/rc.local

There are more elegant ways (eg. as argued here) to connect to the web at startup, but let's use web connection as an easy rc.local example app, then pick your own application(s) to put into rc.local.

# nano /etc/rc.local
#!/bin/bash
echo "router connect"
wpa_supplicant -iwlan0 -Dwext -B -c /etc/wpasupplicant/wpa_supplicant.conf
exit 0

# chmod 755 /etc/rc.local

... or some like to just "+x" it.

/etc/systemd/system/rc-local.service

Next, create a systemd service file to call rc.local. As well noted here, the file must include a "wanted by" line.

# nano /etc/systemd/system/rc-local.service
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

... and then enable the service in systemd...

# systemctl enable rc-local.service

The next time the system boots, it subsequently runs the rc.local file and connects to the router.

boot crashes, x crashes, video crashes, mouse crashes, kernel panics

A friend has an old (c.2011) HP box that was running Arch.

boot hang

Endless possibilities. Here are some ways I've seen it solved

• Solution: # systemctl disable dhcpcd.service. Symptoms: Boot hang with thousands of lines of fails including cgroup fails with appearance the OS or systemd are corrupt. Real source: dhcpcd.service attempts to autoconnect at startup. If it times out, eg, there's no ethernet cable, systemd interprets this nuisance as a fatal f*cking error. Nevertheless it continues to run its boot script, failing every subsequent step, and generating thousands of lines of spurious errors. Time: an entire Saturday, until lucked into it around line 1500 of an arch-chrooted (from USB) journalctl -r.

x crash

Buddy was uses Wikimapia and Google Maps in two open browser tabs. He thought "these are just websites, why does my system keep locking up", but of course he had selected perhaps the two most polygon intensive sites on the Web about which to make such a claim, and he was moving his mouse at video game speeds. All this on a 2011 HP with onboard G31 chip graphics. Little wonder the persistent failures, mostly of two varieties: 1) lockups, and 2) exit to terminal with kernel panics. Some possibilities:

1. xorg setting for video card
2. xorg setting for mouse
3. browser leaks with multiple many-polygon pages open (maps)
4. the old Intel 82G33/G31 integrated controller card being overwhelmed
5. ?

logs

We're looking for two main log types: Xorg crashes, and Kernel crashes. Xorg is the easiest -- hasn't changed much over the years. We can still find Xorg logs in /var/log/Xorg.0.log.old and copy to our user directory to read them in any text editor. Failures stand out, and there is usually enough information to start modifying one's xorg.conf file to fix whatever's wrong. In the case of my friend, it appears there was nothing failing and writing to Xorg.log, at least on a first-look.

Kernel crashes. During crashes, writing can be inconsistent; we can't be certain we'll have information. Additionally, journald crash logs are written in binary and, further, compressed, and so require the journalctl client to read whatever's in there (and of course "whatever's in there" can become corrupted during a panic). So it's 50-50 if we can see anything in these logs. IMO, verifying a corruption-free log is the place to begin.

# journalctl --verify

...in the case of my friend's logs, this revealed a plethora of corruptions at times I could not decipher, but may have corresponded to the panics.

Given all of this, it appeared the best thing to do was get some text readable log information.

# nano /etc/systemd/journald.conf
Storage=none
ForwardToSyslog=yes

...next crash, I should be able to see if there's anything out there in human readable text. Meanwhile...

# journalctl -b

... and look for errata.

video card

On the video card front, his old Intel 82G33/G31 is onboard and shares memory (fatal), but also appears to have some VRAM. No GPU.

[solved] .xinitrc - include startup programs?

Many Linux users, are in a GUI environment from startup to shutdown. They are in a GUI GDM before they enter their Window Manager Desktop Environment.

Others login to runlevel 3 so we can view startup messages before moving into runlevel 5. When we're satisfied with boot messages, we use "$ startx". Startx of course initializes X via the local file "/home/[user]/.xinitrc. Its final line calls whatever windows manager we want to use. So, for example, the last line in .xinitrc might be "exec twm", for those who use twm. Users can also include any other programs prior to that last line, as long as they fork them to background ("&") so the script isn't waiting for that program to exit before the next line is executed. A simple .xinitrc could be the following:

$ cat .xinitrc
# ~/.xinitrc
# set editor to nano
export EDITOR=nano

# clipboard app
/usr/bin/clipit &

# volume app
/usr/bin/volwheel &

# Tom's Window Manager
exec twm

A potential problem occurs for this group of people using "runlevel3 + startx". Because .xinitrc runs through a list of whatever apps the user wants and then loads the windows manager, the actual initialization of X11 is happening at the same time these programs are being called. Sometimes there's a conflict.

solution

Desktop Environments and some Windows Managers (eg. Cinnamon) allow users to configure startup programs via some sort of client, typically called "startup applications" or some such, which the user configures for their next boot. More generically, the answer is probably a /etc/rc.local file to run at startup, which I cover in this post.

Either way, one definitely should keep their .xinitrc simple: have it load the windows manager without adding applications. Instead, find which other scripts are called when the window's manager loads. Icewm has a nice way of handling this. If one uses "exec icewm-session" in their .xinitrc, icewm checks for a script the user can create called ~/.icewm/startup. For example, I tried this script with good results...

$ cat .icewm/startup
#!/bin/bash
# chmod from 644 to 755 - must be executable to be read by icewm-session

sleep 4
synclient TouchPadOff=1
xgamma -gamma .7
volwheel &
sleep 1
clipit &
sleep 1
exit

Icewm loaded quickly, and then the other two programs appeared in taskbar a few seconds later, without conflicts.

In the case of twm, it appears one could do something similar by placing a script call in their ~/.twmrc file. I didn't have the available time to test such an option today. The point here is to avoid conflicts when light windows managers load. If we can let .xinitrc simply load the selected windows manager, we can create or modify scripts to load other programs or settings downstream from .xinitrc.