Creating a daemon calling script for maza on macOS

[ghost]

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

[tanrax]

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

[ghost]

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?"

[tanrax]

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.

[ghost]

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?

[tanrax]

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!

[ghost]

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 :)

[tanrax]

Of course. In my cron file

@daily maza update

[ghost]

Ah, yes, that was in the readme. Did not work on macos, I'm afraid.

[tanrax]

@KenMatsuo-TK Any progress? No one is reporting any problems on MacOS.

[ghost]

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..

[tanrax]

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.

[ghost]

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

[ghost]

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 .

[ghost]

Hi @tanrax, any idea following my previous message? Best, Ken

[cRoCx]

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?

[tanrax]

I think there is a problem related to bash and daemons. I don't think Maza is responsible.

[cRoCx]

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.

[tanrax]

@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

[cRoCx]

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 "List updated!(B" 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.

[tanrax]

thank you so much! I'm going to update the README so it doesn't happen to anyone else.