-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added systemd support to rpi3-ondemand-cpufreq #36
base: master
Are you sure you want to change the base?
Conversation
[Service] | ||
ExecStart=/usr/lib/rpi-scripts/bin/rpi3-bluetooth start | ||
ExecStop=/usr/lib/rpi-scripts/bin/rpi3-bluetooth stop | ||
Type=forking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend against using the "Type=forking" model of systemd services.
Specifically in this service the only reason to use "forking" is because the actual service is started by "nohup".
Instead of calling the rpi3-bluetooth script, just call /usr/sbin/rpi3-attach-bluetooth directly.
Systemd also directly supports requiring specific paths to exist in sysfs or proc before starting a service, so you can prevent this service from starting if /proc/device-tree/soc/gpio@7e200000/bt_pins isn't found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of the reason I did it that way was so that the same script could be used from openrc or systemd.
The idea being that it would be more likely to be accepted if it could be more easily maintained.
30 Oct 2020: sadly, due legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the ebuilds etc. may be of use for others looking to take forward Gentoo on 64-bit RPi systems); however, there will be no further updates to the underlying binhost etc., nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice. |
Hi,
I've recently started looking at adding systemd support to some of the ebuilds.
I figured I'd try a pull request on this one first just to see if the way I'm doing this is ok
The main body of the init script has been copied across to a file called rpi3-ondemand which ends up being installed into /usr/lib/rpi-scripts/bin/rpi3-ondemand
This can be called directly with the start parameter
There's then a systemd service file installed into /lib/systemd/system/rpi3-ondemand-cpufreq.service. This just has a description, a link to which script to start and what the dependencies are.
Usually the type can be ether simple (script doesn't fork itself and blocks), forking (script does fork itself and returns), oneshot (change something then exit)
So it's fairly simple.
Edit added scripts for
net-wireless/rpi3-bluetooth
net-misc/rpi3-ethfix