Am 20.05.2016 um 21:50 schrieb Christian Boltz:
Hello,
it looks like
systemctl restart foo
is internally mapped to a sequence of
systemctl stop foo; systemctl start foo
what else?
Unfortunately, this behaviour causes quite some trouble for me.
why?
I need a way to know if "rest
Hi systemd-devel,
I'm on Debian Jessie running the default systemd-215. I have a daemon (running
as root, controlled by systemd), whose job it is to launch on-demand VNC
servers for other users. Currently, this daemon uses a shell command like the
following to launch the vnc server for a give
Hello,
it looks like
systemctl restart foo
is internally mapped to a sequence of
systemctl stop foo; systemctl start foo
Unfortunately, this behaviour causes quite some trouble for me.
I need a way to know if "restart "or "stop" was used because the mapping
to stop / start gives my serv
On Thu, 19.05.16 10:57, 김민경/주임연구원/SW Platform(연)AOT팀(minkyung88@lge.com)
(minkyung88@lge.com) wrote:
> Hello,
>
> I am planning to work on supporting api which changes "WATCHDOG_USEC"
> value during service running.
>
> With this api, running service can change its own watchdog timeout
On Tue, 17.05.16 21:50, Tomasz Janowski (tomjanow...@gmail.com) wrote:
> Hello,
>
> I have an issue with possible conflicts between systemd and a SLURM
> scheduler cgroup management. SLURM ca be configured to use a few cgroup
> subsystems like freezer, cpuset and memory. The daemon itself runs i
On Wed, May 11, 2016 at 7:31 PM, Lennart Poettering
wrote:
> On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote:
>
> > Hi again all,
> >
> > TL;DR: would it be possible (or make sense) to have systemd Match rules
> for
> > network units that could match on some artifact of the network
On Fri, 20.05.16 18:08, Ivan Shapovalov (inte...@intelfx.name) wrote:
> On 2016-05-20 at 14:59 +0200, Lennart Poettering wrote:
> > On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
> >
> > > The default systemd configuration runs ldconfig at boot. Why?
> >
> > It's conditional
I debugged this further .
And this turned out to be issue with our script in ExecStop.
Thanks for comments
On May 20, 2016 8:16 PM, "Lennart Poettering"
wrote:
> On Wed, 18.05.16 20:38, Pradeepa Kumar (cdprade...@gmail.com) wrote:
>
> > sorry for not being clear earlier.
> > may be i am not expl
On Wed, 18.05.16 20:38, Pradeepa Kumar (cdprade...@gmail.com) wrote:
> sorry for not being clear earlier.
> may be i am not explaining properly.
>
> In XYZ.service:
> ExecStop: myscript1
>
> $cat myscript1
> echo "inside myscript1"
>
>
> and
>
> The sequence in jounrnalctl logs are:
>
> Ma
On Fri, 20.05.16 11:24, Bao Nguyen (bao...@gmail.com) wrote:
> Hi Martin,
>
> Thanks a lot for your answer.
>
> How about if my specific script is written by SysVinit, it has LSB headers,
> can we still use in LSB header the property lAfter= as in systemd to make
> it start/stop orderly?
Our "s
On Fri, 20.05.16 16:10, Lennart Poettering (lenn...@poettering.net) wrote:
> You mean, because not all local file systems have been mounted yet?
>
> So, there was actually a PR that tried to fix that, posted recently:
>
> https://github.com/systemd/systemd/pull/2859
>
> and it was merged re
On 05/20/2016 04:04 PM, Lennart Poettering wrote:
On Fri, 20.05.16 15:55, Florian Weimer (fwei...@redhat.com) wrote:
On 05/20/2016 02:59 PM, Lennart Poettering wrote:
On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
The default systemd configuration runs ldconfig at boot.
On Fri, 20.05.16 16:06, Florian Weimer (fwei...@redhat.com) wrote:
> On 05/20/2016 04:04 PM, Lennart Poettering wrote:
> >On Fri, 20.05.16 15:55, Florian Weimer (fwei...@redhat.com) wrote:
> >
> >>On 05/20/2016 02:59 PM, Lennart Poettering wrote:
> >>>On Fri, 20.05.16 14:01, Florian Weimer (fwei..
On Fri, 20.05.16 15:55, Florian Weimer (fwei...@redhat.com) wrote:
> On 05/20/2016 02:59 PM, Lennart Poettering wrote:
> >On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
> >
> >>The default systemd configuration runs ldconfig at boot. Why?
> >
> >It's conditionalized via Condit
On 05/20/2016 02:59 PM, Lennart Poettering wrote:
On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
The default systemd configuration runs ldconfig at boot. Why?
It's conditionalized via ConditionNeedsUpdate=, which means it is only
run when /etc is older than /usr. (This is
On Wed, 18.05.16 22:14, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:
> I need to mount tmpfs on .cache for each user after login.
> How can I do that with systemd?
> S
> For example I want for user1 mount tmpfs on dir .cache, for user2 mount
> .cache to tmpfs also and so on.
> After logout last se
On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
> The default systemd configuration runs ldconfig at boot. Why?
It's conditionalized via ConditionNeedsUpdate=, which means it is only
run when /etc is older than /usr. (This is tested via checking
modification times of /etc/.upd
From what I understand, directories such as /usr/lib and stuff are
properly used even in case of a corrupted ld.so cache. like ldconfig
does not affect those directories at this time.
W dniu 20.05.2016 o 14:06, Vasiliy Tolstov pisze:
> 2016-05-20 15:01 GMT+03:00 Florian Weimer :
>> The default sys
2016-05-20 15:01 GMT+03:00 Florian Weimer :
> The default systemd configuration runs ldconfig at boot. Why?
>
> Most deployments of systemd appear to be dynamically linked, so if the ld.so
> caches are corrupted, you will never get to the point where you can run
> ldconfig.
>
> Running ldconfig to
The default systemd configuration runs ldconfig at boot. Why?
Most deployments of systemd appear to be dynamically linked, so if the
ld.so caches are corrupted, you will never get to the point where you
can run ldconfig.
Running ldconfig too early tends to cause problems because the file
sy
20 matches
Mail list logo
