Problems concerning to /etc/local.d [Solved]

Discussion in general that pertains to Sabayon Linux - Must Pertain to Sabayon Linux

Moderator: Moderators

Problems concerning to /etc/local.d [Solved]

Postby linuxfluesterer » Mon Jul 08, 2013 12:46

Hallo guys.
After I'd opened a thread with misbehave on (KDE) Bluetooth with Sabayon from 26/06/2013, Kernel 3.9.7 and KDE 4.10.4, I have made some tests to get Bluetooth started.
Usually it would be enough to get bluetooth started with command:
Code: Select all
rc-update add bluetooth default

to get this service started while booting.
But a reboot doesn't lead to success.
So, then I've started bluetooth manually (as root) with:
Code: Select all
/etc/init.d/bluetooth start
which leads into an error message:
Code: Select all
* WARNING: bluetooth is already starting

Code: Select all
/etc/init.d/bluetooth restart
leads also in the same message:
Code: Select all
* WARNING: bluetooth is already starting

OK: So, finally, I could start then bluetooth as root with:
Code: Select all
bluetooth start

Then I get bluetooth running, I see the symbol in the tray of KDE.
But here's the point. I made a script to start bluetooth at boot time.
This script contains:
Code: Select all
# Stand: 05/07/2013, geaendert zu neuem Sabayon v. 26/06/2013 mit Kernel 3.9 und KDE 4.10.4
# btusb ist geladen
# Es fehlt nur der start vom Bluetooth-Daemon!
modprobe btusb
bluetoothd start
echo " 02 Bluetooth gestartet"

and is located in /etc/local.d directory:
Code: Select all
SL-K39-KDE410 ~ # ls -lan /etc/local.d
insgesamt 24
drwxr-xr-x   2 0 0   74  7. Jul 14:00 .
drwxr-xr-x 151 0 0 8192  3. Jul 06:33 ..
-rwxr-xr-x   1 0 0   95  7. Jul 13:51 10_mkdir_ProjectX.start
-rwxr-xr-x   1 0 0  238  7. Jul 13:51 20_Bluetooth.start
-rw-r--r--   1 0 0  652 24. Jun 22:05 README

So, as all I know, both the files 10_mkdir_ProjectX.start and 20_Bluetooth.start should be started automatically while booting process.
Because I don't see any bluetooth entry with ps aux|grep bluetooth and no echo line in 'dmesg'
and also the first file doesn't create a tmpfs directory as it should do, I fear, that /etc/local.d/ files are not /no more(?) executed.
My question is: Can someone confirm this attitude? How can I check else?
I didn't change the way to install Sabayon to the way I did before.
Before (since I use tmpfs tmp directory due to an ssd), at least the 10_mkdir_ProjectX.start - file was executed at boot time.
When I start both files manually (as root) then both are executed.
Why not while booting?

Any help is appreciated.

Here my hardware:
Acer V3-571G Laptop
Intel Core i5-3210M
8 GByte Ram, 40 GByte sdd
NVidia GForce GT630M (switchable with integrated Intel graphics).
Integrated Bluetooth
Software: Sabayon Daily from 26/06/2013 with KDE 4.10.4 and Kernel 3.9.7.

-Linuxfluesterer (I love KDE ...)
Last edited by linuxfluesterer on Sat Jul 20, 2013 15:31, edited 1 time in total.
Take away Facebook from me and let there be real people again...
User avatar
Old Dear Hen
Posts: 753
Joined: Thu Sep 20, 2012 19:47
Location: Germany

Re: Problems concerning to /etc/local.d

Postby Fitzcarraldo » Sat Jul 20, 2013 10:31

/etc/local.d/ is for scripts launched by the local service of OpenRC (See local.d). If you're using systemd, it does not use local.d.
User avatar
Sagely Hen
Posts: 8032
Joined: Sat Mar 10, 2007 5:40
Location: United Kingdom

Re: Problems concerning to /etc/local.d

Postby linuxfluesterer » Sat Jul 20, 2013 15:30

After a longer time of guessing, reading and testing,
I have found out, that systemd uses
Code: Select all

So I've edited the matching .service file as root:
Code: Select all
mc -e /usr/lib/systemd/system/local-d.service
Description=Execute start/stop scripts in /etc/local.d in an OpenRC compatible way

ExecStart=-/etc/local.d.rc start
ExecStop=-/etc/local.d.rc stop


and inserted especially both lines with ExecStart=-... After that I needed to enable this service also.
The thing is, I need to start some script when boot, for what reason ever.
With sysvinit, /etc/local.d/*.start files where run when booting by default after installing Sabayon.
But since Sabayon has changed to systemd with the latest iso-live-images, local-d.service is NOT enabled by default.
Honestly, I wonder, why. It took me a while with guessing and testing, when I began to read about systemd functionality.
But neither in Rigo announcement (important messages) nor in forum nobody (e.g. Lxnay) has told about the differences between sysvinit and systemd, and that some services have to be adopt and/or enabled before achieve the same result as running sysvinit.
Then I still have (or better have again) problems with my alsa sound. It is muted again.
A recommendation in another thread with 'Alsa sound muted' was to enable the alsa services with:
Code: Select all
systemctl enable alsa-store.service
systemctl enable alsa-restore.service

So, despite that sound doesn't work for me just now, why must the user enable sound by enabling a service?
This is a basic hardware, which is used by DE messages, used for music and movies. With sysvinit it was default.
This service should be activated by default with systemd also, when creating the Sabayon install image.
I am really willing to learn, I enjoy, yes. But how should I know, that systemd was the reason, because something must be adopted here and/or enabled? When I opened this thread, I was not focussed on systemd (how?).
Now, in between, I have found the solution by myself. By enabling the adopted /usr/lib/systemd/system/local-d.service then /etc/local.d/*.start files will be executed in an OpenRC way. But honestly, I expect that some more Sabayon users will be effected by services which are NOT enabled by systemd.
I will mark this thread as closed now.

-Linuxfluesterer (I love KDE ...)
Take away Facebook from me and let there be real people again...
User avatar
Old Dear Hen
Posts: 753
Joined: Thu Sep 20, 2012 19:47
Location: Germany

Return to Sabayon Linux General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest