Am 25.07.19 um 20:38 schrieb Debraj Manna:
> I have a service on a Ubuntu 16.04 which I use systemctl start, stop,
> restart and status to control.
>
> One time the systemctl status returned active, but the application
> "behind" the service responded http code different from 200.
>
> So I woul
I have a service on a Ubuntu 16.04 which I use systemctl start, stop,
restart and status to control.
One time the systemctl status returned active, but the application "behind"
the service responded http code different from 200.
So I would like to restart the service when the http code is not 200
On Do, 25.07.19 13:02, Tiwari, Hari Sahaya ([email protected]) wrote:
> Hello,
> I have one query on the behaviour I am overserving with systemd service.
>
> Below are the contents of service file,
>
> # cat /usr/lib/systemd/system/qs.service
> [Unit]
> Description=init script
> After=net
On Do, 25.07.19 17:51, Pawel Szewczyk ([email protected]) wrote:
> On 7/23/19 18:00, Lennart Poettering wrote:
> >
> > Do you have some profiler results about this? i.e. what exactly is the
> > time spent on?
>
> I will probably try to do some 'real' study of this problem by using
> perf or o
On 7/23/19 18:00, Lennart Poettering wrote:
>
> Do you have some profiler results about this? i.e. what exactly is the
> time spent on?
I will probably try to do some 'real' study of this problem by using
perf or other tool. So far all I know is that the device enumeration
(i.e. device_enumerat
On Thu, Jul 25, 2019 at 05:29:33PM +0200, Pawel Szewczyk wrote:
> On 7/17/19 23:14, Greg KH wrote:
> >
> > 100ms seems like a really long time, what exactly is it doing during
> > that time? Is the kernel spending too much time regenerating the
> > uevents?
> >
> > How many devices are you talki
On 7/17/19 23:14, Greg KH wrote:
>
> 100ms seems like a really long time, what exactly is it doing during
> that time? Is the kernel spending too much time regenerating the
> uevents?
>
> How many devices are you talking about? Any chance to see what really
> is happening here by running perf t
Am 25.07.19 um 15:46 schrieb Debraj Manna:
> Thanks Mantas for replying.
>
> ExecStartPre=-/bin/su ubuntu -c
> "/home/ubuntu/build-target/kafka/kafka-systemd-prestart.sh"
> ExecStart=/bin/su ubuntu -c
> "/home/ubuntu/build-target/kafka/kafka-systemd-health.sh"
> ExecStopPost=-/bin/bash
> /home/
Hello,
I have one query on the behaviour I am overserving with systemd service.
Below are the contents of service file,
# cat /usr/lib/systemd/system/qs.service
[Unit]
Description=init script
After=network.target
[Service]
ExecStartPre=/bin/sh /usr/local/cmcluster/bin/realtimeslice.sh -s
/usr/l
Thanks Mantas for replying.
ExecStartPre=-/bin/su ubuntu -c "/home/ubuntu/build-target/
kafka/kafka-systemd-prestart.sh"
ExecStart=/bin/su ubuntu -c "/home/ubuntu/build-target/
kafka/kafka-systemd-health.sh"
ExecStopPost=-/bin/bash /home/ubuntu/build-target/
kafka/kafka-systemd-poststop.sh
If I s
Am 25.07.19 um 13:29 schrieb Frank Steiner:
> Silvio Knizek wrote:
>
>> the proper approach would be to define the dependency of the generated
>> .service to the mount point with a drop-in and RequiresMountsFor=. See
>> man:systemd.unit for more information.
>
> How would that work for init.d s
Lennart Poettering wrote:
Things like ssh when run as a sysv script: people expect that shutting
down ssh doesn't kill all your children, and it didn't in sysv... And
there are similar things.
That's a reasonable example, thanks!
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.
Am 25.07.19 um 13:15 schrieb Mantas Mikulėnas:
> IIRC the idea is that user sessions are killed during shutdown before
> unmounting anything anyway, and services have implicit
> After=local-fs.target so they get stopped before local filesystems? The
> shutdown process is one area that I still kno
Am 25.07.19 um 13:07 schrieb Frank Steiner:
> Reindl Harald wrote:
>
>> "try to kill all processes using a filesystem before unmounting it"
>> isn't that easy when it comes to namespaces, "lsof" even don't tell you
>> the root cause preventing unmount but the ernel still refuses to do so
>
> Ag
On Do, 25.07.19 13:46, Frank Steiner ([email protected]) wrote:
> Mantas Mikulėnas wrote:
>
> > I think that's a deliberate decision made in the
> > systemd-sysv-generator. Note how the generated .service files have
> > "KillMode=process" (and even "RemainAfterExit=yes"). The default f
Ulrich Windl wrote:
*1: I have a support call open with SUSE:
Before systemd (almost) all processes were killed before unmounting.
With systemd I'm seeing excessive reboot delays due to unmount timing out. For
example if you have a process started from NFS that has a log file on NFS open,
too.
Lennart Poettering wrote:
When generating native unit files from legacy sysv scripts, we use
KillMode=process, which means we'll only kill the main process, and
nothing else. This choice was made since its behaviour comes closest
to classic SysV behaviour (since there the init system didn't kill
Mantas Mikulėnas wrote:
I think that's a deliberate decision made in the
systemd-sysv-generator. Note how the generated .service files have
"KillMode=process" (and even "RemainAfterExit=yes"). The default for
native services is to kill the entire cgroup, and IIRC that even was
one of the main re
On Do, 25.07.19 13:29, Frank Steiner ([email protected]) wrote:
> Silvio Knizek wrote:
>
> > the proper approach would be to define the dependency of the generated
> > .service to the mount point with a drop-in and RequiresMountsFor=. See
> > man:systemd.unit for more information.
>
>
On Do, 25.07.19 12:49, Ulrich Windl ([email protected]) wrote:
> >>> Silvio Knizek schrieb am 25.07.2019 um 12:10 in
> Nachricht :
>
> [...]
> > Hi,
> >
> > the proper approach would be to define the dependency of the generated
> > .service to the mount point with a drop-in and Re
On Do, 25.07.19 12:52, Ulrich Windl ([email protected]) wrote:
> > "try to kill all processes using a filesystem before unmounting it"
> > isn't that easy when it comes to namespaces, "lsof" even don't tell you
> > the root cause preventing unmount but the ernel still refuses to do
On Do, 25.07.19 12:08, Ulrich Windl ([email protected]) wrote:
> *1: I have a support call open with SUSE:
> Before systemd (almost) all processes were killed before unmounting.
> With systemd I'm seeing excessive reboot delays due to unmount timing out.
> For example if you have
On Do, 25.07.19 11:40, Frank Steiner ([email protected]) wrote:
> Hi,
>
> I'm currently discussing a problem with the SuSE support about failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing processes left over by some init.d script. E.g. use
>
Silvio Knizek wrote:
the proper approach would be to define the dependency of the generated
.service to the mount point with a drop-in and RequiresMountsFor=. See
man:systemd.unit for more information.
How would that work for init.d scripts?
Also the systemd-sysv-generator can only do so muc
On Thu, Jul 25, 2019 at 1:26 PM Debraj Manna
wrote:
> I have unit file which looks like below. I am seeing some of the echo are
> showing up in syslog but not in journalctl. Can someone let me know what is
> going on?
> systemd version 229 running on Ubuntu 16.
>
> [Unit]
> Description=Kafka Serv
On Thu, Jul 25, 2019 at 12:49 PM Frank Steiner <
[email protected]> wrote:
> Hi,
>
> I'm currently discussing a problem with the SuSE support about failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing processes left over by some init.d script.
Reindl Harald wrote:
"try to kill all processes using a filesystem before unmounting it"
isn't that easy when it comes to namespaces, "lsof" even don't tell you
the root cause preventing unmount but the ernel still refuses to do so
Agreed! I've seen that already when trying to unmount manually
>>> Reindl Harald schrieb am 25.07.2019 um 12:16 in
Nachricht <[email protected]>:
> Am 25.07.19 um 12:08 schrieb Ulrich Windl:
>> Before systemd (almost) all processes were killed before unmounting
>
> that's often a transfigured point of view
>
> many issues w
>>> Silvio Knizek schrieb am 25.07.2019 um 12:10 in
Nachricht :
[...]
> Hi,
>
> the proper approach would be to define the dependency of the generated
> .service to the mount point with a drop-in and RequiresMountsFor=. See
> man:systemd.unit for more information.
> Also the systemd-sysv-generat
Thanks Silvio for replying. I will check your suggestions.
But it appears this is some issue with systemd version 229 as mentioned in
https://unix.stackexchange.com/a/417632
On Thu, Jul 25, 2019 at 4:09 PM Silvio Knizek wrote:
> Am Donnerstag, den 25.07.2019, 15:55 +0530 schrieb Debraj Manna:
>
Am Donnerstag, den 25.07.2019, 15:55 +0530 schrieb Debraj Manna:
> I have unit file which looks like below. I am seeing some of the echo
> are
> showing up in syslog but not in journalctl. Can someone let me know
> what is
> going on?
> systemd version 229 running on Ubuntu 16.
>
> [Unit]
> Descrip
I have unit file which looks like below. I am seeing some of the echo are
showing up in syslog but not in journalctl. Can someone let me know what is
going on?
systemd version 229 running on Ubuntu 16.
[Unit]
Description=Kafka Service
[Service]
Type=simple
Environment=KAFKA_HOME=/home/ubuntu/depl
Am 25.07.19 um 12:10 schrieb Silvio Knizek:
> the proper approach would be to define the dependency of the generated
> .service to the mount point with a drop-in and RequiresMountsFor=. See
> man:systemd.unit for more information.
> Also the systemd-sysv-generator can only do so much. Please writ
Am 25.07.19 um 12:08 schrieb Ulrich Windl:
> Before systemd (almost) all processes were killed before unmounting
that's often a transfigured point of view
many issues where there also before systemd but never got noticed and
after change to systemd they got visible, just because a sysvinit don't
Am Donnerstag, den 25.07.2019, 11:40 +0200 schrieb Frank Steiner:
> Hi,
>
> I'm currently discussing a problem with the SuSE support about
> failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing processes left over by some init.d script. E.g. use
> the foll
>>> Frank Steiner schrieb am 25.07.2019 um
>>> 11:40 in
Nachricht <[email protected]>:
> Hi,
>
> I'm currently discussing a problem with the SuSE support about failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing proces
Hi,
I'm currently discussing a problem with the SuSE support about failing
unmounts during reboot. Tyring to debug this I realized that systemd
is not killing processes left over by some init.d script. E.g. use
the following script in /etc/init.d/
#!/bin/sh
#
### BEGIN INIT INFO
# Provides: bla
37 matches
Mail list logo
