[SOLVED] syslogd error opening log file

[jankom]

/var/log files are reported as read only.
I've finally installed Gentoo trying to follow all instructions, 64-bit Desktop version after resolving a freetype and harfbuzz problem with the help of the Gentoo forum. However, when I boot I have 6 error messages before login:

[cboldt]

Its possible that the entire filesystem whatever /var is part of being mounted on, is mounted as a read-only filesystem. This is a function of filesystem mounting, not a function of file permissions.

The command "mount" with no modifiers will show plenty of detail.

Being mounted "ro" (read only) instead of "rw" (read/write) will happen when there are issues confirming integrity of filesystem. In other words, a "ro" mount can happen even though the system is configured to make a rw mount.

To figure this out, of course more info is needed. What is your partition mounting arrangement? Either "df" or parts of /etc/fstab, or the output of the `mount` command.

[jankom]

Thx4 the quick reply.
The error shows up in the boot screen after starting sysklogd. I tried to do a

[cboldt]

Output of the 'mount' command shows that the problem isn't that the filesystem is mounted read only.

I assume when you say you get a report that the file or the folder is read only, that is literally what the report says. Maybe some extended attribute is set on a file or on /var/log. I don't think this is likely, for various reasons. the command `lsattr` is used to show extended attributes.

Can you write to a file there? Just open a file with an editor (for example, `nano /var/log/test-write.txt`) compose a novel, and see if it saves. Do that as root because the var/log directory is generally not regular user or world writable. Mine is ...

[Hu]

When the filesystem is reported as read-only, please show the output of cat -n /proc/self/mounts, at least for the line for that filesystem, but preferably the entire output. I wonder if OP has /etc/mtab as a real file, rather than a link to /proc/mounts, in which case the output of mount cannot be trusted when the root filesystem is read-only.

[GuntherDW]

Is this in a VM and/or a BIOS install? Because I have noticed similar issues when installing a "fresh" Gentoo in a KVM VM using a BIOS setup a couple weeks ago.

I don't know why, but these issues seemed to vanish when using UEFI boot methods instead of BIOS. That and/or using "rw" instead of "ro" in GRUB, but that's kind of dangerous.
Both methods were using the same methods of booting though. Both were using gentoo-kernel, dracut etc. The only major difference was BIOS booting and UEFI booting (and thus changing the partition table from MBR to GPT using gdisk).

The strange thing was that all of this showed up after the "remounting disks as r/w" message popped up.

I should do a new install to doublecheck but it might just be a fluke in a config file somewhere, or it just wasn't tested very well. Given that I used a ~arch install, including a stage1 bootstrap to get a ~amd64 toolchain before even starting to really install the distribution.

For clarification: the FS'es *were* mounted as read/write but maybe the command had a delay or was run too late or something, but by the time I could login it already "fixed itself". It was just rsyslog or syslog-ng and other services that were complaining about it.

[jankom]

@cboldt
Yes, I can write and save to /var/log/auth.log as root. I created that empty file when I did a touch command as root. But the sysklogd error is persistent after multiple boots.

@Hu
My /etc/mtab is a real file, not symlinked (using command ls -aiHl /etc/mtab and it shows read only for all and owned by root.
Output of cat --n /proc/self/mounts

[GuntherDW]

Yeah, I just made that VM and it booted up just fine, I guess it was either a fluke or something to do with the state of portage/that stage3 initial install at the time.
But I can confirm at least that I have noticed it occurring, even to other people at the time. But whatever it was seems to be fixed now.

Either that or what happened to trigger said issue just didn't occur now. Just as a check though, if you do omit the "ro" (or change it to "rw") in GRUB, does the issue suddenly stop appearing?
It's not really safe to do, if there's any filesystem corruption before fsck gets to it it might cause other issues, but it might just rule out a couple avenues first.

EDIT: Hmm, after playing around in that VM a bit I haven't been able to trigger said bug yet. Looking at screenshots though rsyslog was getting triggered to launch right after localmount/fsck. Is this the case in your system as well?

screenshot : https://i.imgur.com/BgHKWth.png / https://i.imgur.com/YyJn99m.png

I'm almost ready to just attribute it myself to a borked stage3/1 tarball because I haven't been able to trigger it again just yet.

[jankom]

@GuntherDW
Tried eliminating ro from /boot/grub/grub.cfg and rebooted, but the issue is still there.

Interestingly, after playing with startx I noticed that in ~/.local/share/xorg/Xorg.0.log the "Kernel command line:" has BOOT_IMAGE=vmlinuz-5.10.61 ... root=/dev/sda2 ro even after rebooting without the grub ro and restarting X.

I compiled the kernel myself mainly to leave out drivers not needed for my machine and installed it without initramfs following standard procedures (make, make module-install, make install) then doing the grub thing.

[cboldt]

Booting is usually part ro, although I don't know the gory details. At some point during startup drives can be mounted rw, and are. The fact that you can write to a file implies the system is not read only, but something is reporting read only. This is a confusing pair of reports, they can't be reconciled. One of the reports is false or misleading.

The permissions on a file aren't changed by mounting rw vs. mounting ro - permissions look the same both ways, and from initial descriptions, sysklog is not complaining about permisisions, it says the file SYSTEM is ro.

I assume you've done the 'cat /proc/self/mounts' step to confirm the relevant mount is in fact rw. Assuming further, if the mount is rw, but sysklogd reports it is not, the issue is out of my league. Could be an artifact of some whiz-bang secure kernel (I know zero about selinux), or could be a sysklogd problem, but that I sort of doubt.

Edit to add - I see sysklogd has a "systemd" USE flag. Shooting in the dark, are you running systemd or some other itint, and second question, does your sysklogd USE flag there, correspond with your init system?

[jankom]

@cboldt
Yes, I did the cat /proc/self/mounts - see my previous post, and I do not use selinux (too complicated for me).
As far as the sysklogd USE flag is concerned: what is an easy way to find out that? I'm new to Gentoo and just learning the intriucacies of USE. My boot is not "systemd", I'm more familiar with the older init process.

Thanks again to all for your continued attention. - Janos

[cboldt]

Run `emerge -pv sysklogd`

The output of that will tell all the USE flags that pertain to the package sysklogd. Those with a dash/minus in front are not enabled on your install.

Edit to add - I don't know or remember for sure that you are using sysklogd. Maybe the package you installed is another of the logging packages. There are a few. Maybe you are using newsyslog or rsyslog or even something else. Just thinking that if the filesystem is writabable, the issue isn't the filesystem or how it is mounted. That means the issue is with the program trying to do the writing. I use syslog-ng, so would have to dig a bit to learn about other logging programs.

[jankom]

@cboldt

[cboldt]

That does help. You are using open-rc to start, I think, so moving the place that sysklogd starts to AFTER the remount ought to cure the fail to write report.

`rc-status -a`will show all the services you have programmed to start, and whether they start as part of sysinit, boot, or default. My logging starts as part of the "default," and by this time the file systems are all writable.

As root, `rc-update` is the command that does service removal and service additions. I'm thinking ...

rc-update delete sysklogd sysinit (or rc-update delete sysklogd boot)
rc-update add sysklogd default

If there is some need or desire to log earlier events, then we get into kernel settings for kernel logging, and IIRC, openrc has some logging function for its startup, as well. Somehow I've managed to debug my way through startup issues without having to routinely log them - in other words, I'm satisfied with starting logging as part of default and not earlier.

Your observation here also reconciles up the "observations can't be reconciled" aspect. The filesystem IS ro when sysklogd tries to write, and it IS NOT ro when you inspect later, after startup is complete.

[jankom]

@cboldt
Yesss!
Case closed, error disappeared after I removed syklogd from run level sysinit. I did not have to add it to run level default because it was already there. Case closed.

unless

To all: is this a bug somewhere? I followed the instructions in installing the system, and service "sysklogd" was included twice. Maybe in "Installing system tools" section I entered command