>>> Lennart Poettering schrieb am 29.07.2019 um 14:16
in
Nachricht <20190729121614.GG19185@gardel-login>:
> On Mo, 29.07.19 14:14, Ulrich Windl ([email protected])
> wrote:
>
>> OK: The "abandoned" scope most likely is a daemon process started in an
>> interactive session that do
Particularly the following sentence:
This option defaults to off, since it depends on drivers and
software setup whether the watchdog is correctly reset again after
the kexec completed, and thus for the general case not clear if safe
(since it might cause unwanted watchdog reboots after the kexec
On Do, 25.07.19 19:16, Debraj Manna ([email protected]) wrote:
> 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"
> ExecSt
On Do, 25.07.19 14:20, Mantas Mikulėnas ([email protected]) wrote:
> Take a look at `journalctl -o verbose SYSLOG_IDENTIFIER=su _PID=38464`.
>
> I suspect the messages *are* in the journal, just not tagged with
> UNIT=kafka.service anymore. In some distros, `su` is actually configured to
> call pa
On Do, 25.07.19 15:55, Debraj Manna ([email protected]) 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.
>
> ExecStartPre=-
On Fr, 26.07.19 19:07, Debraj Manna ([email protected]) wrote:
> Thanks Reindl for replying.
>
> Can we make use of the watchdog & systemd-notify functionality of systemd?
> I mean something like this.
>
> [Unit]
> Description=Test service
> After=network.target
>
> [Service]
> Type=notify
On Mo, 29.07.19 14:14, Ulrich Windl ([email protected]) wrote:
> OK: The "abandoned" scope most likely is a daemon process started in an
> interactive session that does no longer exist ("logout").
> Is there a command to display the actual processes abelonging to each scope?
Use "
>>> Lennart Poettering schrieb am 29.07.2019 um 14:11
in
Nachricht <20190729121150.GE19185@gardel-login>:
> On Mo, 29.07.19 14:05, Ulrich Windl ([email protected])
> wrote:
>
>> > Key here is that these scope units are ordered after
>> > systemd‑user‑sessions.service, which also
On Mo, 29.07.19 14:08, Ulrich Windl ([email protected]) wrote:
> >> And just repeating the unmount without further actions is not a
> >> hack?
> >
> > Hmm? we tend to give up when we can't unmount something, log about it
> > and go on. We also have a second shutdown phase, which is
On Mo, 29.07.19 14:05, Ulrich Windl ([email protected]) wrote:
> > Key here is that these scope units are ordered after
> > systemd‑user‑sessions.service, which also means they are terminated
> > before that service is terminated (since in systemd the shutdown order
> > is always t
>>> Lennart Poettering schrieb am 29.07.2019 um 13:55
in
Nachricht <20190729115524.GB19185@gardel-login>:
> On Mo, 29.07.19 08:16, Ulrich Windl ([email protected])
> wrote:
>
>> >>> Lennart Poettering schrieb am 25.07.2019 um
13:37
>> in
>> Nachricht <20190725113724.GC12912@gard
On Mo, 29.07.19 08:38, Ulrich Windl ([email protected]) wrote:
> Sorry I hit "send" too quickly:
> That would mean the problem of not being unable to umnount /home is not that
> the network is down, but that some process still has open files on /home.
>
> However from the origina
>>> Lennart Poettering schrieb am 29.07.2019 um 13:53
in
Nachricht <20190729115308.GA19185@gardel-login>:
> On Mo, 29.07.19 08:17, Ulrich Windl ([email protected]‑regensburg.de)
wrote:
>
>> >> What this "solution" fails to see is that any user can start a
>> >> process that may prevent clean un
On Mo, 29.07.19 08:23, Ulrich Windl ([email protected]) wrote:
> >>> Frank Steiner schrieb am 25.07.2019 um
> >>> 14:14 in
> Nachricht <[email protected]>:
> > Ulrich Windl wrote:
> >
> >> *1: I have a support call open with SUSE:
> >> Before sys
On Mo, 29.07.19 08:16, Ulrich Windl ([email protected]) wrote:
> >>> Lennart Poettering schrieb am 25.07.2019 um 13:37
> in
> Nachricht <20190725113724.GC12912@gardel-login>:
> > On Do, 25.07.19 12:52, Ulrich Windl ([email protected]‑regensburg.de)
> wrote:
> >
> >> > "try to ki
On Mo, 29.07.19 08:17, Ulrich Windl ([email protected]) wrote:
> >> What this "solution" fails to see is that any user can start a
> >> process that may prevent clean unmount. It's completely far away
> >> from reality to believe that such a user will write (or even know
> >> how t
On So, 28.07.19 22:11, Chris Murphy ([email protected]) wrote:
> Using either of the following:
>
> systemd.log_level=debug systemd.journald.forward_to_kmsg log_buf_len=8M
>
> systemd.log_level=debug systemd.log_target=kmsg log_buf_len=8M
Note that this is not sufficient. You also have to p
On Mon, Jul 29, 2019 at 08:57:26AM +0200, Ulrich Windl wrote:
> >>> Greg KH schrieb am 25.07.2019 um 17:45 in
> Nachricht <[email protected]>:
> > 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 r
On So, 28.07.19 21:25, Vaibhav Dahiya ([email protected]) wrote:
> Hello ,
>
> My question is related to changing some flags on fd = journal_fd(),
> basically
> I want to make this socket descriptor to get a flag for non-blocking.
> As I am preparing a patch for this. I have generic query , is this
19 matches
Mail list logo