Cron not installed?

arubislander

@WQ6Z8X4U Only installing apps from the OpenStore is supported. Is syncevolution one such app? Otherwise there are other apps in the OpenStore that sync with nextcloud. Have you tried any of those?

RayCulp

Hi @arubislander,

When I first installed UT16 about a year ago on my Google Pixel 3a XL, Syncevolution came pre-installed. It is a command line tool and is the recommended way to sync UT contacts (address book) with any CardDav capable server, including but not limited to Nextcloud, but also with many other types of data sources and servers.

As far as I can tell, UT 16 and 20 both use Evolution Data Server as a backend engine for the contacts app.

After OTA upgrade to UT20 and hard reset of the phone, Syncevolution is still on my phone (whereas all apps that I had previously installed from the Open Store are gone), so I am assuming it is still supposed to be there, especially since Syncevolution itself works perfectly on UT20 to sync my contacts.

What I need is a way to run this sync process automatically on a schedule, say every hour.

UT16 came with the Cron service, which allows you to run tasks automatically on a predefined schedule. It is the Cron job service that seems to be missing on UT20 and which I am asking about.

My question is whether it is okay to install Cron the normal way that you would on any Ubuntu system, by executing sudo apt-get install cron, or is there some other tool on UT20 that has replace Cron to execute tasks automatically?

RayCulp

Perhaps this is the reason why Cron is missing? Maybe all I need to do is run unminimize?

This system has been minimized by removing packages and content that are not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

RayCulp

I think it is also worth mentioning that UBsync is the only tool for UT that I am aware of that actually synchronizes local copies of files on your phone with a Nextcloud server, but it is currently not offered in the OpenStore for UT20 because it is still being updated. Jan Belohoubek seems to be working very hard on updating it, so it will probably be ready within a few days.

As far as I can tell, GhostCloud, which is the only Nextcloud app currently offered in the OpenStore for UT20, is a WebDav client, not a sync tool. Can anyone confirm this?

arubislander

@WQ6Z8X4U said in Cron not installed?:

My question is whether it is okay to install Cron the normal way that you would on any Ubuntu system, by executing sudo apt-get install cron, or is there some other tool on UT20 that has replace Cron to execute tasks automatically?

It is not okay to do so. Of course it is your device and you are free to do as you please with it. But anything you install via apt might be overwritten in a next OTA or whenever you switch update channels.

Also, not sure cron would even work on UT 20.04. But try it out and report back.

RayCulp

@arubislander said in Cron not installed?:

It is not okay to do so.

Ok, fair enough. I understand that generally speaking it is not supported to install anything via apt. Fine.

@arubislander said in Cron not installed?:

Of course it is your device and you are free to do as you please with it.

This sound very much like "Doing this may void your warranty". Ok, I'm fine with that.

@arubislander said in Cron not installed?:

anything you install via apt might be overwritten in a next OTA or whenever you switch update channels.

If this's the worst that can happen, it's a non-issue. I'm happy to re-install whatever gets overwritten in the next OTA, as long as installing it doesn't actually break anything. Could it? If you don't know, who/where should I be asking?

I can see now that my initial question was badly worded and invited a side discussion about Nextcloud sync tools and why I'm on my own if I do weird stuff to my phone. That completely misses the point.

The point is: cron was available on UT16 and after OTA update to UT20 it's gone. Why is it gone? Was it just forgotten? Is it not yet compatible with UT20? Was there some other reason? Will it be added later? I want to understand. If this is not the right place to ask, I'll be glad to raise and issue on Gitlab or whatever is more appropriate.

Lakotaubp

@WQ6Z8X4U You could try asking that here https://t.me/ubports_pixel3a or the main group here https://t.me/ubports

RayCulp

@Lakotaubp

Thank you for this suggestion. I just asked this question in the Pixel 3a Telegram group, and there appears to be no clear information as to why cron is now missing, but I did receive a very useful recommendation to use systemd timers instead.

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.