Cron not installed?

RayCulp

@Lakotaubp Do you know how I can mark this topic as solved?

arubislander

@WQ6Z8X4U I would like to add some clarification.

The cron packages were not 'removed' on purpose. Rather, they are no longer included in the base image because there were no other packages or features in UT that depended on them.

So you should not expect them to make a reappearance until or unless some feature in the OS requires it.

Since you have been using cron jobs already in the past and were thus doing 'unsopported stuff' I would say, go ahead and install the packages you need, although there is a small chance that it might mess up a next update. So on further reflection, maybe don't do that

The suggestion to look into SystemD Timers is a good one. I for one would be eager to hear about your findings.

RayCulp

@arubislander said in Cron not installed?:

The cron packages were not 'removed' on purpose. Rather, they are no longer included in the base image because there were no other packages or features in UT that depended on them.

Thank you so much for this information!

@arubislander said in Cron not installed?:

The suggestion to look into SystemD Timers is a good one. I for one would be eager to hear about your findings.

Yes, I agree that this is a better option than re-installing cron. I will test it out and add corresponding comments to threads here in the forum that recommend using cron, if it is ok with the moderators here that I might be "necroing" some older threads.

arubislander

@WQ6Z8X4U I am one of the moderators and you have my blessing. This would be necro-ing for a worthwile cause

Lakotaubp

@WQ6Z8X4U Topic Tools (cog wheel top right) Ask as question then mark as Solved.

RayCulp

@Lakotaubp Thanks! I think I'll wait a bit to mark it solved though, as I would like to add some information about systemd timers in a few days.

RayCulp

I just wanted to briefly report back.

Synchronization continues to work perfectly if I manually execute the command in a terminal.

Setting it up to execute automatically with a systemd service and timer is more challenging than expected because Syncevolution is throwing errors that it did not before with cron. I have no idea whether it is because I'm doing something wrong (I just started learning about init / systemd a week ago), or whether it's because files/functions are missing, like cron is. I think the best course of action will be to try to get it to work first on an Ubuntu desktop system where I can be sure it's not missing files/functions. Then I can try to replicated that on UT. It may take a while though.

RayCulp

I'm afraid I can't spend any more time on this right now, so I'm going to have to wrap it up: Here are the key points:

cron is gone in UT 20 and is not coming back
Anything that relied on cron previously does not work anymore.
The recommendation I received from a member of UT's core development team is to use systemd timers instead.
I have tried countless variations and combinations of bash script files and systemd services over the past two days, but I am unable to get a systemd service to sucessfully execute a Syncevolution synchronization.
I suspect that this has something to do with the requirement to export the DISPLAY and DBUS_SESSION_BUS_ADDRESS variables as well as the user account used to execute the syncevolution command, but I do not have the expertise to solve the problem at this time.

prophanetes

@WQ6Z8X4U Thanks for keeping us in the loop! I totally appreciate your efforts here. This definitely captured my attention. I am itching to get my hands dirty with systemd timers myself... but also short on time.

RayCulp

I have solved the problem and will post a detailed guide on how to set up automated Syncevolution sychronization of contacts with Nextcloud (CardDav) using a systemd service and timer in the next few days.

RayCulp

There is one important caveat, however:

Earlier tutorials for using Syncevolution with cron under UT 16 employed a type of command substitution syntax to export the environment variable DBUS_SESSION_BUS_ADDRESS:

export DBUS_SESSION_BUS_ADDRESS=$(ps -u phablet e | grep -Eo 'dbus-daemon.*address=unix:abstract=/tmp/dbus-[A-Za-z0-9]{10}' | tail -c35)

I was unable so far to get this command substitution working with a systemd service, so the service I am currently using has a static value for the environment variable:

Environment="DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/32011/bus"

This value of the DBUS_SESSION_BUS_ADDRESS for the user phablet is what I get when I run echo $DBUS_SESSION_BUS_ADDRESS.

However, using a static value does not seem to cause any problems because, unlike UT 16, UT 20 does not seem to change the value of DBUS_SESSION_BUS_ADDRESS each time you reboot the system.

Can anyone confirm that this value is always the same, or are there still situations in which DBUS_SESSION_BUS_ADDRESS might be given a new value?

If it's always the same, then in new tutorials we can recommend that users get the value of DBUS_SESSION_BUS_ADDRESS one time with echo $DBUS_SESSION_BUS_ADDRESS and use that value in the service.

If it does not always remain the same, then we will need to find a way to get the command substitution working to grab the value dynamically each time.

RayCulp

@WQ6Z8X4U said in Cron not installed?:

Can anyone confirm that this value is always the same, or are there still situations in which DBUS_SESSION_BUS_ADDRESS might be given a new value?

This question has now also been answered by the people at my local Linux user group.

In the expression DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/32011/bus, the number 32011 corresponds to the UID, so it does not change between system reboots.

mschmids

@arubislander said in Cron not installed?:

Since you have been using cron jobs already in the past and were thus doing 'unsopported stuff...

Admittedly a bit late to the party, but with reference to the chapter CalDAV and CardDAV syncing from the UBports documentation, I would like to respectfully circle back to the "unsupported" claim in the above.

Furthermore I follow the top down dependency argument for the packages being pulled in, however this necessary concludes a defined top, presumably done manually.

arubislander

@mschmids said in Cron not installed?:

Admittedly a bit late to the party, but with reference to the chapter CalDAV and CardDAV syncing from the UBports documentation, I would like to respectfully circle back to the "unsupported" claim in the above.

And I would like to call attention to the note on the first page of that section of the documentation.
While it does not say 'you are on your own if you do any of these' as clearly as I would like, it does warn that the user is going off the recommended path.
In general in UT making your system r/w means doing unsupported stuff that might break your device on an update, or is not guaranteed to continue working (or as we have now seen, even being possible) after.

RayCulp

@arubislander said in Cron not installed?:

In general in UT making your system r/w means doing unsupported stuff

I've heard this term "unsupported" several times during the last few weeks, and I must say I find it a very confusing.

Since this is an open source, volunteer project, my assumption has been from the beginning that there is no such thing as "support" in the sense that usually comes to mind in connection with purchased products.

Any help or advice you receive on the forums comes from volunteers who are under no obligation whatsoever to provide help or advice for anything. At all. End of story.

The user is always fully responsible for whatever they do and on their own if something goes wrong. Of course, they can seek help and advice in the forum, and generally they will receive it, but they have no claim or right to this. There is also a limit to the amount of help a user will receive. If applying the suggestions from volunteers in the forum fails to fix the problem, then the user can't send the phone in to UBports to have it fixed.

Or am I wrong about all of this? Exactly what do the terms "supported" and "unsupported" mean?

arubislander

@WQ6Z8X4U "Unsupported" in this instance means "outside of the (current) goals of the project and design of the software."

These designs and goals can and will be developed and broadened over time. For instance, there is now no supported way of running custom background processes on UT. But discussions are being had, and ideas floated, on how best to bring about support in a way that is battery-life friendly and gives the user control of these processes.

RayCulp

@arubislander said in Cron not installed?:

"Unsupported" in this instance means "outside of the (current) goals of the project and design of the software."

Ok, I would paraphrase this as "something that we are not currently working on". Fair enough. But it's still not immediately clear to me what the consequences are for the user. For example, are users allowed to ask questions in the forum about unsupported procedures, i.e. procedures that involve making the system image writable? Please keep in mind that I am asking these questions from the perspective of someone who would like to write clear, helpful documentation for users, not someone who needs help themself.

arubislander

@WQ6Z8X4U said in Cron not installed?:

Ok, I would paraphrase this as "something that we are not currently working on".

That implies the promise or possibility of future work. But some things will never be worked on. If they are desired (like say, swapping out Lomiri for Phosh), then forking the project is what would be suggested.

For example, are users allowed to ask questions in the forum about unsupported procedures, i.e. procedures that involve making the system image writable?

Well, and I will be speaking more on a personal note here, I feel that if you are going to do 'unsupported stuff', it is best to know what you are doing and be willing to do the research if and when it breaks stuff.

What has happened too often is that users who know just enough to follow a tutorial and run a script, but do not understand the workings of the system or what the script is doing, break something and then need help fixing it. That increases the support burden of volunteers.
Yes, those users could be ignored, but more often than not they are vocal and tenacious. (Also, to their credit, support volunteers really want to help people figure out and fix their issue. But since the issue has arisen because of doing something 'unsupported' the knowledge to help is likely to be missing.)

This is the reason the 'unsupported' disclaimer is repeated again and again.

Circling back to your question, it is a difficult one. Because of course users are free to discus a wide range of issues under the appropriate categories of the forum. But we also do not want to give undue exposure on the forum to, what would amount to, hacks which could break the system. That would potentially get more people trying them, not getting the help they need and going away with a bad experience of the OS and the community.

mschmids

@arubislander said in Cron not installed?:

For instance, there is now no supported way of running custom background processes on UT.

Now this is a convincing argument to me. Since cron, by its very nature, interfers with the sleep / wake handling, significant to the mobile OS design, as was once explained in length. So I asume the use of sytemd makes no difference in this regard.

Still CalDAV and CardDAV syncing is essential in my setup.

RayCulp

@arubislander said in Cron not installed?:

That implies the promise or possibility of future work.

As does "outside of the (current) goals of the project and design of the software", I would say. In that case, I would simply state "outside of the goals of the project and design of the software". This leaves no ambiguity regarding possible future work on whatever it is that the user is trying to achieve.

Now we can use that to nail down what the red line is that makes an action "unsupported". If I derive it from the above definition, then I arrive at a red line that is much more stringent than just making your system image writeable. Maybe some procedures/tutorials show you how to do advanced things that don't require making the system image writable. It's irrelevant. If what you're trying to achieve is not within the scope of the goals of the project and design of the software, then it's "unsupported".

@arubislander said in Cron not installed?:

I feel that if you are going to do 'unsupported stuff', it is best to know what you are doing and be willing to do the research if and when it breaks stuff.

And I agree with you.

The vibe that I'm getting is that if something is "supported", or more precisely "within the scope of the goals of the project and design of the software", then if a user tries it and gets in trouble, the likelihood that someone can help is high. On the other hand, if something is "unsupported", or "outside of the goals of the project and design of the software", and a user attempts it and messes things up, then there may not be anyone with the knowledge to help, and, as a consequence, a complete reinstall may be the only solution.

If we can agree on this, I think it is a very good basis for a clear message to users, and it also enables us to unambiguously label tutorials as "supported" or "unsupported".

Thinking further ahead, one thing that we might communicate to users is that if they want to attempt something "unsupported", then they should be aware that they may brick the system and a full re-install may be the only solution, so they should be comfortable with re-installing UT from scratch before they attempt it. What do you think?