# Checking your configfile (/etc/syslog-ng/syslog-ng... STUCK

## Oniryczny

Hello

kernel 4.1.15 x86-64

openrc

grub2

System boots up, runs scripts and stucks on [u]Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...

it didn't move forward by the whole night so I turned it off, disk OK (no errors)

Every start ends up on this message

What can I do?

----------

## DawgG

i suggest you remove syslog-ng from the relevant (default) runlevel (so it does not block the whole system) and check/fix its configfile. if the init-script gets stuck completely 

```
syslog-ng --help
```

 shows some help.

GOOD LUCK!

----------

## Oniryczny

can I edit a file (which one) from other linux and disable syslog-ng?

----------

## fedeliallalinea

 *Oniryczny wrote:*   

> can I edit a file (which one) from other linux and disable syslog-ng?

 

Yes you can boot from livecd, mounting the necessary filesystems and entering the new environment. At this point you can remove from runlevel syslog-ng.

----------

## Oniryczny

I mean... I connect the hard disk to another computer already running linux and I edit a file (disabling syslog-ng)

----------

## fedeliallalinea

 *Oniryczny wrote:*   

> I mean... I connect the hard disk to another computer already running linux and I edit a file (disabling syslog-ng)

 

For edit a file is ok

----------

## Oniryczny

I still want to know which file should I edit?

----------

## fedeliallalinea

 *Oniryczny wrote:*   

> I still want to know which file should I edit?

 

The configurations files for syslog-ng are /etc/syslog-ng/syslog-ng.conf and /etc/conf.d/syslog-ng.

For remove manually service from runlevel, I think but I'm not sure, you need to remove file (it's a symlink) /etc/runlevels/default/syslog-ng.

----------

## Tony0945

 *Oniryczny wrote:*   

> I still want to know which file should I edit?

 

You probably have an error in /etc/syslog-ng/syslog-ng.conf.  I don't know which version of OpenRC you are running. I am deliberately running an earlier version, because some errors will cause later versions to fail. You want to execute "rc-update del sys-log-ng". If you boot your install media and chroot into your installation, you can do this. 

Once you can boot, try running "/etc/init.d/syslog-ng start" If there is a configuration error, it should tell you and also will tell you which file and line has the error.

AFAIK, you can try that in your chroot with "/etc/init.d/syslog-ng restart"

----------

## Oniryczny

I was still asking about something else than chrooting but anyway thank you  :Smile: 

----------

## Tony0945

chrooting is easier than dismantling your PC and putting the drive in another machine. Once it's in the other machine you have to chroot anyway.

But, if you are dead set on it, remove the hard drive, put it in another machine, mount it, delete the symlink as fedeliallalinea said, then unmount it, shut down the other machine, put your hard drive back, boot up and once it's booted, try to start syslog-ng manually, and as I said, it should give you a message indicating where the error is.  If it hangs again, re-emerge syslog-ng.

----------

## Oniryczny

Okay

I deleted syslog-ng from runlewel (deleting symlink was much easier than chrooting)

System boots up and I can manually start syslog without any error

but adding it back to runlevel hangs again (I don't know what's wrong if it starts manually)

----------

## Tony0945

Does  rc-update|grep syslog-ng indicate default or some other runlevel? Which version of OpenRC?

----------

## fedeliallalinea

Here a similar problem

----------

## Oniryczny

```
# eix -I openrc

[I] sys-apps/openrc

     Available versions:  0.17 0.18.4 0.19.1 0.21.7 ~0.22.1 ~0.22.2 **9999 {audit debug ncurses +netifrc newnet pam prefix selinux static-libs tools unicode KERNEL="FreeBSD linux"}

     Installed versions:  0.21.7(21:47:05 19.09.2016)(ncurses netifrc pam static-libs unicode -audit -debug -newnet -prefix -selinux -tools KERNEL="linux -FreeBSD")

     Homepage:            https://github.com/openrc/openrc/

     Description:         OpenRC manages the services, startup and shutdown of a host

#
```

openrc doesn't exist in any runlevel now, but it was in the default one only...

----------

## Tony0945

 *Oniryczny wrote:*   

> #openrc doesn't exist in any runlevel now, but it was in the default one only...

 I don't understand that comment. BTW, are you running FreeBSD or Linux?

Since you are running unstable OpenRC, I would emerge the stable as follows and see if it fixes the problem. Unfortunately, you will have to chroot.

```
emerge -a1v =sys-apps/openrc-0.17
```

 If it works then you know the culprit is OpenRC.

This is just a temporary change that will be undone at the next update or emerge. Not guaranteed to even boot, but it's the version I'm running.

```
X3 ~ # uname -a

Linux X3 4.8.3-gentoo #1 SMP Sat Oct 22 15:17:25 CDT 2016 x86_64 AMD Athlon(tm) II X3 440 Processor AuthenticAMD GNU/Linux

X3 ~ # equery w openrc

/usr/portage/sys-apps/openrc/openrc-0.17.ebuild
```

----------

## Oniryczny

I thought openrc-0.21.7 is stable...

I'm running normal gentoo (x86-64) kernel 4.1.15

----------

## Tony0945

 *Oniryczny wrote:*   

> I thought openrc-0.21.7 is stable...
> 
> I'm running normal gentoo (x86-64) kernel 4.1.15

 

You're right! I need to update portage. Nevertheless, try 0.13 as a test. Something's wacky.

----------

## Oniryczny

Now, there's a new version of openrc (0.22)

But still doesn't work on my machine...

----------

## Tony0945

Stumped.

----------

## ct85711

now you mentioned it seems to work when you start syslog manually, but did you verify that it is really working?

This site, gives some good tips on how to troubleshoot syslog  https://pzolee.blogs.balabit.com/2009/12/troubleshooting-and-debugging-syslog-ng/

One thing it says, which will be helpful is running

```
 syslog-ng -Fevd
```

This will output a lot of information, to your regular console and make syslog so it runs in the foreground.  Another nice about this command is that it will let you know, if system log is receives a message and what it does with it.  If it crashes, then obviously this will let you know of that too and help identify if it's a config issue or an issue with syslog it's self...

 *Quote:*   

> You can also use other useful programs for testing syslog-ng.
> 
> To send logs to “/dev/log”, use the logger. This program exists on the most platforms.
> 
> For example:
> ...

 

I don't know if this logger will be available, as I am not on my linux machine right now, but if you do have it; it can send a message to have it logged...

Otherwise, most times syslog will log when a user logs in (i.e. in another console su into root, possibly wrong password, etc...).

I don't have much experience with sudo if those are logged, hence why I don't mention that...

Now from experience, 2 common things can cause syslog throw a fit, is config-version, and use-dns()...

 *Syslog-ng Documentation wrote:*   

> use-dns()
> 
> Type: 	yes, no, persist_only
> 
> Default: 	yes
> ...

 

Obviously, if it's unable to resolve hostname (because network isn't up to query the DNS server), this is going to make syslog-ng seem like it hangs due to having to wait for the resolver timeout and fail...

So you may want to put this into your config file so it doesn't try resolving hostnames...

```
use-dns(no)
```

I'll leave this up to you to figure out where to put it...

Here's a link to syslog's documentation...   https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html-single/index.html

----------

## Oniryczny

I got something like this http://wklej.org/id/2972472/

----------

## gr3m1in

This topic is pretty old, however I've just faced exactly the same problem.

I've googled for the solution with no luck, so I'm writing this.

I think that I found the solution, maybe it will help someone.

Since there is somewhat similar behavior with sddm some time ago, I tried to just press random keys on the keyboard while syslog-ng was in "hanged" state.

It appeared that it helps, so I guessed that syslog-ng now requires an entropy generator as well as sddm did.

Having haveged already installed for sddm, and having it and syslog-ng both at boot runlevel, I just forced haveged to start before syslog-ng with

```
rc_syslog_ng_need="haveged"
```

at /etc/rc.conf.

That worked at once.

I hope it was useful.

----------

## Stolz

I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y

----------

## cbx550f

 *Stolz wrote:*   

> I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y

 

Stolz: I owe you a beer! I had the same issue (originally it was stuck when starting syslog-ng, but after disabling that it was stuck on something else... forgive me for forgetting what that was). Your tip there saved me a ton of bother.

Changed kernel config and all is good! Thanks man!

For reference, under "Device Drivers" in kernel config, I selected "Trust the CPU manufacturer to initialize Linux's CRNG" (4.19 kernel)

Cheers

----------

## Tony0945

 *Quote:*   

> config RANDOM_TRUST_CPU
> 
> 	bool "Trust the CPU manufacturer to initialize Linux's CRNG"
> 
> 	depends on X86 || S390 || PPC
> ...

  Is this even an issue? I have it off, apparently by default. Maybe I'm naive, but why would I not trust AMD to not install spyware? It sounds very tin-foil hat to me.

----------

## Hu

As described in the quoted Kconfig text, there is no way to verify that the rdrand instruction is safe.  Installing spyware on a system would be detectable by inspecting the system state with the right forensics tools.  Building spyware into the CPU is considered infeasible, so it is considered a non-issue.  rdrand occupies a special place of paranoia though.  Suppose a malicious party sold a CPU that, rather than returning random numbers, returned the result of low-32-bits-of(aes256(secretkey, counter++)).  For a well-chosen key, this output would appear random to anyone who did not know the derivation function (secretkey, aes256, any IV, and which bits of the result are returned to the application).  However, it would be very predictable for anyone who knew the derivation function and guessed the current value of counter, which might not be hard if an application used rdrand in a way that most or all of its bits were observable.  This would then allow the adversary to predict your random numbers in advance.  Many cryptographic algorithms assume an unpredictable source of randomness is used.  If your adversary predicts your random numbers, then the algorithm fails to provide the designed secrecy.  I'm not aware of any evidence that there are commercially available CPUs with intentionally weakened derivation functions (given the recent resurfacing of the AMD chip that returns a steady string of -1 as its random numbers, I can't write "with unnecessarily weakened derivation functions", but that fault is so embarrassingly obvious that I can't believe it's an intentional weakness), but the problem is that if someone did make such a CPU, the number of people who would know about it could be kept quite small.

----------

## Tony0945

Thank you for that detailed explanation, Hu.

Still, if it is required for syslog-ng to work properly, it seems to be the way to go. Or is it like urandom vs random, in that it depends on what one is doing?

----------

## ct85711

 *Quote:*   

> Still, if it is required for syslog-ng to work properly, it seems to be the way to go. Or is it like urandom vs random, in that it depends on what one is doing?

 

It's not that syslog-ng needs this kernel setting to function, it is boiling completely down to random/urandom (the entropy) which could use it.  I specifically stress the key word could, meaning it does not need to use it; and can work well without it.  Alas, this issue ends up looking like another issue caused by when the kernel made urandom a blocking instruction and not providing an initial entropy seed.  Now one thing to note, the kernel change on urandom was done in 2017 or earlier; while this trust option was later added in 2018...

----------

## Hu

My understanding was that /dev/urandom never fails to return data (that is its entire point), though it can return low-quality data if the good entropy has been drained.  There is also a syscall getrandom, which pulls from urandom and defaults to blocking unless told otherwise.  Many programs that don't need cryptographically strong random numbers nonetheless use the blocking mode, which causes problems when the kernel has insufficient entropy.  The kernel developers' position is that programs that need good random numbers shouldn't be blocking on them during early boot, and programs that need random numbers, but not high quality ones, should be requesting non-blocking mode.  For the latter, consider applications like mktemp: it needs a random source, but if it gets a weak random number, that's OK, because it will either work anyway (and the value doesn't need to be secret, just unique) or it will collide and mktemp can try again.

----------

## ct85711

I admit I wasn't completely correct on urandom in that it is blocking; however urandom interface will only return up to as much entropy as it has available (it is not a infinite source).  So urandom may not return as much random bytes as requested to the point the entropy is depleted and it ends up giving a noticable delay.  This is according to urandom's man page.

 *Quote:*   

>  Linux 3.17 and later provides the simpler and safer getrandom(2)  interface  which  re‐
> 
>        quires no special files; see the getrandom(2) manual page for details.
> 
>        When  read,  the  /dev/urandom  device returns random bytes using a pseudorandom number
> ...

 

----------

## solamour

I just had the same problem, and here is how my case was.

On one machine with an Intel i7 (not sure it has anything to do with the processor make/type, though), "CONFIG_RANDOM_TRUST_CPU=y" in kernel (Device Drivers -> Trust the CPU manufacturer to initialize Linux's CRNG) was all I needed.

But another machine with AMD Temash, the kernel config didn't work; if I disable "syslog_ng" from starting, then it gets stuck at "netmount", which (I think) is the next service in line. Disabling it, and now it gets stuck at "distccd", and so on.

What worked was adding rc_syslog_ng_need="haveged" in /etc/rc.conf, as @gr3m1in mentioned.

And then there is a very old, old machine with AMD Geode, which worked without the kernel config nor "haveged".

__

sol

----------

## tgnb

 *Stolz wrote:*   

> I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y

 

I owe you a beer for this as well. Thanks!

----------

## agg3l

 *Stolz wrote:*   

> I was having the same issue. syslog-ng was frozen during boot waiting for entropy. I had to move the mouse or press keys to unfreeze it. In my case I didn't have to install Haveged, I just enabled one kernel option: CONFIG_RANDOM_TRUST_CPU=y

 

Whoa, I've found the solution finally. Spent couple of days on this mess.

Surprising thing is, during migrating two close to similar Gentoo VMs from VirtualBox to KVM, having identical kernel config & startup services; both worked correctly before, one booted like a charm with qemu, while another got dead stuck on with this specific problem (and solution worked). Wish I know why... The only significant difference between two is vHDD partitioning and openSSL version (1.0 / 1.1). Latter went bad

Many thanks anyway   :Very Happy: 

----------

## pa4wdh

I just had the same problem, enabling the kernel option CONFIG_RANDOM_TRUST_CPU indeed fixed it.

As for the security implications:

I think the risk of using the (unverified) CPU RNG is quite low as it's only used to seed Linux' RNG. Before data is handed out via (u)random or the getrandom function (which syslog-ng uses) it is passed through sha1 together with other sources of randomness, and don't forget that later in the boot process the RNG is seeded with the seed saved at shutdown time.

----------

