Cron not installed?

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

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