TL;DR:
I'm experiencing a "boot hang" when launching syslog-ng. System was installed from
artix-lxqt-openrc-20181008-x86_64.iso and updated using
pacman -Syyu.
System itself runs fine when the hang is canceled by hitting Ctrl+C multiple times.
----
Short introduction of myself, as this is my first post:
I`ve been using Linux for some years now, my current main system is Manjaro - so you might guess what took me here: having the Arch-Style without systemd. :)
I know a bit about Linux in general, but i'm completely new to Artix or OpenRC.
I've installed Artix on my test system from the artix-lxqt-openrc-20181008-x86_64.iso and updated it to the latest version. Despite a small issue during boot everything runs fine and is looking nice. :)
Currently, the system "hangs" during boot. At this point, hitting Ctrl+C several times makes the boot process go further.

I than can login to LXQt and everything (including networking) is fine.
Searching around a bit i came across this topic (https://forum.artixlinux.org/index.php/topic,747.msg6149.html#msg6149), which seemed to describe the same problem. On my system syslog-ng was already installed and active, adding syslog-ng-openrc did not change anything.
So i thought the issue might be, that syslog-ng starts after NetworkManager and added i dependency in
/etc/init.d/NetworkManager:
use consolekit elogind syslog-ng
This led to the behavior, that now boot hangs upon syslog-ng Config Check:

So i went straight forward and commented the config check out of
/etc/init.d/syslog-ng :
#syslog-ng -s -f "${SYSLOG_NG_CONFIGFILE}"
Now the boot process hangs on launching syslog-ng itself (no screen photo of that).
I appreciate every hint whats gone wrong with this installation and why syslog-ng wont launch on itself in a reasonable amount of time.
kind regards
guzzisti
What is "SYSLOG_NG_CONFIGFILE" in your configuration and does this file exist?
As seen in the second "screen photo", this variable resolves to
/etc/syslog-ng/syslog-ng.conf - this file exists:
$ ls -l /etc/syslog-ng/syslog-ng.conf
-rw-r--r-- 1 root root 3661 30. Dez 03:54 /etc/syslog-ng/syslog-ng.conf
I have not messed with this one after installation. :)
Do you get the same behaviour if you set rc_parallel="YES" in /etc/rc.conf?
Behaviour stays the same. I disabled syslog-ng using rc-update delete syslog-ng default and the boot does not hang up albeit the nm-dispatcher message still show up - which makes me tend to believe that NetworkManager is not the issue.
Manually starting syslog-ng from a terminal after boot works without any hassle.
If installed Artix in a virtual machine as well, there i see the nm-dispatcher messages as well, but the boot process does not get stuck. Maybe i should compare the configs of the vm and my test machine to see if there's any difference.
I'm thinking about doing a fresh install from the base-iso on my test machine to see if this might change something.
I think that's not necessary.
Please kick out or disable in syslog-ng.conf
use_dns()
and try again.
Thanks for your reply artoo, but dns was already disabled:
$ cat /etc/syslog-ng/syslog-ng.conf | grep use_dns
use_dns (no);
Nevertheless your post pointed me to back to the direction "networking", digging a bit in the internet made me across this older gentoo bugreport: https://bugs.gentoo.org/228973#c34
So i added the an additional dependency in syslog-ng script:
$ cat /etc/init.d/syslog-ng | grep net
need hostname localmount net
No everything is fine. Seems like the network interface on this machine needs 1 or 2 seconds to come up after NetworkManager is started, getting into a race with syslog-ng startup.
Gonna install Artix on my laptop now... ;D
Another possible cause we discussed with artoo on the IRC, was the absence of uucp group. If you're missing that group, it might be the reason for syslog-ng's behaviour. Latest filesystem and opensysusers fix that. Anyway, marking this as [SOLVED].
I can confirm that this has been an issue on my main server as well. I so rarely reboot, I didn't notice. It hangs long and hard. I'm talking 4 minutes.
i can confirm this is still an issue as well
Unmarking. I had witnessed it too, but now it works in all my boxes without stalling. Let's find out what's causing it, people!
Don't know if this is any evidence, but to this only happens on my hardware machines, mostly AMD Trinity or Carrizo based.
A vm installation in virtualbox doesn't stall on boot.
yes i'm on AMD
also another strange behavior i observe is that if i hit 'enter' a couple of times when booting it passes the error and
starts sddm, i don't know if that is an OpenRC feature or ?
FWIW - my box is intel
============ start debug info ============
libhd version 21.59u (x86-64) [7688]
using /var/lib/hardware
kernel version is 4.19
----- /proc/cmdline -----
BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=acadd176-e695-491c-8744-90942bc7a89f rw net.ifnames=0 quiet resume=UUID=94ad1e46-b617-4863-975b-af0044716bb3
----- /proc/cmdline end -----
debug = 0xff7ffff7
probe = 0x15938fcdaa17fcf9fffe (+memory +pci +isapnp +net +floppy +misc +misc.serial +misc.par +misc.floppy +serial +cpu +bios +monitor +mouse +scsi +usb -usb.mods +modem +modem.usb +parallel +parallel.lp +parallel.zip -isa -isa.isdn +isdn +kbd +prom +sbus +int +braille +braille.alva +braille.fhp +braille.ht -ignx11 +sys -bios.vbe -isapnp.old -isapnp.new -isapnp.mod +braille.baum -manual +fb +pppoe -scan +pcmcia +fork -parallel.imm +s390 +cpuemu -sysfs -s390disks +udev +block +block.cdrom +block.part +edd +edd.mod -bios.ddc -bios.fb -bios.mode +input +block.mods +bios.vesa -cpuemu.debug -scsi.noserial +wlan -bios.crc -hal +bios.vram +bios.acpi -bios.ddc.ports=0 +modules.pata -net.eeprom +x86emu=dump -max -lxrc)
shm: attached segment 32768 at 0x7ff2ceeea000
>> hal.1: read hal data
>> floppy.1: get nvram
>> floppy.2: klog info
>> bios.1: cmdline
>> bios.1.1: apm
>> bios.2: ram
bios: 0 disks
>> bios.2: rom
>> bios.3: smp
----- BIOS data end -----
>> bios.4: vbe
>> bios.4.1: vbe info
=== bios setup ===
failed to read /dev/mem
x86emu: could not init vm
>> bios.5: 32
>> bios.6: acpi
>> sys.1: cpu
hypervisor check: 0
vm check: vm_1 = 0, vm_2 = 0
is_vmware = 0, has_vmware_mouse = 0
>> misc.9: kernel log
>> misc.1: misc data
>> misc.1.1: open serial
>> misc.1.2: open parallel
51: None 00.0: 10103 CPU
[Created at cpu.462]
Unique ID: rdCR.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "GenuineIntel"
Model: 6.58.9 "Intel(R) Core(TM) i7-3517UE CPU @ 1.70GHz"
Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,ps e36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constan t_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf ,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,s se4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm, cpuid_fault,epb,pti,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,xsa veopt,dtherm,ida,arat,pln,pts
Clock: 1663 MHz
BogoMips: 4389.78
Cache: 4096 kb
Units/Processor: 16
Config Status: cfg=new, avail=yes, need=no, active=unknown
Hello, I allow myself to answer this forum because I have a similar concern,
(https://media.discordapp.net/attachments/507636673861910559/571754568317403136/IMG_20190427_194618842.jpg?width=400&height=300)
I hope someone will give an answer because syslog takes longer to start
i can reliably reproduce this on every boot and also the part about hitting 'enter' a couple of times to make syslog-ng start,
but i found this warning that may be part of the problem:
syslog-ng |[2019-04-21T21:04:41.862159] WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode. Please update it to use the syslog-ng 3.20 format at your time of convenience. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file.;
i will try to update the configuration to see if it solves this.
I'm also using Artix on another AMD machine without having this problem.
I have exactly the same problem.
I have a freshly installed Artix Linux on a Lenovo X220. The system runs flawlessly and smoothly, only the system startup also feels stuck for 3 minutes.
When the system finish booting, the NetworkManager can't establish the connection with my wifi.
However, if I run (and now please do not laugh) with the fingers on the touchpad during startup, the system starts fast, without hanging up and the NetworkManager is connected with my wifi.
I thought I'm crazy because it is absolutely not logical, that the move with my fingers on the touchpad would speed up the systemboot and the network connection is established.
It is logical if a lack of entropy is causing the delayed startup. Try bashing random keys and see if that also speeds up the boot.
If it does then low entropy is probably the problem.
Messing with the configuration didn't change anything about the problem
I also did a fresh Artix install but the issue still persists.
And what may be the solution to solve the entropy problem? Apart from the fact that I eventually get a tendonitis, if I have to slide over the touchpad, every time I start my device.
I have 3 more, several year old devices and all of them have Artix Linux installed. All of them boot fast and easy.
I have really no idea what I should do.
You can install some SW (read fake) entropy generator like haveged.
I have already installed haveged and it is already running.
pacman -Ss haveged
world/haveged 1.9.4-3 [Installiert]
Entropy harvesting daemon using CPU timings
world/haveged-openrc 20180221-1 (openrc-world) [Installiert]
OpenRC haveged init script
world/haveged-runit 20180226-1 (runit-world)
runit service scripts for haveged
extra/haveged 1.9.4-3 [Installiert]
Entropy harvesting daemon using CPU timings
Runlevel: default
syslog-ng [ started ]
cronie [ started ]
dbus [ started ]
NetworkManager [ started ]
acpid [ started ]
bluetooth [ started ]
haveged [ started ]
See syslog-ng hangs in getrandom(2) on boot (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913754)
haveged solves the problem, as long as it's executed _before_ syslog-ng starts.
sudo rc-update del haveged default ; sudo rc-update add haveged boot
https://forum.obarun.org/viewtopic.php?pid=3502#p3502 (https://forum.obarun.org/viewtopic.php?pid=3502#p3502)
This sounds very similar to the above bug dealt at Obarun a month ago. Something about kernel 5.0.. and urandom /dev/random that has changed. If so then with lts(4.19) the problem should not appear, if it does it may be a different problem.
This solves my problem. Now my system boots without hanging up.
Thanks a lot :)