"standard init scripts" are deprecated but still supported.
procd, the OpenWrt specific init daemon, has been the default since 2013. So, new init scripts should be written for it.
(But not all old packages have been modernized to use procd in their init scripts. And even some new packages have still been authored with the old style scripts.)
Procd init scripts allow better integration with the OpenWrt system, and offload to Procd the logic that would have otherwise be implemented in the script itself.
None is enforcing that rule on new community packages, so anything goes.
If you decide to not ship a procd init script in your own package, your choice does not affect the rest of the system. So as long as you don't really need it you can do without.
Many services only need to be started on boot and use static configuration (so they don't need to reload it on change), so there is no real benefit in using Procd over normal init scripts.
Stuff that is using UCI and has a Luci web interface package for configuration usually do.
Don’t know if it applies to our openwrt but to me was useful to understand that the
local
Inside the myservicename.init
(The one starting with
#!/bin/sh /etc/rc.common)
was inside the function but is obtained by parsing
/etc/config/myservicename
UCI type config file.
I know I am dumb as the procd page explained it, but I spent ages to learn that local variable is:
A variable declared as local is one that is visible only within the block of code in which it appears. It has local "scope". In a function, a local variable has meaning only within that function block.
and reading the wiki page wasn’t enough to pick up the parsing UCI file bit. As I said Linux isn’t my bread & butter and easy and linear examples work better than a explanatory paragraph.
Is there a way to link it to the procd page ? Or to whom I should ask to have something like it at the end of the procd page as tutorial to be of help
to people like me ?
It mentions Onion Omega, which is this https://onion.io/store/omega2/ and as they say they are running LEDE, which is the OpenWrt release before the current 18.06.
Yes it should apply to current OpenWrt, and yes the current procd documentation is minimal.
the whole OpenWrt site is a wiki, anyone can add or edit the articles (apart from the home page and some other major pages I think).
Imho it's better to copy-paste it whole and leave a link to the original article with credits and such. A lot of sites disappear and we don't want to lose information at random.
but problem is node.js is some java stuff people won't have on their small openwrt routers
thats why I didnt tried to create the webpage
was waiting to have something I could play with
and even a C program should be compiled for every platform
so I was thinking about a simple bash script
but then I realized openwrt doenst ships with bash but something else (I dont know bash .....something else would be a nightmare)
so I tried a simple shell (whatever kind it is) to log something to logread and then change a variable in the logged message using procd parsing system
problem is I didnt find a way to send anything to log !!! can you imagine
meanwhile I tried to log something to logread using hotplug (like I need a way to restart network when a device (wlan0 or eth1) goes up but wasnt able to do that so moved back to first try to log something to logread by hotplug)
You may still need to install additional commandline tools in OpenWrt. A Desktop PC Linux like Ubuntu has much more commandline tools in default install.
Check if a tool is available by writing which tool-name
and it will answer you where this tool is, or an error if there is no such tool installed.
I would strongly recommend against selecting a different login shell via /etc/passwd, doing so will blow up with the next sysupgrade (conffiles are kept, including /etc/passwd, while user-installed binaries (/bin/bash) that are not part of the default image are dropped - leaving you without a valid login shell for root --> inaccessible/ semi-bricked device).
If you like bash and assuming your device has enough flash/ RAM/ CPU cycles left, there's no real reason not to use it, by calling it manually - but configuring a non-default login shell is a bad idea.