Nice! (although, I think the issue for me came from some kind of weirdness when calling them from cron without using runuser, even when they were in a bash script…will be easy enough to spin up a system in order to test this again though, especially with your great logfile output. Thanks. 
)
Don’t use cron. Use a systemd timer that runs as root.
As an aside, everything with fwconsole is designed to be ran as the root user. That is the only documented method that FreePBX has ever used.
Great concept with systemd timers, but that would better need a pre-requisite freepbx.service to “wrap” the standard ‘fwconsole start’ in many deployments I think. Checking my calendar, it’s 2021 already 
I made a guide related to this for a script that does so git stuff. But the service and timer file bits are the same.
Great work guys, and your systemd timer article was a really nice refresher for me all in one place, thank you.
For the people following along, it’s very strange, but specifically regarding the fwconsole reload and fwconsole restart commands, they struggle to be automated unless you run them as root using runuser (which runuser -l root can only be called by root itself, so that works when, say, used in the root crontab or systemd timer), but, anyway, you can see the error in the screenshot when @sorvani’s script gets to the fwconsole reload command - this is output from calling the script directly from the root crontab without calling the script using ruser -l root. (It works awesomely when you are calling it directly from the CLI as intended, of course, and the other fwconsole commands seem to be okay with being called directly)
The TL;DR is that fwconsole reload and fwconsole restart have their own path issues regarding, hilariously, runuser if they are not also wrapped in a runuser -l root when being called from the root crontab (and I haven’t tried it yet but I suspect with a systemd timer as well…but I would need to test this to know for sure) - I found a good article stating that while systemd always runs things as root by default, there is a difference where more variables get set, such as $USER, $LOGNAME, $HOME, $SHELL if you also tell it User=root so maybe it would have something to do with that in order to ditch the runuser -l root command and use a systemd timer with fwconsole reload (if it’s possible to use User=root when setting up a timer…I haven’t made it that far yet but I would think it would be).
(Basically my testing so far reveals that somehow a part of fwconsole reload calls runuser itself, and if automating with even the root crontab or similar it has path issues finding it unless it has been run as runuser -l root -c ‘command to fwconsole or script containing fwconsole’ which assumedly sets up a different path variable / environment that is more similar to directly using the CLI, in which case of course it runs well then.)
There’s not really a question in there but I wanted to report my findings for anyone following along and trying things.
1 Like
/usr/sbin/fwconsole by default is run-able by the asterisk user, it is probably ‘linked’
ls -l $(which fwconsole)
1 Like
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.