Cron but local user?

Is there a local user variant of Cron? I want to run a script every few hours, but only if I am logged into my account and in the context of my account (not as root).

crontab -e
if your feeling classy : change add this to your .bashrc

export EDITOR=nano

that way it opens nano instead of Vim (the memes are true, its near impossible to get out of vim :rofl: )

1 Like

I’m actually good with vim, thanks to the vimtutor app, but thanks.

I had vim crash my terminal a few times and ever since then I have had a complex about using it, Kudos to you for being brave enough to use it!

If you have cron installed, you can define user crontabs as well as a system crontab. Just run crontab -e as your user.

Another option that I see referenced a lot is to use systemd timers. I haven’t dug into that myself (I use cron out of habit), but that is an option.

cron does not play well with anything that interacts with GUI components for that you should use a systemd timer, I have an implementation of a timer wizard in one of my bash scripts:

You mean “local” vs. “remote”?
There are no “remote” users. One can log in on a remote system (e.g. using ssh) and then use a user on that system. Maybe you call that a “remote” user as seen from the system where you use ssh, but the user is simple a user of the remote system.

And yes, every user on a system can use cron and thus have a crontab, not only user root (why do you even think that would be a restriction of other users then root?)
As others already said, every user can manage his/her crontab with crontab -e. See of course man crontab.

Apart from the fact that root as a user can have a crontab, there is also the system crontab of jobs in /etc/crontab and/or /etc/cron.d/. And they are of course also run “as root”.

There is no ready solution for this.
“only if I am logged into my account” probably means “when my user is logged in in the GUI”. Jobs started from the crontab are independent from other processes on the system. Thus your script must test if user darkhog is having a GUI session ad then bail out or not.

If you mean by that that the background job started by cron must be able to do something on a GUI session (e.g. open a window, or spying on what is typed in the session) there is no simple solution. The GUI session is of course protected from eavesdropping/spying from outside the session. I guess there are solutions to this (see e.g. xhosts) but they are not that easy to implement.

Systemd timers (for both requirements).

Yes, it may be that these inside the users-space may offer solutions here.

@darkhog:

A possibility with the default “cron” is not really possible but, you could take a look at “Anacron” –

 > LANG=C zypper info cronie-anacron
Loading repository data...
Reading installed packages...


Information for package cronie-anacron:
---------------------------------------
Repository     : Haupt-Repository
Name           : cronie-anacron
Version        : 1.5.7-150400.84.3.1
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 43.7 KiB
Installed      : No
Status         : not installed
Source package : cronie-1.5.7-150400.84.3.1.src
Upstream URL   : https://github.com/cronie-crond/cronie
Summary        : Utility for running regular jobs
Description    : 
    Anacron becames part of cronie. Anacron is used only for running regular jobs.
    The default settings execute regular jobs by anacron, however this could be
    overloaded in settings.

 >

Further help for “Anacron” is here – <How to run commands periodically with anacron on Linux>
and here – <How to run a job on first login of each day using cron or something similar?>


Alternatively: “systemd” running as a User Instance –
HowTo is here: <Creating User’s Services With systemd>

Thus, once enabled, the service starts automatically after our login. Then, it’ll be running as long as we have some open sessions. In other words, the service instance is bound to the user, not to the session.

In 25 years of using VIM I can’t recall it ever causing anything to crash.

1 Like

Same.

I did know someone years ago who didn’t understand the UI and could’t figure out how to exit it - and ended up rebooting the system to deal with it.

ZZ or :wq! isn’t the most intuitive, but it’s habit for those of us who have used it for a while.