Creating a daemon calling script for maza on macOS
Opened this issue · 20 comments
Hi,
After creating a cron job failed to work, I have been trying to set up a daemon for maza. Unfortunately, I am a bit stuck. Pretty close, I would say, but still stuck.
I already asked for help on stackoverflow but there are outstanding questions about maza itself. Any ideas?
https://stackoverflow.com/questions/71125775/stuck-with-daemon-calling-bash-script-on-macos-any-ideas?noredirect=1
Thanks!
~Ken
I wouldn't know how to help you, I'm sorry I haven't worked with MacOS for a while.
I'm going to close an issue as it's more related to the operating system than the script itself.
Best regards
That's really too bad @tanrax. The comment from pmdj seems to say exactly the opposite: "It sounds like the remaining problems are specific to maza - I am unfortunately not familiar with this software, so I don't have a specific idea on how to solve it. The error tput: No value for $TERM and no -T specified makes it sound like (a) maza is a shell script itself and (b) it is written assuming that the command will be run from a terminal window, not in the background. Is there a command line flag you can pass to it to use it as part of a non-terminal invocation?"
I still think it is a Mac configuration problem because I have never received negative feedback when creating a daemon in MacOS. But then again, maybe there is a new bug in Apple's system. Ok I'll open and wait for an answer from StackOverflow.
Thanks.
Thanks. But Stackoverflow is stuck at the moment, wondering whether this would stem from maza (see their message quoted above). I was only able to confirm that maza was a shell script, but not to say anything about "it is written assuming that the command will be run from a terminal window, not in the background. Is there a command line flag you can pass to it to use it as part of a non-terminal invocation?" Any ideas?
No, there is no flag because it is not necessary. I can confirm that it runs as a daemon because that's how it works on my computer.
There is nothing in the script that you can't run line by line from a terminal. If you want to know what is happening, a first step would be to open it and run each line. Good luck!
That is good to know, thank you very much! Any chance you could share your daemon? Maybe there is some inspiration that can be drawn from there :)
Of course. In my cron file
@daily maza update
Ah, yes, that was in the readme. Did not work on macos, I'm afraid.
@KenMatsuo-TK Any progress? No one is reporting any problems on MacOS.
Thanks for following up. Progress -- yes and no. Over on Stackoverflow, someone recommended to remove the use of tput, suggesting that might be the issue, which I did. The daemon still successfully launches mazascript (the script I made to update maza), which successfully adds the date to the specially-created file.dat (for testing purposes). However, maza is not actually stopped, as it should in the script (which, when it works, will be replaced with 'update'). The log now gives a new error, saying "ERROR. You must install gsed if you are using OSX". This error does not occur when launching maza manually, and gsed is already installed ("brew install gnu-sed" gives "gnu-sed 4.8 is already installed and up-to-date. To re-install.....". An alias for Gsed is found in "/usr/local/bin". The same person said "This seems like a PATH issue. Might want to add /usr/local/bin to the PATH from your wrapper script." but I'm not sure what to do with that..
With your permission I am going to close the issue. I do not receive any type of notification that this is being repeated with other users.
I hope you can solve it.
Well noted. Still trying to make it work on macOS Monterey, as per https://stackoverflow.com/questions/71125775/stuck-with-daemon-calling-bash-script-on-macos-any-ideas?noredirect=1#comment126712563_71125775
Quick follow up on this. Following discussions on Stackoverflow (see link above), here is the comment I receive: "Seems like [maza is] trying to put stuff in the user's home directory, but the root user doesn't have one on macOS and instead inherits it from the parent process, or defaults to /, which in turn is indeed read-only. Is there a way to specify the directory where maza keeps its data?" I guess this might be an issue for mac and not for Linux (which I think you use); that could explain the issue, @tanrax .
Hi @tanrax, any idea following my previous message? Best, Ken
I'm having the same issue on a Raspberry Pi 5 with a fresh Raspberry Pi OS 64-bit install, which is based on Debian Bookworm. Receiving a daily error message from cron:
tput: No value for $TERM and no -T specified
Any ideas?
I think there is a problem related to bash and daemons. I don't think Maza is responsible.
Executing maza manually inside an ssh terminal works flawlessly. It's just that cron didn't want this command. Also I had to put it as @daily /usr/local/bin/maza update
. Previously it threw another error saying it couldn't locate the maza binary.
Ah ok, then I don't know exactly what's wrong here. Doesn't bother me too much, since I can also run it manually every now and then.
@cRoCx I think it's the permissions. It may be that the cron is a user and does not have access to the binary.
Try creating the cron with...
sudo su
crontab -e
I've put it already in the root users crontab since the beginning, instead of a users crontab as you suggest in your readme.md, so I did sudo crontab -e
instead of crontab -e
.
Btw. you might want to correct this in your readme.md, if that is your intented way of setting it up. Because in your readme you suggest a lot of commands to be executed with sudo
... apart from the crontab setup.
Aaaaand I found a hint on why the issue occurs. It seems related to the tput command in the maza script. Have a look: https://stackoverflow.com/questions/29979966/tput-no-value-for-term-and-no-t-specified-error-logged-by-cron-process
Their suggested solution works for me with the following root user's crontab:
TERM=xterm
@daily /usr/local/bin/maza update
Sorry, for bothering you @tanrax . I could have found and solved it myself right from the start. But I suggest placing a hint in the readme.md to put the update command in the crontab of root and another hint maybe for this TERM thingie.
Edit 1: Oh wait, now cron is sending me Emails with "�[32mList updated!�(B�[m" after every execution. Let me investigate this a little further.
Edit 2: Ok, cron is not sending Emails anymore if I use either TERM=dumb
or @daily /usr/local/bin/maza update >> /var/log/maza.log
I have changed the crontab of root now to:
TERM=dumb
@daily /usr/local/bin/maza update
Hope this has no other side effects on other crontab entries in the future.
thank you so much! I'm going to update the README so it doesn't happen to anyone else.