On 12/5/18, Kamil Jońca wrote:
> Cindy-Sue Causey writes:
>
>> On 12/5/18, Kamil Jońca wrote:
>>> Michael Biebl writes:
>>>
My general remark that anacron is typically not needed anymore, still
stands though (even if it doesn't apply for your specific use case).
>>>
>>> What is
Cindy-Sue Causey writes:
> On 12/5/18, Kamil Jońca wrote:
>> Michael Biebl writes:
>>
>>>
>>> My general remark that anacron is typically not needed anymore, still
>>> stands though (even if it doesn't apply for your specific use case).
>>
>> What is other tool to make USER automated, cyclic
On 12/5/18, Kamil Jońca wrote:
> Michael Biebl writes:
>
>>
>> My general remark that anacron is typically not needed anymore, still
>> stands though (even if it doesn't apply for your specific use case).
>
> What is other tool to make USER automated, cyclic tasks?
I learned of "apt-cache
Michael Biebl writes:
>
> My general remark that anacron is typically not needed anymore, still
> stands though (even if it doesn't apply for your specific use case).
What is other tool to make USER automated, cyclic tasks?
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
We totally
Am 05.12.18 um 11:35 schrieb Kamil Jońca:
> So I cannot drop (ana)cron :) EOT
With your specific set of requirements, you are most likely best served
by cron (and anacron if your system is not continuously running).
I still don't understand why you need to start your backup task as user
Michael Biebl writes:
> Am 05.12.18 um 11:04 schrieb Kamil Jońca:
>
>> But 'enable-linger' starts my ALL services, which is not what I want.
>> I want to start only timers.
>
> Since you can only have one systemd --user instance, this is not possible.
> You can't have a systemd --user instance
Am 05.12.18 um 11:04 schrieb Kamil Jońca:
> But 'enable-linger' starts my ALL services, which is not what I want.
> I want to start only timers.
Since you can only have one systemd --user instance, this is not possible.
You can't have a systemd --user instance which is started during boot
with
Michael Biebl writes:
[...]
>
>> 2. start timers irrespective of graphical login.
>
> If you want them to be started during boot, use enable-linger
But 'enable-linger' starts my ALL services, which is not what I want.
I want to start only timers.
KJ
--
http://wolnelektury.pl/wesprzyj/teraz/
Am 05.12.18 um 10:49 schrieb Michael Biebl:
> Am 05.12.18 um 10:47 schrieb Kamil Jońca:
>> How can I:
>> 1. start services only with graphical login and
>
> You can't. At least not yet. Use ~/.config/autostart
Some work has already been done to support graphical-session.target
Am 05.12.18 um 10:47 schrieb Kamil Jońca:
> Michael Biebl writes:
>
>> Am 05.12.18 um 10:04 schrieb Kamil Jońca:
>>> Michael Biebl writes:
>>
> which in turn, can break ALL your "user" units)
I'd be interested to know, what exactly you have in mind here. I'm not
aware of
Michael Biebl writes:
> Am 05.12.18 um 10:04 schrieb Kamil Jońca:
>> Michael Biebl writes:
>
which in turn, can break ALL your "user" units)
>>>
>>> I'd be interested to know, what exactly you have in mind here. I'm not
>>> aware of such a breakage.
>>
>> For example: I have (--user)
>>
Am 05.12.18 um 10:04 schrieb Kamil Jońca:
> Michael Biebl writes:
>>> which in turn, can break ALL your "user" units)
>>
>> I'd be interested to know, what exactly you have in mind here. I'm not
>> aware of such a breakage.
>
> For example: I have (--user)
> kj-keepassx.service - my own
Michael Biebl writes:
> Am 05.12.18 um 08:54 schrieb Kamil Jońca:
>> "User" task aren't started until user logs in. (You should play with
>> enable-linger,
>
> I haven't read the full discussion, so I missed the part that you are
> apparently using a user crontab.
To clarify things:
1. In
Am 05.12.18 um 08:54 schrieb Kamil Jońca:
> "User" task aren't started until user logs in. (You should play with
> enable-linger,
I haven't read the full discussion, so I missed the part that you are
apparently using a user crontab.
Just curious: Why are you starting the backup task via a user
Michael Biebl writes:
> Am 05.12.18 um 07:41 schrieb Michael Biebl:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
>> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
>> problem is gone.
>
> Btw, I'd go as far and say that you can safely drop anacron these days.
Am 05.12.18 um 07:41 schrieb Michael Biebl:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
> problem is gone.
Btw, I'd go as far and say that you can safely drop anacron these days.
A lot of Debian packages which
Michael Biebl writes:
[...]
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
> problem is gone.
kjonca@alfa:~%ls /lib/udev/rules.d/60-anacron.rules
ls: cannot access '/lib/udev/rules.d/60-anacron.rules': No such
> On Mon, 03 Dec 2018, Kamil Jońca wrote:
>> >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm'
>> >> timed out. Killing.
>> > See, someone or some script told systemd to stop anacron (or maybe to
>> > stop-and-start/restart it). THIS is causing the undesired behavior.
>>
On Tuesday, December 4, 2018 at 1:40:03 PM UTC+5:30, Kamil Jońca wrote:
> Rusi Mody writes:
> > Best bet is switch to using systemd timers
>
> Second question: Why systemd kills my jobs? (Yes I know what parameters
> are responsible for this, but why they are configured that way?)
I am no
On Mon, 03 Dec 2018, Kamil Jońca wrote:
> >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm'
> >> timed out. Killing.
> > See, someone or some script told systemd to stop anacron (or maybe to
> > stop-and-start/restart it). THIS is causing the undesired behavior.
>
> Dec
Rusi Mody writes:
> On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote:
>> I have in my /etc/cron.daily some local scripts.
>> Some of them can be occassionally time-consuming.
>> Recently I found that some of them did not end.
>> And what I found:
>> 1. as "everybody" knows,
On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote:
> I have in my /etc/cron.daily some local scripts.
> Some of them can be occassionally time-consuming.
> Recently I found that some of them did not end.
> And what I found:
> 1. as "everybody" knows, in case of anacron
Henrique de Moraes Holschuh writes:
> On Mon, 03 Dec 2018, Kamil Jońca wrote:
>> 1. as "everybody" knows, in case of anacron presence, system cron jobs
>> are delegated to anacron.
>> 2. recently in Debian we have anacron.timer which also runs "cron.daily"
>>entry.
>> 3. there is a timeout
Kamil Jońca wrote:
> Here is some journal excerpt:
> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm'
> timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service:
> Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa
> systemd[1]:
On Mon, 03 Dec 2018, Kamil Jońca wrote:
> 1. as "everybody" knows, in case of anacron presence, system cron jobs
> are delegated to anacron.
> 2. recently in Debian we have anacron.timer which also runs "cron.daily"
>entry.
> 3. there is a timeout in systemd services which cause to kill my
I have in my /etc/cron.daily some local scripts.
Some of them can be occassionally time-consuming.
Recently I found that some of them did not end.
And what I found:
1. as "everybody" knows, in case of anacron presence, system cron jobs
are delegated to anacron.
2. recently in Debian we have
26 matches
Mail list logo
