hostapd won't start via systemctl
I'm having a weird issue with hostapd. When I run it via
systemctl start hostapd, it fails with this log:
The file definitely exists though, and if I run the command from hostapd.service manually, it works fine:
Changing the conf file perms to 644 didn't help, and searching for the error message didn't turn up anything about weird bugs. Is there something immutable filesystem-specific that could be causing this? hostapd was installed via rpm-ostree, if that makes a difference.50 Replies
Are you running the
sudo systemctl start hostapd.service or just systemctl start hostapd.service?
also what does the systemd service file look like?
And it fails even if it starts at boot.
Just retried
sudo systemctl restart hostapd.service to be sure and it logged the same error.that's really weird, nothing jumps out super obviously in the service file that would cause the issue.
I wonder if it's an SELinux issue?
could you try running
sudo getenforce and see if SELinux is turned on?
If it's enforcing, try doing sudo setenforce permissive and then try running sudo systemctl stop hosapd.service and then sudo systemctl start hosapd.service
could be that the SELinux label isn't set correctly for whatever reason.
if it was SELinux, I would think the behavior would persist even when you are trying to do it manually instead of the service file, but it would be nice to rule it out.Whoa, that was it.
I never would have guessed that.
Thank you so much!
Will that persist after a reboot?
no, we will probably want to do some more digging to figure out what we need to label the config file with to make it work.
lemme try and find what commands to run to see the SELinux errors. Otherwise if you have cockpit installed, it has a nice interface to see that stuff!
here it is
try running
sealert -a /var/log/audit/audit.log and paste here what it outputs.
nice thing about this command is it will usually give you a command to run to fix it if it's simple.I don't have a sealart command.
huh... I wonder if bazzite doesn't ship the
setroubleshoot and setools packages.
I have them on Bluefin-dx
you may need to layer those packages in. I'll double check my bazzite machine, hold on.Install it with rpm-ostree?
Says they're available.
yeah, they do not appear to be built into the bazzite image.
@KyleGospo @EyeCantCU
we should definitly get those packages in for troubleshooting issues like this.
this may be a quick PR we can do instead of having you layer them, but not totally sure on it.
I think I found in the container file where to add the packages. I'll put together a quick PR.
@Evening Newbs it should be in the next build of Bazzite. For now your options are:
1. Layering the package to continue troubleshooting
2. Set SELinux to permissive for now and continue troubleshooting once the new build ships.
If you layer something, can you revert it, or is the only option uninstalling and making a second layer?
I've been wondering that for a while.
rpm-ostree uninstall should allow you to remove the layer.
or the package rather.Yeah, but is that 2 layers, or did you remove the layer you added?
I'm mostly just curious.
There's only one layer, and that's the changes you've made
Removing something simply remove it from your layer
It's kind of like a git rebase if you've used git before
Ah, okay. I was picturing something more like a git commit for each
rpm-ostree action.It's technically like that, but removal is less a revert commit and more deleting it
Unless you're removing an upstream included package
And
rpm-ostree uninstall looking more like git revert in that it makes a commit to undo another one.
Got it. Good to know.I'm surprised base silverblue doesn't ship the SELinux tools.
especially since it ships SELinux by default.
Oh, and to answer to original question, I'm happy to layer them and troubleshoot it now.
Go ahead and layer
setroubleshoot and setools packages, then run sudo sealert -a /var/log/audit/audit.log
OH, missed sudo.
I missed it initially and then corrected myself 😄
These look like the relevant logs:
ok sick!
so it looks like you just need to do a restorecon on the config file.
Ah, is this because I wrote the config elsewhere and copied it over?
That is exactly why!
Did I blow away some kind of hidden file property?
do me a favor and run
ls -alZ /etc/hostapd
that should show the current selinux label on the folder.ok, so the folder has the right label, but you see how your hostapd.conf file has :user_home_t label instead of :etc_t?
Yeahhhhhh.
Makes sense now.
sudo /sbin/restorecon -v /etc/hostapd/hostapd.conf
should fix that label
you can rerun ls -alZ /etc/hostapd to see if the change worked!Yeah, it's
etc_t now.then you will want to do
sudo setenforce enforcing to set selinux back to enforcing mode.
and then try seeing if sudo systemctl restart hostapd will not give you the error anymore!Yep, it works.
yay!
Thanks so much!
If it's not DNS, it's SELinux 😄
I really appreciate it.
I feel like this is the same "welcome" everyone receives to SELinux.
No problem! Good rule of thumb is anytime there is a weird permissions issue that doesn't make sense, always try setting selinux to "permissive" and see if it fixes your issue.
Glad I could help you figure it out!
Should I
rpm-ostree uninstall those tools, or will it sort itself out when I update?uninstall, then update
it'll complain if you don't
Yeah, I was wondering the same thing! Good catch! Thanks @KyleGospo
Done. Thanks!
Thank you!
One unrelated question while we're here: will there be any ill effects if I disable NetworkManager and use systemd-networkd instead?
I certainly have not tried that. I'm assuming the effects would be similar to if you made this change in silverblue proper.
Did you copy or move the file over? If you copied it, it should of had the right type.
If you every have issues with a systemd service. Open another terminal and run journalctl -xe. Start the troublesome service and it will be very obvious it's a SELinux issue.
It will also tell you what might be the action to take (though that might require setroubleshoot).
If it starts telling you to use audit2allow, pause and research. Restorecon has been fine.
Honestly, probably should point people towards SELinux documentation since most people unless they came from fedora have zero experience with it.
I can't remember if I copied it or moved it.
I do remember that I needed to adjust permissions once it was there, so probably moved.
Yeah don't move things. Copy them. SELinux works on inodes instead of paths so moving things retains the old file contexts.
This was definitely a welcome to SELinux type issue.
Glad it was able to resolved without anything to crazy.
Yeah, me too.
Thanks again for all the help everyone.