Cron not installed?

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

[RayCulp]

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

TBH I know nothing about this. What I do know is that adding a Nextcloud account via the GUI is supported, and the settings for the Nextcloud account indicate that syncing calendars is also supported, but when I do this, my calendars only get synced one single time when the account is created. Nothing after that.

My unsupported custom Syncevolution configurations on the other hand, together with my unsupported systemd service and timer, reliably sync my address books, and I strongly suspect I can also get calendar syncing to work this way.

FWIW, I have not noticed any degradation of performance or battery life or any other disruption due to my unsupported experiments. That's not to say that I would recommend everyone try them. As I mentioned above, I think at a minimum anyone who tries these things should be comfortable with re-installing UT.

[RayCulp]

Here's a frightening thought: Are there any situations where fiddling around with unsupported stuff might brick the phone so badly that you can't even re-install from scratch? oO

[arubislander]

@WQ6Z8X4U said in Cron not installed?:

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.

As a working proposition, I would be inclined to agree with you. But this is not a black-and-white matter. The current state of the OS is not its final state. Granted, there are not really any broad and overarching design plans written down where we can point users to. So there are, for sure, use cases that cannot be implemented in any supported way right now, which will become possible to do in a supported way in the future.

As I see it, 'unsupported' has two aspects to which it applies:

• what the user wants to do, (i.e. sync their contacts; host a website on their device)
• how the user wants to do it (using some scheduling process to call syncevolution periodically; installing ngnix)

Regarding the first use case example, because the current implementation is broken, users cannot sync their contacts. So currently there are only unsupported ways to do so. This will change in the future, when the functionality is fixed.

Regarding the second use case, it will never be the goal of the project to host your website on a UT device. (And even stating this so emphatically here gives me pause, because 'convergence', but let us assume this to be so for the sake of argument.) So any way in which this is achieved will most likely be unsupported as well. (I say most likely, because I cannot rule out the possibility of achieving 'unsupported' goals in a 'supported' way. But regardless, the goal itself is unsupported, so you'd likely still be on your own.)

My main point is that some unsupported use cases can become supported in the future, while others most likely will not. But unsupported ways of doing things are very likely to remain unsupported.

[arubislander]

@WQ6Z8X4U said in Cron not installed?:

Here's a frightening thought: Are there any situations where fiddling around with unsupported stuff might brick the phone so badly that you can't even re-install from scratch? oO

Hard bricking the device, I think would be difficult, but causing malfunctions that aren't simply rectified by a reinstall, yes, I suppose that is possible. But it would sooner be the case from messing with the devices partitions or deleting the wrong files, rather than from installing random packages.