On OpenSUSE 13.2 with KDE, can a program be launched after the computer resumes from standby without having to change files in a directory where only root has write access (such as /etc) ?
Fisrt question is of course: should that program be run from the user’s KDE session (that hibernated and thus is in charge of the seat on resume) (a user process), or from the system (a root process)? Maybe you mean with "without having to change files in a directory where only root has write access (such as /etc) " that is should be a KDE (thus user) thing.
BTW. my basic idea about hibernation, etc. is that it is just a way to pause the users’ session and that the basics of it require that nothing will be differnt between pre hibernation and post resume. Nobody should see any difference if it hibernated or not during that time period. Thus I doubt that there are hooks to hang on things completely contrary to this design.
On 2015-01-14 12:46, hcvv wrote:
>
> Fisrt question is of course: should that program be run from the user’s
> KDE session (that hibernated and thus is in charge of the seat on
> resume) (a user process), or from the system (a root process)?
As he has asked the same questions on two places at least that I have
seen, I already know the task is to be run by the user that has control
of the KDE session 
> BTW. my basic idea about hibernation, etc. is that it is just a way to
> pause the users’ session and that the basics of it require that nothing
> will be differnt between pre hibernation and post resume. Nobody should
> see any difference if it hibernated or not during that time period. Thus
> I doubt that there are hooks to hang on things completely contrary to
> this design.
Well, there are hooks to be run at the system level, as root, on
“/etc/pm/sleep.d/”. A user can have a reason to do the same himself for
his desktop applications. For instance, stop and restart download tasks.
There are programs that are very confused by hibernation and do weird
things when they awake. For instance, ntp, dovecot… things are not as
transparent as they should be. Apparently there is not a method to
inform applications that they are going to be hibernated, so what they
see suddenly is a clock shift.
For instance, the fetchnews application I use to fetch nntp behaves
badly. I can inadvertently hibernate the machine while it is working,
and when I awake it, it tries to continue fetching with a network
connection that is dead hours ago, but it takes minutes to find that out
and abort.
Firefox could be downloading a youtube video. How gracefully does it
continue?
So no, hibernation is not that transparent for applications.
There is an autostart directory in kde.
cron has a target for boot/halt.
Hibernation control by pm-utils is being phased out for systemd, and
systemd can have per user things. Maybe one of those things allow some
control of hibernation, by the user.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
KDE can be made to run commands or user scripts when various events happen, but unfortunately resuming is not one of them
System Settings >> Application and System Notifications >> Manage Notifications
Hibernation control by pm-utils is being phased out for systemd, and
systemd can have per user things. Maybe one of those things allow some
control of hibernation, by the user.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, systemd can have user scripts run, but this still involves root privileges to create the necessary, (which the OP doesn’t want).
Good reference
https://wiki.archlinux.org/index.php/Power_management#Suspend.2Fresume_service_files
Example here
https://crocodile.is/blog/2013/04/28/user-suspendresume-service-scripts-for-systemd/
FWIW, I was able to create a custom user service successfully following the advice given here
https://wiki.archlinux.org/index.php/Systemd/User#Automatic_start-up_of_systemd_user_instances
but the problem is I only see default.target amongst the available user units, and no user ‘suspend.target’ unit available. So, no obvious way to trigger it following a resume, (unlike system services) 
Since cron has a target for boot / halt… does boot include resume? There are work arounds to use cron with user privileges.
If not under cron, perhaps its variants such as anacron or fcron do?
On 2015-01-16 16:06, Konfekt wrote:
>
> Since cron has a target for boot / halt… does boot include resume?
As far as I know, no.
The known targets (extensions) are documented on crontab(5). Perhaps the
addition could be suggested to its developer.
> There are work arounds to use cron with user privileges.
Not workaround, but full support.
> If not under cron, perhaps its variants such as anacron or fcron do?
Dunno. I would have to read their manuals.
However, you could trigger from pm-utils the running of tasks by user on
return from hibernation. “su - user -c command” for instance, or cycle
run all scripts found in certain directory… but no desktop or terminal
would be available to them.
That is, write your own code to add this feature.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2015-01-16 16:06, Konfekt wrote:
If you are not the administrator of that machine, you can code something
yourself. Have a piece of code wait for a minute, which doesn’t use cpu,
and when it returns, compare timestamps from before and after. If way
more than a minute elapsed, the machine was hibernated, so do your stuff.
This code could have access to your desktop.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thank you. I asked the crontab author about it.
It is not that I don’t have access to /etc/ but I consider it cleaner and more portable
to configure it by changing files in the home folder alone.
By the way, could you give a hint on the right setup for crontab with user priviliges? At the moment I resort to
sudo crontab -u Konfekt ~/.crontab
On 2015-01-19 15:06, Konfekt wrote:
>
> By the way, could you give a hint on the right setup for crontab with
> user priviliges? At the moment I resort to
> sudo crontab -u Konfekt ~/.crontab
Just remove “sudo” from the line.
Eumm…
Ok, if you are logged in as user “Konfekt”, just open a terminal
(konsole, xterm, whatever), and type:
crontab -e
That’s your user Konfekt’s crontab. By default you will get “vi” as
editor, so you can change it for this time, like this:
EDITOR=/usr/bin/gedit crontab -e
or any other editor you like. If you want the editor change permanent,
edit “~/.bashrc”:
export EDITOR=/usr/bin/mcedit
That’s the more or less traditional way. I think KDE has a dedicated
cron editor; I don’t remember the name, could be kcron. I see a package
of that name, but I don’t see how to start it.
Ah, ok, from the command line you can start it as “kcmshell4 kcm_cron”,
and you get a nice GUI… surely there is a GUI way to start it
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Well, the HowTo at
http://www.it.uc3m.es/marcos/doc/miniHOWTOs/miniHOWTO-Use_anacron_as_non-root_user.html
contained all. However, would it not have been safer, because less independent of the shell the user uses, if one starts anacron in ~/.profile?
Thank you Listas! (Somehow your message didn’t appear when I posted lastly)
Also for the kcron command. I had installed this package but was wondering how to start it. kcron was too naive.
What is the problem?
crontab -e
has functioned for about 20 years already (before we had to do with crontab -l >somefile > edit somefile > crontab -i somefile for some more 20 years back in time).
Who gave you the impression that only root can use cron? Well, root can block individual users from using cron, but that is not switched on by deafult on user creation in openSUSE.
read
man crontab
and experiment.
You are right that crontab works fine without sudo.
Somehow having to pass the user by -u to crontab gave me the impression that crontab is intended to be invoked by the superuser.
On 2015-01-22 21:36, Konfekt wrote:
>
> You are right that crontab works fine without sudo.
>
> Somehow having to pass the user by -u to crontab gave me the impression
> that crontab is intended to be invoked by the superuser.
No, rather that Mr. Root can edit anybody’s crontab. The intention, I
guess, is that on the system there are several cron jobs that runs as
several users that not really persons, but system jobs.
Say, I fetch news as user news, but it is really the administrator who
sets this up. So “… -u news” would be a way.
Another is that you can define jobs as files in “/etc/cron.d/*”, with a
slightly different syntax:
-3,8,13,18,.... * * * * news /path/getthem
(trimmed)
where the word “news” above is the user that it is going to run as. This
is a better way, I think.
And rpm packages can install cron jobs, just drop a file in there.
Notice that the “cron” daemon runs as root, but the jobs it calls run as
many different users, as needed. And root can allow or disallow users
for running cronjobs. I don’t remember for sure if he can specify a list
of users that can use cron or which can not, I’d have to read the manual
again. Sigh. Memory is the second thing to go, they say.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Hmm… so instead of giving a single crontab file, it is preferable to add each entry
as a separate file in /etc/cron.d ?
This looks like more work, but the advantage is that you can specify the user as
who the job is to run in these separate files instead of having to pass it manually
by crontab -u <user> <file>, is that it?
That is nonsense! Sorry.
Users (end-users) do not bother about crontab files. Except what they see when using the crontab tool. They do not matter where it is (and it is NOT in /etc). I repeat, normal users only use the crontab tool to create, change and.or remove their crontab., They only know the crontab tool and what to do with it. Or, in GUI land they use a GUI interface doing the same.
And as root is a user also, root also has “his” crontab, which can be edited using cronatb (from a root terminal session, e.g. after using su -).
And yes, root can also edit the crontab of an ordinary user by using the -u option of crontab. That is because maybe an end-user is too much a noob in this aspect to maintain his own crontab. Or for any other reason the system administrator (root) thinks fit. After all the sysems administrator/manager is responsable for everything in the end.
Separate from these user’s crontabs, there are system crontabs. Thes are in /etc and thar is what you are talking about most of the time. These are the places where the system manager (as root of coiurse) keeps his hourly/daily/weekly or whatever timing schedules of runs for system maintenance (e.g. backups, clenaups. whatever).
Now you might ask: What is the difference between using root’s personal crontab and the system crontabs? That is the subject of sound thinking. System things in the system cronttab(s) and things that root wants to manage in his own environment in his own crontab. But there will not be very many in root’s own crontab in most cases I guess. Also, the system crontabs haave some features not available to the user crontabs IIRC.
Seeing you started testing what Anacron could mean to you, but I doubt that many on openSUSE use anacron. I used it last time on RedHat, at least 10 years ago.
Thanks! Now that you don’t use anacron got me curious:
If an enduser wants to ensure a daily backup, for example of his ~/Document folder
by rsync, regardless of the up-times of his computer, then the ways to achieve this
by crontab seem rather roundabout?!
On 2015-01-23 10:26, Konfekt wrote:
>
> Hmm… so instead of giving a single crontab file, it is preferable to
> add each entry
> as a separate file in /etc/cron.d ?
>
> This looks like more work, but the advantage is that you can specify the user as
> who the job is to run in these separate files instead of having to pass it manually
> by crontab -u <user> <file>, is that it?
If a user named “john” wants a cron job, the normal thing is for him to
run “crontab -e” and that’s all. He does not need to say which file nor
what user. HIM, that’s all. Automatic.
On the other hand, system jobs that are assigned to a user different
from root, even a user that can not login, are normally done as files
under /etc/cron.d/. But it is usually the administrator who does this;
or the distributor; not users.
The permissions of /etc/cron.d do not allow a user to write a job in there.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)