Hello,
>
I found that systemd entered the D state. From the kernel stack, it was
blocked at __skb_wait_for_more_packets.
Is there any way to determine where the problem occurred? Thank you~
*# cat /proc/1/stack*
> [<0>] __skb_wait_for_more_packets+0x134/0x1a0
> [<0>] __unix_dgram_recvmsg+0xdc/0x
: [email protected]; Christopher Wong; Fredrik Hugosson;
Umut Tezduyar Lindskog
Subject: Re: [systemd-devel] Question about the systemd slice hierarchy
Hello.
On Mon, Jun 30, 2025 at 07:45:53AM +, Matthew Chae
wrote:
> I have some questions about "Example 1. Enab
Hello.
On Mon, Jun 30, 2025 at 07:45:53AM +, Matthew Chae
wrote:
> I have some questions about "Example 1. Enabling and disabling controllers"
> from the slice-related man page linked below.
> https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#
>
> First,
Hello everyone,
I have some questions about "Example 1. Enabling and disabling controllers"
from the slice-related man page linked below.
https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#
First, under system.slice, there is a slice named b.slice. Is this poss
Hi,
On Tue, Jun 17, 2025 at 01:37:19PM +0200, Claudius Heine wrote:
> On Tue Jun 17, 2025 at 11:56 AM CEST, Mikko Rapeli wrote:
> > On Tue, Jun 17, 2025 at 11:32:37AM +0200, Claudius Heine wrote:
> >> On Tue Jun 17, 2025 at 10:54 AM CEST, Lennart Poettering wrote:
> >> > On Di, 17.06.25 10:33, Cla
Hi Mikko,
On Tue Jun 17, 2025 at 11:56 AM CEST, Mikko Rapeli wrote:
> Hi,
>
> On Tue, Jun 17, 2025 at 11:32:37AM +0200, Claudius Heine wrote:
>> On Tue Jun 17, 2025 at 10:54 AM CEST, Lennart Poettering wrote:
>> > On Di, 17.06.25 10:33, Claudius Heine ([email protected]) wrote:
>> >> > systemd-repart s
Hi,
On Tue, Jun 17, 2025 at 11:32:37AM +0200, Claudius Heine wrote:
> On Tue Jun 17, 2025 at 10:54 AM CEST, Lennart Poettering wrote:
> > On Di, 17.06.25 10:33, Claudius Heine ([email protected]) wrote:
> >> > systemd-repart seems to be what you are looking for. It can
> >> > create partitions at boot
On Tue Jun 17, 2025 at 10:54 AM CEST, Lennart Poettering wrote:
> On Di, 17.06.25 10:33, Claudius Heine ([email protected]) wrote:
>
>> > systemd-repart seems to be what you are looking for. It can
>> > create partitions at boot them, set up LUKS for them, lock them to TPM
>> > and put a file system ins
On Di, 17.06.25 10:33, Claudius Heine ([email protected]) wrote:
> > systemd-repart seems to be what you are looking for. It can
> > create partitions at boot them, set up LUKS for them, lock them to TPM
> > and put a file system inside. It's really the tool of choice if you
> > want to augment disk im
Hi Lennart,
On Tue Jun 17, 2025 at 10:24 AM CEST, Lennart Poettering wrote:
> On Di, 17.06.25 09:15, Claudius Heine ([email protected]) wrote:
>
>> Hi,
>>
>> I am currently looking for a way to directly create and encrypt a LUKS
>> partition using a hardware token (TPM2, in this case) without requiring
On Di, 17.06.25 09:15, Claudius Heine ([email protected]) wrote:
> Hi,
>
> I am currently looking for a way to directly create and encrypt a LUKS
> partition using a hardware token (TPM2, in this case) without requiring
> an intermediary password/keyfile.
>
> IIUC, cryptsetup doesn't communicate with a
Hi,
I am currently looking for a way to directly create and encrypt a LUKS
partition using a hardware token (TPM2, in this case) without requiring
an intermediary password/keyfile.
IIUC, cryptsetup doesn't communicate with any hardware tokens, or
creates keys in them, while systemd-cryptenroll do
On So, 11.05.25 15:07, Alien Kong ([email protected]) wrote:
> Hello,
>
> I'm currently investigating a long boot delay on our embedded Linux system
> (systemd 255.4-1ubuntu8.4, custom embedded board) as a sporadic issue.
> We noticed that `systemd-binfmt.service` takes almost 90 seconds to
> start
Hello,
I'm currently investigating a long boot delay on our embedded Linux system
(systemd 255.4-1ubuntu8.4, custom embedded board) as a sporadic issue.
We noticed that `systemd-binfmt.service` takes almost 90 seconds to start.
Here’s the serial port log:
[2025-04-24 01:53:29.060676] [ [0;32m OK
Hi, Paul
more information for reference.
Looking forward to your new reply.Thank you!
1.We changed the default startup Timeout to 60s in /etc/systemd/system.conf.
DefaultTimeoutStartSec=60s
more system.conf information for reference.
[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor
Hi, Paul
Thank you for your reply.
This is a low-probability, sporadic problem. Currently, there is no
`journalctl -b` information with `debug` on the command line.
The unit information of the two services is as follows:
1. systemctl cat systemd-resolved
# /usr/lib/systemd/system/systemd-resolv
Dear Alien,
Am 10.05.25 um 10:24 schrieb Alien Kong:
I'm seeing an unexpected 90s delay between systemd-sysctl.service and
systemd-resolved.service
in our boot sequence (systemd 255.4-1ubuntu8.4, custom embedded board).
systemd-analyze critical-chain shows:
multi-user.target @1min 54.340s
└─u
Hello,
I'm seeing an unexpected 90s delay between systemd-sysctl.service and
systemd-resolved.service
in our boot sequence (systemd 255.4-1ubuntu8.4, custom embedded board).
systemd-analyze critical-chain shows:
multi-user.target @1min 54.340s
└─user_medium_priority.service @1min 32.653s +21.686s
Thanks for you help, guys!
The culprit was the initramfs. Regenerating it with "sudo dracut --force" (on
Fedora Linux) fixed the issue.
Have a good day!
On Fr, 18.04.25 00:35, EpicTux123 ([email protected]) wrote:
> Hello there.
>
> I had the following file in my system:
>
> /etc/sysctl.d/90-custom-mtu-probing.conf
> net.ipv4.tcp_mtu_probing=1
>
> I deleted that file and rebooted my system.
> But the "net.ipv4.tcp_mtu_probing" value is still "1
It was <2025-04-18 pią 00:35>, when EpicTux123 wrote:
> I had the following file in my system:
>
> /etc/sysctl.d/90-custom-mtu-probing.conf
> net.ipv4.tcp_mtu_probing=1
>
> I deleted that file and rebooted my system. But the
> "net.ipv4.tcp_mtu_probing" value is still "1", even though its default
Hello there.
I had the following file in my system:
/etc/sysctl.d/90-custom-mtu-probing.conf
net.ipv4.tcp_mtu_probing=1
I deleted that file and rebooted my system.
But the "net.ipv4.tcp_mtu_probing" value is still "1", even though its default
is "0".
I have tried to use "sudo sysctl -w net.ipv
Hi,
I tried to use the example [1] to use sd-event memory pressure and hit
some problems.
First, I wrote the code to use sd_event_loop and the memory pressure
event was correctly captured and the callback ran. Then, I used the
example [1] to use glib to poll the event. I found sd_event_wait()
alwa
Hi Matthew.
On Wed, Oct 02, 2024 at 08:10:04AM GMT, Matthew Chae
wrote:
> https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#MemoryAccounting=
The implicit accounting is from kernel PoV. With the unified cgroup
hierarchy, same granularity applies to all siblin
On Di, 09.07.24 18:02, Laurent GUERBY ([email protected]) wrote:
> Hi,
>
> On a debian testing system (systemd 256.2-1) I created a user with:
>
> trixie# homectl create utest --storage=luks --ssh-authorized-keys="xxx"
>
> The I used ssh to login as the user
>
> ssh utest@trixie
>
> And it all wo
On Tue, Jul 09, 2024 at 12:13:38PM +0200, Lennart Poettering wrote:
> On Mo, 08.07.24 15:57, Demi Marie Obenour ([email protected]) wrote:
>
> > On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> > > On Do, 04.07.24 12:44, Demi Marie Obenour ([email protected]
Hi,
On a debian testing system (systemd 256.2-1) I created a user with:
trixie# homectl create utest --storage=luks --ssh-authorized-keys="xxx"
The I used ssh to login as the user
ssh utest@trixie
And it all worked as described here as new feature of systemd 256:
https://mastodon.social/@pid
On Mo, 08.07.24 15:57, Demi Marie Obenour ([email protected]) wrote:
> On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> > On Do, 04.07.24 12:44, Demi Marie Obenour ([email protected])
> > wrote:
> >
> > > > No, these belong to your process, systemd couldn'
On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> On Do, 04.07.24 12:44, Demi Marie Obenour ([email protected]) wrote:
>
> > > No, these belong to your process, systemd couldn't really reach into
> > > your processes to close them, even if it wanted to.
> > >
> > > Bu
Hello,
I've recently discovered repart systemd tool, and I would like to ditch
bash scripting in favor of systemd-reparted. What I'm trying to do:
- From initrd, before mounting /sysroot or /sysusr grow partition
/dev/mmcblk0p2 with type linux-generic.
- Encrypt this partition with key-f
On Do, 04.07.24 21:48, Zheng Chuan ([email protected]) wrote:
> >> I have some processes in my initrd needed to be excluded from the killing
> >> spree
> >> during switch-root and needed to continue to run in the root file system.
> >> I read
> >> the ROOT_STORAGE_DAEMONS.md and the source c
On Do, 04.07.24 12:44, Demi Marie Obenour ([email protected]) wrote:
> > No, these belong to your process, systemd couldn't really reach into
> > your processes to close them, even if it wanted to.
> >
> > But do note that any files you keep open or mapped at the moment of
> > transitio
On Thu, Jul 04, 2024 at 03:18:04PM +0200, Lennart Poettering wrote:
> On Do, 04.07.24 11:24, chenruyi (A) ([email protected]) wrote:
>
> > Hi,
> >
> > I have some processes in my initrd needed to be excluded from the killing
> > spree
> > during switch-root and needed to continue to run in the
On Do, 04.07.24 11:24, chenruyi (A) ([email protected]) wrote:
> Hi,
>
> I have some processes in my initrd needed to be excluded from the killing
> spree
> during switch-root and needed to continue to run in the root file system. I
> read
> the ROOT_STORAGE_DAEMONS.md and the source code of
On Mo, 01.07.24 12:56, 松藤 諒太 ([email protected]) wrote:
Hi!
> At this condition, I've found that systemd-resolved performed to return the
> result of those queries to application
> unless all queries are completed being resolved via one of multiple
> interfaces.
we have two ru
On Mon, Jul 1, 2024 at 6:57 AM 松藤 諒太
wrote:
> Dear contributers for systemd-resolved:
>
> Hello. I'm Ryota Matsufuji.
>
> Could I ask a question about the behavior of systemd-resolved?
>
> When being requested v4 and v6 address by application(such as wget with
> default option or firefox),
> depe
Dear contributers for systemd-resolved:
Hello. I'm Ryota Matsufuji.
Could I ask a question about the behavior of systemd-resolved?
When being requested v4 and v6 address by application(such as wget with
default option or firefox),
depending on the interfaces' configuration, I watched multiple
On Wed, 2024-05-22 at 17:42 +0200, Lennart Poettering wrote:
> On Mi, 22.05.24 17:13, Nop ([email protected]) wrote:
>
> > Hello folks,
> > I have a question about what you guys considers to be the
> > right/expect way.
> >
> > I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and,
To me, just like you, it all started with me trying to detect if
running as part of systemd service or not.
And by that I really mean: user clicked somewhere, or typed in some
command in an input box or a TE, without having to be aware that
systemd is involved under the hood or not.
I do get that i
On 23.05.2024 09:18, Nop wrote:
From my terminal emulator that I start by clicking in the menu:
echo "kitty: $(pidof kitty) - $INVOCATION_ID" && echo "plasmashell:
$(pidof plasmashell) - $(sudo strings /proc/$(pidof
plasmashell)/environ | grep INVOCATION_ID)"
kitty: 4441 - e3ec804609094a139948a1
>From my terminal emulator that I start by clicking in the menu:
echo "kitty: $(pidof kitty) - $INVOCATION_ID" && echo "plasmashell:
$(pidof plasmashell) - $(sudo strings /proc/$(pidof
plasmashell)/environ | grep INVOCATION_ID)"
kitty: 4441 - e3ec804609094a139948a1887c90ac7a
plasmashell: 857 - INVO
On 22.05.2024 23:35, Nop wrote:
Sorry, just noticed that I didn't "reply to all"... So Lennart is
going to receive this twice...
Le mer. 22 mai 2024 à 17:42, Lennart Poettering
a écrit :
On Mi, 22.05.24 17:13, Nop ([email protected]) wrote:
Hello folks,
I have a question about what you guys
Sorry, just noticed that I didn't "reply to all"... So Lennart is
going to receive this twice...
Le mer. 22 mai 2024 à 17:42, Lennart Poettering
a écrit :
>
> On Mi, 22.05.24 17:13, Nop ([email protected]) wrote:
>
> > Hello folks,
> > I have a question about what you guys considers to be the righ
On Mi, 22.05.24 17:13, Nop ([email protected]) wrote:
> Hello folks,
> I have a question about what you guys considers to be the right/expect way.
>
> I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to
> me, it feels like those two variables should not be propagated from
> DE
Hello folks,
I have a question about what you guys considers to be the right/expect way.
I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to
me, it feels like those two variables should not be propagated from DE.
I mean, if I start KDE Plasma, for example, using systemd, it w
Hi list,
In some cases users may want to clean up the files under /tmp only during
boot with the following configuration
# cat /etc/tmpfiles.d/fs-tmp.conf
#Type Path Mode User Group Age Argument
d! /tmp 1777 root root 14d
But according to the man page of tmpfiles.d
'''
If the exclamation mark (
> On 1 Sep 2023, at 22:36, PureLinux Betriebsführung wrote:
>
> So my question is - is there any option to set a relative value/a percentage
> for that values? Per default, it seems to be possible. So why not a user
> defined percentage?
How are you managing journal config?
If you are using
On 02.09.2023 12:22, PureLinux Betriebsführung wrote:
...
The documentation states, that there are relative values used per
default, but they are capped (as you mentioned) at a specific value. So
for me, it looks like journald is also supporting relative values.
So i am wondering about the fact
Hi,
thanks for your fast response, Andrei! It seems like i was a bit unclear
with my explanation, so we misunderstood. Sorry for that.
I meant the actual size of the filesystem, which differs from e.g. 100M
on a small SoC up to ~8G on a bigger server system. Not a specific
service, which is c
On 02.09.2023 00:29, PureLinux Betriebsführung wrote:
Hi,
i am running a bunch of partly very different systems with Debian
Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1).
If i am configuring journald, i am facing the problem, that /var/log is
having a very different size
Hi,
i am running a bunch of partly very different systems with Debian
Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1).
If i am configuring journald, i am facing the problem, that /var/log is
having a very different size on all my machines. From 100M to 8G or
something.
I think I got it.
Basically what I did was to setup a veth to link the namespace and the
host networking then setup IPs and some iptables rules to give it
Internet access. Unfortunately that weird bug keeps happening but now
I know how to do this kind of isolation.
Maybe I should bond the etherne
There's no single service option to do this, as far as I know, since it
involves a bit more than just making the interface visible.
After PrivateNetwork is enabled, the newly created namespaces need to be
explicitly given network access through the host; the same "external"
interface can't exist i
I am working on a service unit for a DHT crawler.
For some reason, it doesn't work well with the default network settings
because it seems to use a huge amount of traffic for a very small
amount of findings.
The same program works fine via docker, but I want to package it as a
hardened systemd un
On Di, 26.10.21 10:41, Arian van Putten ([email protected]) wrote:
> Hey list,
>
> I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question
>
> There are some fields in the USER_RECORD spec which are described as
> "unsigned 64 bit integer values". Specifically the fiel
Hey list,
I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question
There are some fields in the USER_RECORD spec which are described as
"unsigned 64 bit integer values". Specifically the fields describing
time.
However JSON lacks integers and only has doubles [0]; which would
Pe duminică, 16 august 2020, 20:00:10 EEST, Lennart Poettering
a scris:
On So, 16.08.20 16:35, ionut n ([email protected]) wrote:
>
> Hi SystemD Team,
>
> One question.
>
> Is it possible with systemd-journalctl to change the location to save logs in
> other location?
>
> My sys
I understand, but there is no option or any parameter in systemd to not do
through mount?
Pe duminică, 16 august 2020, 19:48:51 EEST, Tomasz Torcz
a scris:
On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote:
>
> Hi SystemD Team,
It's "systemd" (all lowercase).
>
> One quest
Hi SystemD Team,
One question.
Is it possible with systemd-journalctl to change the location to save logs in
other location?
My system is volatile (tmpfs) and I have another location available to keep
certain logs.
- /dev/root or / is tmpfs
- /external-persistent0 is ext4 or xfs
I
On So, 16.08.20 16:35, ionut n ([email protected]) wrote:
>
> Hi SystemD Team,
>
> One question.
>
> Is it possible with systemd-journalctl to change the location to save logs in
> other location?
>
> My system is volatile (tmpfs) and I have another location available to keep
> certain logs.
On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote:
>
> Hi SystemD Team,
It's "systemd" (all lowercase).
>
> One question.
>
> Is it possible with systemd-journalctl to change the location to save logs in
> other location?
>
> My system is volatile (tmpfs) and I have another location
On Mi, 26.02.20 13:50, piliu ([email protected]) wrote:
> Hi,
>
> I encountered a systemd bug during saving vmcore for kdump kernel.
>
> I got the following message:
>
> [ 60.283489] systemd[1]: Started Reload Configuration from the Real Root.
> [ 60.290912] systemd[1]: Reached target Initrd Fi
- journald
failing (Andreas Kempe)
--
Message: 1
Date: Wed, 26 Feb 2020 13:50:55 +0800
From: piliu
To: SystemD Devel
Subject: [systemd-devel] question about a poweroff issue
Message-ID:
Content-Type: text/pla
Hi,
I encountered a systemd bug during saving vmcore for kdump kernel.
I got the following message:
[ 60.283489] systemd[1]: Started Reload Configuration from the Real Root.
[ 60.290912] systemd[1]: Reached target Initrd File Systems.
[ 60.296162] systemd[1]: Reached target Initrd Default
On 2/2/19 3:44 PM, Reindl Harald wrote:
>
>
> Am 02.02.19 um 21:05 schrieb Steve Dickson:
>> On 2/2/19 2:52 PM, Reindl Harald wrote:
>>> Am 02.02.19 um 20:42 schrieb Steve Dickson:
Hello,
In a.service I have
[Unit]
Before=b.service
[Install]
Requi
On 2/2/19 4:03 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote:
>>
>>
>> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
>>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
Hello,
In a.service I have
[Unit]
Before=b.ser
On 2/2/19 4:07 PM, Uoti Urpala wrote:
> On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote:
>>> Have you enabled a.service?
>>>
>> No... I did not think I had to... I figured
>> when b.service was started, a.service would be
>> run regardless of being enabled or disabled.
>>
>> Is that no
On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote:
>
>
> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
> > On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
> >> Hello,
> >>
> >> In a.service I have
> >>
> >> [Unit]
> >> Before=b.service
> >>
> >> [Install]
> >> RequiredBy=b.
On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote:
> > Have you enabled a.service?
> >
> No... I did not think I had to... I figured
> when b.service was started, a.service would be
> run regardless of being enabled or disabled.
>
> Is that not the case?
So you just have the file for a.
Am 02.02.19 um 21:05 schrieb Steve Dickson:
> On 2/2/19 2:52 PM, Reindl Harald wrote:
>> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>>> Hello,
>>>
>>> In a.service I have
>>>
>>> [Unit]
>>> Before=b.service
>>>
>>> [Install]
>>> RequiredBy=b.service
>>>
>>> when I systemd start b.service (whi
Am 02.02.19 um 21:03 schrieb Steve Dickson:
> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>>> Hello,
>>>
>>> In a.service I have
>>>
>>> [Unit]
>>> Before=b.service
>>>
>>> [Install]
>>> RequiredBy=b.service
>>>
>>> when I systemd st
On 2/2/19 2:52 PM, Reindl Harald wrote:
>
>
> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>> Hello,
>>
>> In a.service I have
>>
>> [Unit]
>> Before=b.service
>>
>> [Install]
>> RequiredBy=b.service
>>
>> when I systemd start b.service (which happens to fail)
>> but... a.service is not bein
On 2/2/19 2:48 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>> Hello,
>>
>> In a.service I have
>>
>> [Unit]
>> Before=b.service
>>
>> [Install]
>> RequiredBy=b.service
>>
>> when I systemd start b.service (which happens to fail)
>> but... a.service
On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
> Hello,
>
> In a.service I have
>
> [Unit]
> Before=b.service
>
> [Install]
> RequiredBy=b.service
>
> when I systemd start b.service (which happens to fail)
> but... a.service is not being run.
>
> So I guess my question is w
Am 02.02.19 um 20:42 schrieb Steve Dickson:
> Hello,
>
> In a.service I have
>
> [Unit]
> Before=b.service
>
> [Install]
> RequiredBy=b.service
>
> when I systemd start b.service (which happens to fail)
> but... a.service is not being run.
>
> So I guess my question is what do I have to
Hello,
In a.service I have
[Unit]
Before=b.service
[Install]
RequiredBy=b.service
when I systemd start b.service (which happens to fail)
but... a.service is not being run.
So I guess my question is what do I have to do
to ensure a.service is *always* run before b.service?
tia,
steved.
_
On Fri, Jan 11, 2019 at 08:03:45AM +, Sietse van Zanen wrote:
> Hi,
>
>
>
> I am writing a daemon script which uses sd_notify watchdog. This works fine,
> system will kill the if the process doesn’t notify.
>
>
>
> However, I have seen in 1 occasion where, due to a programming error, th
Hi,
I am writing a daemon script which uses sd_notify watchdog. This works fine,
system will kill the if the process doesn't notify.
However, I have seen in 1 occasion where, due to a programming error, the
script got stuck in a read and was not killed where it should have been.
So my question
On Mo, 05.11.18 16:21, Liu, Shuang (ADITG/ESM) ([email protected]) wrote:
> Hi,
>
> We are facing problem with hardware watchdog.
>
> To my understanding, the watchdog is pinged inside the manager_loop(),
> which means, during e.g. systemctl daemon-reload, watchdog cannot be pinged.
>
> Here,
Hi,
We are facing problem with hardware watchdog.
To my understanding, the watchdog is pinged inside the manager_loop(),
which means, during e.g. systemctl daemon-reload, watchdog cannot be pinged.
Here, perhaps other timeouts are involved in, e.g. generator timeout, dbus
timeout, systemctl tim
Hello,
On Wed, Aug 1, 2018 at 7:36 PM, Mantas Mikulėnas wrote:
>
> AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their
> relative ordering isn't that important... but if the firmware marks a device
> as on-board *and* also provides a slot number, then it's more likely tha
On Wed, Aug 1, 2018 at 7:18 PM Francis Moreau
wrote:
> Hello,
>
> I have a question regarding the default value of NamePolicy= defined
> in 99-default.link.
>
> The value is "NamePolicy=kernel database onboard slot path"
>
> Could someone explain me why "onbard" is preferred over "slot" which
> i
Hello,
I have a question regarding the default value of NamePolicy= defined
in 99-default.link.
The value is "NamePolicy=kernel database onboard slot path"
Could someone explain me why "onbard" is preferred over "slot" which
is preferred over "path" ?
Thanks.
--
Francis
___
On Sat, Mar 24, 2018 at 5:54 PM, Brian J. Murrell
wrote:
> On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote:
> >
> > Which systemd version do you run? In v232,
>
> systemd-219-42.el7_4.10.x86_64
>
> > nss-lookup.target:Description=Host and Network Name Lookups
> > nss-user-lookup.target:
On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote:
>
> Which systemd version do you run? In v232,
systemd-219-42.el7_4.10.x86_64
> nss-lookup.target:Description=Host and Network Name Lookups
> nss-user-lookup.target:Description=User and Group Name Lookups
Same here:
# systemctl show ns
On Fri, Mar 23, 2018 at 9:52 PM, Brian J. Murrell
wrote:
> On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote:
> >
> > No, dependencies do not imply any specific ordering. (The only
> > exception is
> > when a .target wants/requires another unit.)
>
> That seems odd but I will leave that a
On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote:
>
> No, dependencies do not imply any specific ordering. (The only
> exception is
> when a .target wants/requires another unit.)
That seems odd but I will leave that aside for a moment...
> In other words, you will need to additionally l
On Fri, Mar 23, 2018 at 5:41 PM, Brian J. Murrell
wrote:
> If I have:
>
> Wants=system.slice nss-lookup.target named-setup-rndc.service
>
> in named-pkcs11.service, so shouldn't mean that named-pkcs11.service
> will be started up before the nss-lookup.target is Reached/Started?
>
No, dependencie
If I have:
Wants=system.slice nss-lookup.target named-setup-rndc.service
in named-pkcs11.service, so shouldn't mean that named-pkcs11.service
will be started up before the nss-lookup.target is Reached/Started?
That doesn't seem to be the case on my system:
Mar 23 09:44:03 server.interlinx.bc.ca
if you have the mentionned file (/usr/lib/systemd/system/rpcbind.socket)
then systemd will open whatever port is described in there and pass it
pre-opened to rpcbind.
systemd has no idea what that port is for and the file mentionned above
was provided to systemd by the rpcbind package. You s
Hello evryone,
I would like to ask you a question regarding the new random UDP port in
rpcbind 0.2.3.
In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
rpcbind.service, then I do netstat
udp0 0 0.0.0.0:111 0.0.0.0:*
10408/rpcbind
udp0 0 0.0
On Fr, 29.12.17 17:19, eshark ([email protected]) wrote:
> Hi, All
> I tried to test the socket activation by a simple foobar.socket and
> foobar.service, which are as the following:
> foobar.socket:
>[Socket]
>ListenStream=/dev/socket/foobar
>
>
>[Install]
>
The program source codes and the foobar.service , the foobar.socket are as the
attachments.
Thanks for any suggestion!
At 2017-12-29 16:19:35, "eshark" wrote:
Hi, All
I tried to test the socket activation by a simple foobar.socket and
foobar.service, which are as the following:
Hi, All
I tried to test the socket activation by a simple foobar.socket and
foobar.service, which are as the following:
foobar.socket:
[Socket]
ListenStream=/dev/socket/foobar
[Install]
WantedBy=sockets.target
foobar.service:
[Service]
On Thu, Nov 30, 2017 at 7:19 AM, Vengatesh R
wrote:
> Hi Team,
>
>
>
> AIX 7.1 nodes area not reporting to puppet master. Please find the below
> details.
>
>
>
> Puppet master : Red hat Linux 7.3 x86_64
>
Hi,
this is not the Puppet mailing list, not the AIX mailing list, and not the
Red Hat su
Hi all,
Thank you very much for your support.
I will try to fix the cycle.
Brs,
On Mon, Nov 27, 2017 at 4:11 PM, Reindl Harald
wrote:
>
>
> Am 27.11.2017 um 05:23 schrieb Bao Nguyen:
>
>> Thanks all for your comments. I will try to use option FreeBind. However
>> could anyone explain for me t
Hi Team,
AIX 7.1 nodes area not reporting to puppet master. Please find the below
details.
Puppet master : Red hat Linux 7.3 x86_64
The information in this e-mail and any attachments is confidential and may be
legally privileged. It is intended solely for the addressee or addressees. Any
use
Thank you.
I know have a deeper understanding of the this topic :)
Regards.
Chiba
2017年11月28日(火) 23:32 Lennart Poettering :
> f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 ([email protected]) wrote:
>
> > We have a few questions about systemctl and -H option.
> >
> > It looks like systemctl is communica
f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 ([email protected]) wrote:
> We have a few questions about systemctl and -H option.
>
> It looks like systemctl is communicating with /run/systemd/private in order
> to interact with systemd.
>
> However, after you log in the connected computer via ssh, it lo
Hi, i asked similar question a few weeks ago, and you probably will get a
oficial answer soon :P, but in a nutshell would be:
/run/systemd/private is a private socket and its meant for systemd tools to
communicate with systemd even if dbus daemon is down. this is specially
true during boot and shu
1 - 100 of 395 matches
Mail list logo
