Re: [systemd-devel] systemd-networkd: Failure to add slave interface to bridge

2023-01-31 Thread Mantas Mikulėnas
 31 11:05:12 sarkovy systemd-networkd[1294]: No change in value '0',
> suppressing write
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: Setting
> '/proc/sys/net/ipv4/conf/vpn_rpi400/promote_secondaries' to '1'
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: No change in value '1',
> suppressing write
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Requested to
> set link flags
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Requested to
> set IPv6LL address generation mode
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Requested to
> set master interface
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Requested to
> set bridge configurations
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Requested to
> activate link
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400:
> link_check_ready(): link layer is configuring.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Setting link
> flags
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Setting
> IPv6LL address generation mode
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Setting
> master interface
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: link flags set.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: IPv6LL
> address generation mode set.
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Failed to
> set master interface: Invalid argument
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: Failed
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: vpn_rpi400: State
> changed: configuring -> failed
> Jan 31 11:05:12 sarkovy systemd-networkd[1294]: Sent message type=signal
> sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=50 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 31 11:05:26 sarkovy systemd-networkd[1294]: Got message
> type=method_call sender=:1.215 destination=org.freedesktop.network1
> path=/org/freedesktop/network1 interface=org.freedesktop.DBus.Properties
> member=Get cookie=2 reply_cookie=0 signature=ss error-name=n/a
> error-message=n/a
> Jan 31 11:05:26 sarkovy systemd-networkd[1294]: Sent message
> type=method_return sender=n/a destination=:1.215 path=n/a interface=n/a
> member=n/a cookie=51 reply_cookie=2 signature=v error-name=n/a
> error-message=n/a
> Jan 31 11:06:35 sarkovy systemd-networkd[1294]: Got message
> type=method_call sender=:1.216 destination=org.freedesktop.network1
> path=/org/freedesktop/LogControl1
> interface=org.freedesktop.DBus.Properties member=Set cookie=3
> reply_cookie=0 signature=ssv error-name=n/a error-message=n/a
> Jan 31 11:06:35 sarkovy systemd-networkd[1294]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.DBus
> path=/org/freedesktop/DBus interface=org.freedesktop.DBus
> member=GetConnectionUnixUser cookie=52 reply_cookie=0 signature=s
> error-name=n/a error-message=n/a
> Jan 31 11:06:35 sarkovy systemd-networkd[1294]: Got message
> type=method_return sender=org.freedesktop.DBus destination=:1.12
> path=n/a interface=n/a member=n/a cookie=4294967295 reply_cookie=52
> signature=u error-name=n/a error-message=n/a
>
>
> These are the contents of /etc/systemd/network/50-vpn.network:
>
> [Match]
> Name = vpn_*
>
> [Link]
> RequiredForOnline = no
> ActivationPolicy = up
> ARP = no
>
> [Network]
> Description = VPN interface
> DHCP = no
> DHCPServer = no
> LinkLocalAddressing = no
> DefaultRouteOnDevice = no
> LLMNR = no
> IPv6AcceptRA = no
> Bridge = br_lan
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd-homed: Change group membership without root and user passwords

2023-01-20 Thread Mantas Mikulėnas
If I remember correctly, groups (except "usergroups") are not managed by
systemd-homed; they're still managed by shadow via /etc/group. So an admin
can just add any username to /etc/group using `vigr`, regardless of that
user's origin.

(Even if groups *were* managed by systemd-homed, I think the default setup
of /etc/nsswitch.conf is that group memberships from all sources are
merged?)

On Fri, Jan 20, 2023 at 4:42 PM eric  wrote:

> Hey everyone on systemd-devel
>
> Is there somehow a method to change group membership without having the
> user's password ?
>
> Usually its an admin task to maintain group membership and she has no
> user passwords.
>
> But when its the users task to join a group, the user needs the admin
> password, this is also a bad situation.
>
> Is it possible to add more than one password ?
>
> /eric
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] [Question] How to make services only see only one external network interface and loopback

2023-01-17 Thread Mantas Mikulėnas
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 in two namespaces at once, so in Docker you usually
have a virtual one.

One method is a pair of 'veth' interfaces – one end stays in the host
namespace, one is moved into the container namespace, and you have a
virtual Ethernet cable between the two. The host end then usually goes into
a bridge, and the host does routing and often NAT (just like it would for
full VMs). Something needs to assign internal IP addresses to both
interfaces, and something needs to add those NAT rules.

(Another method is to create a 'macvlan' interface off the physical
interface and give it to the container, which then gets its own IP address
directly from the LAN.)

It would be possible to do this with systemd services (maybe systemd-nspawn
to set up namespaces plus networkd to configure the interfaces), but
probably far more hacky than using a container runtime that does all such
configuration by default.

On Tue, Jan 17, 2023, 22:04 Lucas Eduardo  wrote:

> 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 unit.
>
> A difference between the network layout in Docker and the host is that
> Docker only exposes the "lo" interface and an upstream one, and the host
> exposes everything and I think it's causing some kind of conflict.
>
> How can I implement this Docker behaviour in systemd?
>
> I tried using PrivateNetwork but it kills any Internet access because
> only localhost is available.
>
> Is there any not so well known feature to implement this?
>
> I am running systemd 251.7 on NixOS. I already have experience
> converting systemd stuff to the way the NixOS module system understands.
>
> Thanks in advance
>


Re: [systemd-devel] Systemd sessionid like `c508`

2023-01-10 Thread Mantas Mikulėnas
The sessions listed in loginctl are created and their IDs assigned by
systemd-logind (when asked by pam_systemd).

If /proc/*/loginuid and /proc/*/sessionid are available (set up by
pam_loginuid), then logind directly takes the audit session ID as logind
session ID.

If those are not available (kernel audit support disabled), then logind
itself allocates a logind session ID and adds the "c" prefix to prevent
collisions with audit IDs.

src/login/logind-dbus.c:870:if (asprintf(,
"c%lu", ++m->session_counter) < 0)

On Wed, Jan 11, 2023, 05:58 hai wu  wrote:

> Where is the systemd sessionid like `c508` being generated? If kernel
> auditd is disabled, then it seems systemd `loginctl list-sessions`
> command would list user session ids all with `c` character prefix
> instead.
>
> I could not find the source code where these session ids got
> generated. Are these session ids generated from systemd source code or
> from Linux kernel source code?
>
> systemd has this function `sd_pid_get_session` to get session id, it
> seems that's parsing `/proc/self/cgroup`, instead of generating such
> session ids..
>
> Regards,
> Hai
>


Re: [systemd-devel] Syslog forwarding not working within journal namespace

2022-12-28 Thread Mantas Mikulėnas
Each namespace has its own journald service instance, in this case
systemd-journald@my-namespace.service, and each such instance has been
programmed to build the runtime directory name from the specified instance
name. So the new journald process that handles "my-instance" uses
/run/systemd/journald.my-namespace for all sockets.

On Wed, Dec 28, 2022, 17:06 Aaron Enberg  wrote:

> I found a minimal solution, which I don't quite understand.
> I ended up creating an rsyslog config at /etc/rsyslog.d/my-namespace.conf
> with the content:
>
> input(type="imuxsock" Socket="/run/systemd/journal.my-namespace/syslog")
>
> I guess with this rsyslog manages the socket, creating it if it doesn't
> exist.
> It seems like magic to me though. I didn't configure anything else. How
> does journald know to write to this new socket?
>
>
> On Wed, Dec 28, 2022 at 9:55 AM Mantas Mikulėnas 
> wrote:
>
>> The easiest way might be to just symlink it from the existing socket with
>> `ln -s ../journal/syslog /run/systemd/journal.my-namespace`... other than
>> that, depends on the syslog daemon, e.g. an additional unix-stream() for
>> syslog-ng or imuxsock for rsyslogd. (The socket for the main namespace is
>> set up through syslog.socket, but not sure whether adding a second
>> ListenStream= would work for that.)
>>
>> On Wed, Dec 28, 2022 at 2:05 PM Aaron Enberg 
>> wrote:
>>
>>> /run/systemd/journal/syslog exists and I am sure that
>>> ForwardToSyslog=yes is set on the default namespace.
>>>
>>> I’d like to setup an additional socket at
>>> /run/systemd/journal.my-namespace/syslog to forward logs to syslog from my
>>> own namespace. Can you point me to the documentation for how I should do
>>> this?
>>>
>>>
>>> On Wed, Dec 28, 2022 at 2:32 AM Mantas Mikulėnas 
>>> wrote:
>>>
>>>> The forwarding itself is namespaced. ForwardToSyslog relies on the
>>>> syslogd daemon setting up a receiving socket at /run/systemd/journal/syslog
>>>> through which journald will send the messages – but for namespaced
>>>> journald, the runtime directory is different (the point of it being
>>>> namespaced) so the syslogd needs to set up an additional socket at
>>>> /run/systemd/journal.my-namespace/syslog as well.
>>>>
>>>> (Though are you sure the system was using ForwardToSyslog, and not some
>>>> other method? The default configuration of both rsyslog and syslog-ng no
>>>> longer uses this forwarding style, instead the syslogd directly imports
>>>> messages from .journal files – which again needs the syslogd to be
>>>> configured to read from the namespaced path in addition to the default
>>>> path.)
>>>>
>>>> On Tue, Dec 27, 2022 at 11:01 PM Aaron Enberg 
>>>> wrote:
>>>>
>>>>> Hi maintainers,
>>>>>
>>>>> I am trying to get syslog forwarding working with a journal namespace
>>>>> I created for my application.
>>>>>
>>>>> My system is on Debian 11, systemd 247 (247.3-7+deb11u1)
>>>>>
>>>>> Originally, my service used the default namespace and forwarding to 
>>>>> syslog was working. After creating a journal namespace and assigning my 
>>>>> service to it with
>>>>> LogNamespace=my-namespace now the logs from my application do not get
>>>>> forwarded to syslog.
>>>>>
>>>>> I have made sure /etc/systemd/journ...@my-namespace.conf exists and 
>>>>> contains the
>>>>> setting ForwardToSyslog=yes. I actually just copied the default config at
>>>>> /etc/systemd/journal.conf which has forwarding enabled by default. I can 
>>>>> see the
>>>>> logs in the journal with journalctl --namespace my-namespace.
>>>>>
>>>>> I haven't seen any bugs reported on this so I must be missing something.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mantas Mikulėnas
>>>>
>>>
>>
>> --
>> Mantas Mikulėnas
>>
>


Re: [systemd-devel] Syslog forwarding not working within journal namespace

2022-12-28 Thread Mantas Mikulėnas
The easiest way might be to just symlink it from the existing socket with
`ln -s ../journal/syslog /run/systemd/journal.my-namespace`... other than
that, depends on the syslog daemon, e.g. an additional unix-stream() for
syslog-ng or imuxsock for rsyslogd. (The socket for the main namespace is
set up through syslog.socket, but not sure whether adding a second
ListenStream= would work for that.)

On Wed, Dec 28, 2022 at 2:05 PM Aaron Enberg  wrote:

> /run/systemd/journal/syslog exists and I am sure that ForwardToSyslog=yes
> is set on the default namespace.
>
> I’d like to setup an additional socket at
> /run/systemd/journal.my-namespace/syslog to forward logs to syslog from my
> own namespace. Can you point me to the documentation for how I should do
> this?
>
>
> On Wed, Dec 28, 2022 at 2:32 AM Mantas Mikulėnas 
> wrote:
>
>> The forwarding itself is namespaced. ForwardToSyslog relies on the
>> syslogd daemon setting up a receiving socket at /run/systemd/journal/syslog
>> through which journald will send the messages – but for namespaced
>> journald, the runtime directory is different (the point of it being
>> namespaced) so the syslogd needs to set up an additional socket at
>> /run/systemd/journal.my-namespace/syslog as well.
>>
>> (Though are you sure the system was using ForwardToSyslog, and not some
>> other method? The default configuration of both rsyslog and syslog-ng no
>> longer uses this forwarding style, instead the syslogd directly imports
>> messages from .journal files – which again needs the syslogd to be
>> configured to read from the namespaced path in addition to the default
>> path.)
>>
>> On Tue, Dec 27, 2022 at 11:01 PM Aaron Enberg 
>> wrote:
>>
>>> Hi maintainers,
>>>
>>> I am trying to get syslog forwarding working with a journal namespace I
>>> created for my application.
>>>
>>> My system is on Debian 11, systemd 247 (247.3-7+deb11u1)
>>>
>>> Originally, my service used the default namespace and forwarding to syslog 
>>> was working. After creating a journal namespace and assigning my service to 
>>> it with
>>> LogNamespace=my-namespace now the logs from my application do not get
>>> forwarded to syslog.
>>>
>>> I have made sure /etc/systemd/journ...@my-namespace.conf exists and 
>>> contains the
>>> setting ForwardToSyslog=yes. I actually just copied the default config at
>>> /etc/systemd/journal.conf which has forwarding enabled by default. I can 
>>> see the
>>> logs in the journal with journalctl --namespace my-namespace.
>>>
>>> I haven't seen any bugs reported on this so I must be missing something.
>>>
>>> Regards,
>>>
>>> Aaron
>>>
>>>
>>
>> --
>> Mantas Mikulėnas
>>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] Syslog forwarding not working within journal namespace

2022-12-27 Thread Mantas Mikulėnas
The forwarding itself is namespaced. ForwardToSyslog relies on the syslogd
daemon setting up a receiving socket at /run/systemd/journal/syslog through
which journald will send the messages – but for namespaced journald, the
runtime directory is different (the point of it being namespaced) so the
syslogd needs to set up an additional socket at
/run/systemd/journal.my-namespace/syslog as well.

(Though are you sure the system was using ForwardToSyslog, and not some
other method? The default configuration of both rsyslog and syslog-ng no
longer uses this forwarding style, instead the syslogd directly imports
messages from .journal files – which again needs the syslogd to be
configured to read from the namespaced path in addition to the default
path.)

On Tue, Dec 27, 2022 at 11:01 PM Aaron Enberg  wrote:

> Hi maintainers,
>
> I am trying to get syslog forwarding working with a journal namespace I
> created for my application.
>
> My system is on Debian 11, systemd 247 (247.3-7+deb11u1)
>
> Originally, my service used the default namespace and forwarding to syslog 
> was working. After creating a journal namespace and assigning my service to 
> it with
> LogNamespace=my-namespace now the logs from my application do not get
> forwarded to syslog.
>
> I have made sure /etc/systemd/journ...@my-namespace.conf exists and contains 
> the
> setting ForwardToSyslog=yes. I actually just copied the default config at
> /etc/systemd/journal.conf which has forwarding enabled by default. I can see 
> the
> logs in the journal with journalctl --namespace my-namespace.
>
> I haven't seen any bugs reported on this so I must be missing something.
>
> Regards,
>
> Aaron
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] missed _netdev option for nfs

2022-11-30 Thread Mantas Mikulėnas
On Thu, Dec 1, 2022 at 7:41 AM Дмитрий Марков 
wrote:

> Hello, please help me understand the logic of fstab-generator.
>
> this option is really added and works. But it confuses me that I do not
> see it in the output of the mount command. It seems to me that this
> behavior is wrong and may be the result of some bug.
>

The output of the `mount` command is *not* copied 1:1 from fstab, it is
mostly generated by the kernel – i.e. the filesystem driver itself decides
what "active" options to report back to userspace – so it will never report
"mount-time" options such as _netdev or x-something, as those options
weren't given to the filesystem in the first place (they were consumed by
`mount` and/or by systemd).

(There are some exceptions – a few such options get stored in
/run/mount/utab so that `mount` will report them – but _netdev isn't
stored, as it has no use after the mount has already happened.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: Re: Antw: [EXT] [systemd???devel] starting networking from within single user mode?

2022-11-14 Thread Mantas Mikulėnas
On Mon, Nov 14, 2022 at 10:19 AM Michael Chapman 
wrote:

> On Mon, 14 Nov 2022, Ulrich Windl wrote:
> [...]
> > Wow! never heard of that option. Is that a kind of target, or what is
> the mechanism?
> > Which of the 196 (man -k systemd | wc -l) systemd-related manual pages
> would describe it? ;-)
>
> A small correction to my previous email: this particular boot parameter is
> actually documented in kernel-command-line(7). It's not implemented by
> PID 1 itself.
>
> And it should actually be "systemd.debug_shell" with an underscore, not a
> hyphen.
>

proc_cmdline_key_streq() treats - and _ as identical (behaving like kernel
options, I believe).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: [EXT] [systemd???devel] starting networking from within single user mode?

2022-11-14 Thread Mantas Mikulėnas
On Mon, Nov 14, 2022 at 9:00 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 11.11.2022 um 15:49 in
> Nachricht
> :
> > On Fri, Nov 11, 2022 at 4:19 PM Brian Reichert 
> wrote:
> >
> >> On Fri, Nov 11, 2022 at 08:02:00AM +0100, Ulrich Windl wrote:
> >> > >>> Brian Reichert  schrieb am 10.11.2022 um
> >> 23:04 in
> >> > Nachricht <20221110220426.ga17...@numachi.com>:
> >> > > I've managed to hose a SLES12 SP5 host; it starts to boot, then
> hangs.
> >> >
> >> > And what did you do to mess it up? And what do the boot messages say?
> >>
> >> A good question, and not specific to systemd, so I don't want to
> >> pollute the list archives too much on this matter.
> >>
> >> 'All' I did was remove many RPMs that I arbitrarily deemed
> >> unnecessary.
> >>
> >> I came up with a heavily trimmed-down list of SLES RPM for my SLES12
> >> Sp5 environment.
> >>
> >> I successfully installed a server using just that trimmed-down list;
> >> yay me!
> >>
> >> I then explored 'upgrading' a running (slight older) SP5 box, using
> >> this trimmed-down list.  A purposeful side effect was to uninstall
> >> RPMs not in that trimmed-down list.
> >>
> >> This latter box begins to boot, and gets at least as far as loading
> >> the initrd image, before hanging.
> >>
> >
> > Boot with "systemd.debug-shell" and use tty9 to investigate from the
> inside.
>
> Wow! never heard of that option. Is that a kind of target, or what is the
> mechanism?
> Which of the 196 (man -k systemd | wc -l) systemd-related manual pages
> would describe it? ;-)
>

The more I read your smartass sarcastic comments here, the less I feel like
staying on this list and helping *other* people with finding stuff in those
196 systemd-related manual pages. But I suppose that's what you want to
achieve, so that you can snark even more about how "systemd is so complex
that nobody's bothering to reply to the list anymore"?

For those who have *actually* never heard of that option, it is documented
in systemd-debug-generator(8).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: [EXT] [systemd???devel] starting networking from within single user mode?

2022-11-11 Thread Mantas Mikulėnas
On Fri, Nov 11, 2022 at 4:19 PM Brian Reichert  wrote:

> On Fri, Nov 11, 2022 at 08:02:00AM +0100, Ulrich Windl wrote:
> > >>> Brian Reichert  schrieb am 10.11.2022 um
> 23:04 in
> > Nachricht <20221110220426.ga17...@numachi.com>:
> > > I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.
> >
> > And what did you do to mess it up? And what do the boot messages say?
>
> A good question, and not specific to systemd, so I don't want to
> pollute the list archives too much on this matter.
>
> 'All' I did was remove many RPMs that I arbitrarily deemed
> unnecessary.
>
> I came up with a heavily trimmed-down list of SLES RPM for my SLES12
> Sp5 environment.
>
> I successfully installed a server using just that trimmed-down list;
> yay me!
>
> I then explored 'upgrading' a running (slight older) SP5 box, using
> this trimmed-down list.  A purposeful side effect was to uninstall
> RPMs not in that trimmed-down list.
>
> This latter box begins to boot, and gets at least as far as loading
> the initrd image, before hanging.
>

Boot with "systemd.debug-shell" and use tty9 to investigate from the inside.

-- 
Mantas Mikulėnas


Re: [systemd-devel] starting networking from within single user mode?

2022-11-10 Thread Mantas Mikulėnas
On Fri, Nov 11, 2022 at 12:04 AM Brian Reichert 
wrote:

> I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.
>
> If I get it into single-user mode (getting into the grub menu, and adding
> init=/bin/bash) I can at least review the file system.
>
> What I want to do is get networking running, so that I can at least gather
> logs, etc.
>
> When I try to start networking with 'systemctl', I see this error:
>
> systemd "failed to connect to bus; No such file or directory"
>
> What can I do to minimally bring up the networking service? I don't even
> have any network devices at this point...
>

Running without init isn't really single-user mode. You won't be able to
start any services using systemctl without init, because... systemctl
controls init. You also won't have any network devices because drivers for
those are loaded by a service that's not running without init (namely
systemd-udevd).

Boot with either "s" (aka "single" aka "rescue") or "-b" (aka "emergency")
for two variants of single-user mode with init. The former starts some
basic stuff (it's the real single-user mode) including udev so that modules
for your network interfaces still get loaded automatically, while the
latter doesn't start anything except init and a shell (emergency mode is
*almost* like init=/bin/sh but in theory might at least let you `systemctl
start` something).

If udev is not running, try to `modprobe` whichever drivers you need for
the Ethernet interface. (The name can be found by PCI ID, e.g. for
10ec:8136 "grep -i 10EC.*8136 /lib/modules/`uname -r`/modules.alias") Then
manually bring eth0 up, add the IP address, add a default route (dhclient
or dhcpcd will also work without udev, while systemd-networkd probably
won't).

ip link set eth0 up
ip addr add 192.168.1.55/24 dev eth0
ip route add default via 192.168.1.1

-- 
Mantas Mikulėnas


Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

2022-11-05 Thread Mantas Mikulėnas
On Sat, Nov 5, 2022 at 12:52 PM TJ  wrote:

> On 05/11/2022 10:36, Mantas Mikulėnas wrote:
> > On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:
> >
> >> Just seen this announcement in the v252 changelog:
> >>
> >> "We intend to remove support for split-usr (/usr mounted separately
> >> during boot) ..."
> >>
> >> How does this align with support for separate /usr/ with dm-verity ?
> >>
> >> For example, this will affect nspawn. See "man 1 systemd-nspawn" and
> >> "--root-hash=" where in respect of /usr/ it says:
> >>
> >> "Note that this configures the root hash for the root file system. Disk
> >> images may also contain separate file systems for the /usr/ hierarchy,
> >> which may be Verity protected as well. The root hash for this protection
> >> may be configured via the "user.verity.usrhash" extended file attribute
> >> or via a .usrhash file adjacent to the disk image, following the same
> >> format and logic as for the root hash for the root file system described
> >> here."
> >>
> >
> > /usr can remain on a separate partition as long as it's mounted *by the
> > initrd* (the same way initrd currently mounts your rootfs), so that by
> the
> > time systemd starts it already has the full filesystem.
>
> How does this work when systemd is used inside the initrd, as
> "recommended" / discussed at, for example "Using systemd inside an initrd"
> :
>

>From the initrd's perspective, it's not being mounted *at* /usr – it's
being mounted at /newroot/usr or such (like how the rootfs itself is
mounted at /newroot). The initrd has its own / and its own /usr.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

2022-11-05 Thread Mantas Mikulėnas
On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:

> Just seen this announcement in the v252 changelog:
>
> "We intend to remove support for split-usr (/usr mounted separately
> during boot) ..."
>
> How does this align with support for separate /usr/ with dm-verity ?
>
> For example, this will affect nspawn. See "man 1 systemd-nspawn" and
> "--root-hash=" where in respect of /usr/ it says:
>
> "Note that this configures the root hash for the root file system. Disk
> images may also contain separate file systems for the /usr/ hierarchy,
> which may be Verity protected as well. The root hash for this protection
> may be configured via the "user.verity.usrhash" extended file attribute
> or via a .usrhash file adjacent to the disk image, following the same
> format and logic as for the root hash for the root file system described
> here."
>

/usr can remain on a separate partition as long as it's mounted *by the
initrd* (the same way initrd currently mounts your rootfs), so that by the
time systemd starts it already has the full filesystem.

What's finally being removed is support for having the rootfs itself mount
/usr halfway through, which requires many things that normally are on
/usr/lib to be split between it and /lib instead (such as on Debian).

Using the initrd to mount /usr isn't new.
<https://web.archive.org/web/20150906203654if_/https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html>

-- 
Mantas Mikulėnas


Re: [systemd-devel] How to get a useful peer address when doing accept(3, ...) on a systemd supplied listening socket

2022-10-27 Thread Mantas Mikulėnas
On Thu, Oct 27, 2022 at 1:51 PM Klaus Ebbe Grue  wrote:

> Hi systemd-devel,
>
> Sorry to bug you with another user question.
>
> I have a socket activated daemon, call it mydaemon, and I have trouble
> finding out who connects to it.
>
>
> mydaemon.socket contains:
>
>
>   [Socket]
>   ListenStream=
>
> When I connect using IPv4 using
>
>   nc -4 localhost 
>
> then mydaemon does
>
>   sockaddr_in6 peer;
>   socklen_t peer_size=sizeof(peer);
>   accept(3,(struct sockaddr *),sizeof(peer))
>
> Afterwards, peer.sin6_family is AF_INET6 and peer.sin6_addr contains some
> gibberish like a00:e5ae::
>

If you specify nothing for the listen address, systemd will assume the IPv6
address [::] as the default, and will create an AF_INET6 socket bound to
[::]:.

Due to Linux's default "bind both families" magic, it will actually be
bound to both [::]: *and* 0.0.0.0:, so it will accept IPv4
connections – but you'll receive them in the form of AF_INET6 sockets, so
the peer address of your v4 client indeed has family AF_INET6 but contains
a "v6-mapped" IPv4 address such as [:::10.0.229.174] aka
[:::a00:e5ae].

The alternative would be to specify both ListenStream=[::]: and
ListenStream=0.0.0.0: (as well as BindIPv6Only=ipv6-only), which would
cause you to receive *two* socket FDs – one purely for IPv6 clients, the
other for IPv4 – that you'd have to put into poll() or some other loop for
accepting clients.

You can extract the IPv4 address by detecting the [:::0:0/96] prefix
and stripping away the first 12 bytes. (There's also a magic option for
getsockopt() listed in ipv6(7) that can convert such a "v6-mapped" socket
to a "real" AF_INET socket, but it's rarely needed.)


>
> If I connect more than once, the gibberish changes from connection to
> connection.
>

I have a feeling it "changes" because you're trying to give the whole
struct sockaddr to inet_pton() instead of giving just the .sin6_addr field,
so your program is trying to interpret the *port number* (i.e. the
.sin6_port which precedes .sin_addr) as part of the address...

But please show your entire code, otherwise this is all just guessing.

Here's a working example that I've just tested with
`systemd-socket-activate --listen=`:
https://gist.github.com/grawity/63369273742f23b596d764cb6d45feb7


>
> If mydaemon creates the listening socket, I can easily get the peer
> address.
>
> I suspect that when systemd creates the listening socket then
> accept(3,...) returns a socket which is connected to a local socket created
> by systemd.
>
> QUESTION: Is that suspicion correct?
>

No, it isn't.

>

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: Re: [EXT] Finding network interface name in different distro

2022-10-19 Thread Mantas Mikulėnas
On Wed, Oct 19, 2022 at 11:46 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Also I think using "p" twice (pp) was a bad choice.
>

Sure, but that's not systemd format – em1 & p4p1 is the "biosdevname"
format that was before systemd, only eno1 & ens4f0np1 is actual systemd
naming.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

2022-10-07 Thread Mantas Mikulėnas
On Fri, Oct 7, 2022 at 10:24 AM Klaus Ebbe Grue  wrote:

> Hi systemd-devel,
>
> I have a user question which I take the liberty to send here since "about
> systemd-devel" says "... it's also OK to direct user questions to this
> mailing list ...".
>
> I have a daemon, /usr/bin/mydaemon, which listens on one and only one TCP
> port, say , and which does no more than communicating over  and
> creating, reading, writing and deleting files in /home/me/mydaemon/.
>
> Mydaemon leaves it to systemd to create a socket which listens at .
>
> It is unimportant whether or not mydaemon is started at boot and it is
> also unimportant whether or not mydaemon is socket activated. As long as it
> is at least one of the two.
>
> Now I want to upgrade mydaemon to a new version using a script, without
> race conditions and without closing the listening socket. I want the
> listening socket to stay open since otherwise there can be a one minute
> interval during which it is impossible to reopen .
>
> If it is just a clean upgrade, the script could replace /usr/bin/mydaemon,
> then stop mydaemon. If the daemon is socket activated there is no more to
> do. If the daemon is activated only on boot then the script must end up
> restarting mydaemon.
>
> But now I want to do some more while mydaemon is not running. It could be
> that my script should take a backup of /home/me/mydaemon/ in case things go
> wrong. It could be the script should translate some file in
> /home/me/mydaemon/ to some new format required by the new mydaemon or
> whatever.
>
> So I need to stop mydaemon in such a way that mydaemon cannot wake up
> while my script fiddles with /home/me/mydaemon/.
>

Deploy the new version of your daemon to another location
(/home/me/mydaemon.new/), perform all processing/conversions that are
necessary, *then* stop the socket, `mv mydaemon mydaemon.old`, stop the
service, `mv mydaemon.new mydaemon`, start the socket again. The interval
for this will be more like half a second than a minute.

-- 
Mantas Mikulėnas


Re: [systemd-devel] bond for wlan/lan failover: hook for dhcp changes?

2022-09-29 Thread Mantas Mikulėnas
You could use the networkd-broker tool (or its predecessor
networkd-dispatcher) to react to networkd's configuration events, or a
netlink-based tool (similar to `ip mon addr`) to directly watch IP address
changes.

To be honest though, a bond0 that's connected to two completely different
networks kind of makes no sense to me at all. How is it better than just
having two network interfaces?

On Thu, Sep 29, 2022 at 12:22 PM m1027  wrote:

> Hi,
>
> With a working wlan/lan bond0 failover, how can we trigger other
> local services whenever a failover happens?
>
> Why: In our case, a local openvpn client service needs SIGUSR1
> whenever the own IP address changes, after a failover. See man
> openvpn(8), --ipchange.
>
> The problem: After a failover, the openvpn client keeps sitting on
> the wrong IP address/interface. Sending SIGUSR1 manually helps
> indeed: openvpn then reconfigures itself and uses the correct IP
> address. The man page recommends to write a hook script for the
> local dhcpcd to send SIGUSR1 to the openvpn client, however we are
> not using dhcpcd but systemd.
>
> Some more information:
>
> - Failover works in general here; pulling out the cable from lan1
>   activates wlan0 and vice versa, and this triggers external DHCP
>   servers to issue a new IP address. The external servers are
>   triggered because of FailOverMACPolicy=active for bond0.
>
> - Our bond0 is on top of wlan0 + lan1 and configured like this:
>
>   [NetDev]
>   Name=bond0
>   Kind=bond
>   [Bond]
>   Mode=active-backup
>   AdSelect=bandwidth
>   FailOverMACPolicy=active
>
> - We know of networkmanager's dispatcher scripts but are looking for
>   a solution within systemd. (It's also unclear whether our network
>   setup could be configured entirely by networkmanager.)
>
> - There is a workaround: There is the "inactive " option for
>   the openvpn client to shutdown in case of no action. And we can
>   additionally set the client to Restart=always. However, this
>   interrupts even working openvpn client sessions every 60 sec of
>   inactivity.
>
> Thanks for any pointers...
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] "Failed to connect to bus: No such file or directory" when running systemd --user commands with runuser as root

2022-09-19 Thread Mantas Mikulėnas
Non-interactive bash invocations generally don't read ~/.bashrc and don't
pay attention to environment variables that you set there.


On Mon, Sep 19, 2022 at 9:36 PM Dave Houser  wrote:

> I am having issues on my Ubuntu 20.04 system running systemd v245.
> When trying to run `runuser -l mruser -c "systemctl --user status
> myservice.service"` I keep getting "Failed to connect to bus: No such file
> or directory"
>
> This does not make sense to me because I have the same set up on a RHEL
> 8.4 system running systemd v239, and I dont see this issue. I can run
> systemd --user commands as root with runuser with no issues.
>
> Here is the troubleshooting I performed.
>
>
>- tried running systemctl --user status myservice.service as mruser, 
> command
>runs with no errors.
>- I already checked loginctl for mruser, Linger=yes
>- Checked to make sure there was a systemd --user process running with
>ps
>- Logged into the user's account directly with separate ssh session,
>Then tried the same command as root in the original session, still same
>error.
>- mruser already has export XDG_RUNTIME_DIR=/run/user/$(id -u) in
>~/.bashrc
>- Tried rebooting the system, still nothing.
>- Deployed a new instance of Ubuntu 20.04, same problem on it.
>- Already read this post
>
> <https://askubuntu.com/questions/1374347/error-running-systemd-as-user-failed-to-connect-to-bus-dbus-session-bus-addr>,
>was not very helpful.
>
> I made a post about this you can find it here -->
> https://askubuntu.com/questions/1430191/ubuntu-20-04-not-allowing-runuser-to-manage-systemd-user-services-failed-to?noredirect=1#comment2491580_1430191
>
> This seems like odd behavior so I am not sure why this is happening. Can
> anyone help?
>
> - Dave
>
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd service causing bash to miss signals?

2022-09-19 Thread Mantas Mikulėnas
Pipelines somewhat rely on the kernel delivering SIGPIPE to the writer as
soon as the read end is closed. So if you have `foo | head -1`, then as
soon as head reads enough and exits, foo gets killed via SIGPIPE. But as
most systemd-managed services aren't shell interpreters, systemd marks
SIGPIPE as "ignored" when starting the service process, so that if the
service is somehow tricked into opening a pipe that a user has mkfifo'd, at
least the kernel can't be tricked into killing the service. You can opt out
of this using IgnoreSIGPIPE=.

(Though even if there's no signal, I believe  the writer should also get an
-EPIPE out of every write attempt, but not all tools pay attention to it –
some just completely ignore the write() result, like apparently `fold` does
in your case...)

On Mon, Sep 19, 2022, 20:18 Brian Reichert  wrote:

> I apologize for the vague subject.
>
> The background: I've inherited some legacy software to manage.
>
> This is on SLES12 SP5, running:
>
> systemd-228-157.40.1.x86_64
>
> One element is a systemd-managed service, written in Perl, that in
> turn, is using bash to generate random numbers (don't ask me why
> this tactic was adopted).
>
> Here's an isolation of that logic:
>
>   pheonix:~ # cat /root/random_str.pl
>   #!/usr/bin/perl
>   print "$0 start ".time."\n";
>   my $randStr = `cat /dev/urandom|tr -dc "a-zA-Z0-9"|fold -w 64|head -1`;
>   print "$0 end ".time."\n";
>
> You can run this from the command-line, to see how quickly it
> nominally operates.
>
> What I can reproduce in my environment, very reliably, is that when
> this is invoked as a service:
>
> - the 'head' command exits very quickly (to be expected)
> - the shell does not exit (maybe missed a SIGCHILD?)
> - 'fold' chews a CPU core
> - A kernel trace shows that 'fold' is spinning on SIGPIPEs, as it's
>   STDOUT is no longer connected to another process.
>
> My service unit:
>
>   pheonix:~ # cat /etc/systemd/system/random_str.service
>   [Unit]
>   Description=gernate random number
>   After=network.target local-fs.target
>
>   [Service]
>   Type=oneshot
>   RemainAfterExit=yes
>   ExecStart=/root/random_str.pl
>   ExecStop=/usr/bin/true
>   #TimeoutSec=infinity
>   TimeoutSec=900
>
>   [Install]
>   WantedBy=multi-user.target
>
> Easy to repro; this hangs forever, instead of exiting quickly.
>
>   pheonix:~ # systemctl daemon-reload
>   pheonix:~ # systemctl start random_str
>
> Let me know if there are any other details of my environment that
> would be helpful here.
>
> --
> Brian Reichert  
> BSD admin/developer at large
>


Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?

2022-09-17 Thread Mantas Mikulėnas
On Sat, Sep 17, 2022 at 8:35 PM Yuri Kanivetsky 
wrote:

> Hi,
>
> I've noticed that an Arch Linux package (gnupg) seemingly
> automatically enables a socket:
>
> ln -s "../dirmngr.socket"
> "/usr/lib/systemd/user/sockets.target.wants/dirmngr.socket"
>
>
> https://github.com/archlinux/svntogit-packages/commit/e7a6851881e2cfea37b76cfb16ba97af2fcc
>
> Before the change they were symlinked to
> /etc/systemd/user/sockets.target.wants.
>
> Later I was told that there's such a thing as preset units (an
> undocumented feature?):
>
> https://bbs.archlinux.org/viewtopic.php?pid=2057758#p2057758
>
> The way I understood it, if I put dirmngr.socket at
> /usr/lib/systemd/user/sockets.target.wants, it's like adding "enable
> dirmngr.service" to the preset policy. In other words, it won't be
> enabled by default, and won't be activated on boot unless I do
> `systemctl --user preset dirmngr`.
>

No, everything linked to a .wants/ directory immediately becomes a
Wants= dep of  and is therefore "enabled", it doesn't matter whether
that .wants/ is in /etc or /usr/lib or /run.

In fact, units linked into /usr/.../*.wants/ are enabled *permanently, *as
the sysadmin can no longer `systemctl` disable them at all – they can only
be masked. So the Arch change is moving into the opposite direction than
what you thought.


> Can you clarify this? Are there preset units? Is my understanding of
> how they work correct?
>

It's not entirely correct. Systemd indeed has presets, but they work
differently – there are separate config files in
/usr/lib/systemd/{user,system}-preset/ that would be read by a `systemctl
preset `. See systemd.preset(5) for details. (For example,
https://aur.archlinux.org/cgit/aur.git/tree/?h=softu2f uses presets to
enable sockets by default.)

So the reason systemctl says "preset: enabled" is *not *because of any
existing .wants/ symlinks (those still correspond to the main "enabled"
status) – instead it's because the unit doesn't match any .preset files
that would disable it (i.e. it only matches the compiled-in default "enable
*" preset), and therefore systemctl *would create *a .wants/ symlink from
the preset.

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd-network and loopback

2022-09-09 Thread Mantas Mikulėnas
On Fri, Sep 9, 2022 at 11:36 PM Andrea Pappacoda 
wrote:

> Il giorno ven 9 set 2022 alle 12:17:42 -05:00:00, Greg Oliver
>  ha scritto:
> > Well, easiest to explain is user apps that use tcp or udp sockets to
> > communicate.  If they are on the same host, then huge gains can be
> > achieved by using the loopback adapter (especially TCP comms).
>
> Thanks, but again, is this related to systemd-network in any way? My
> question is whether letting systemd-network manage the loopback
> interface is useful or not, not what the loopback interface is used for
> in general.
>
> As far as I understand, systemd itself brings up the loopback interface
> on its own during the early boot stage, and systemd-network(d) is
> launched much later. But is writing something like this in
> /etc/systemd/network/foo.conf ever useful?
>
> $ cat /etc/systemd/network/foo.conf
> [Match]
> Name=*
> Type=loopback
>

It's useful when you want the `lo` interface to have a custom [Address] or
two.

Routers often have an address assigned that's supposed to be independent
from any "physical" interface – on Linux it could be assigned to a
Type=dummy interface or to an empty bridge, but just as frequently it's
assigned to `lo`. (It's even called a "loopback address".)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Help required for configuring a blocking service during shutdown

2022-08-29 Thread Mantas Mikulėnas
On Mon, Aug 29, 2022 at 1:31 PM Henning Moll  wrote:

> Hi,
>
> back in the rcX days I configured a backup system which blocks a system
> shutdown in a certain state (network and mounts still active) if a backup
> is still running. The init script looks like this:
>
> ...
> case "$1" in
> ...
>
> stop)
>
> plymouth --ping
> if [ $? -ne 0 ]; then
>   log_daemon_msg "waiting for running backup" "backup"
> else
>   plymouth message --text="waiting for running backup"
> fi
> sleep 10
> logger -t backup "rcS: trying to get lock..."
> exec {FD}<>"$LOCKFILE"
> {
>   logger -t backup "locked rsync_wrapper: waiting for lock"
>   flock ${FD}
> }
> logger -t backup "rcS: continue shutdown..."
> plymouth message --text=""
>
> ...
> esac
> ...
>
> The strategy is to wait for a successful lock on a shared LOCKFILE.
>
> Now, I want to solve this with systemd. I've read tons of documentation
> but I don't get it, all my experiments failed. I am using Linux Mint 21
> "Vanessa", which is based on Ubunut 22.04.
>
> I am looking for a solution which
>
> * "pauses" a shutdown or reboot attempt as long as the LOCK cannot be
> obtained (which means the backup is still running)
> * while the network connection (ethernet) is still active
> * and all mounts (local, usb and cifs) are still active
> * openssh-server still running
> * The logging functionality (plymouth / log_daemon) would be nice. so the
> system should be allowed to shutdown to a stage where plymouth is already
> visible
>
> Can you please help me?
>
> Best regards
> Henning
>

Probably similar to what you already have – create a service that starts on
boot (doing nothing) and delays the *stop* action. (You'll probably need to
start with [Service] Type=oneshot, RemainAfterExit=yes, TimeoutStopSec=1d.)
If you list After=ssh.service as a dependency, then your service will be
started after OpenSSH and *stopped before OpenSSH*, same with
NetworkManager. (I'm not sure if there's a dependency that can be used to
target manually done SMB mounts, although remote-fs.target might work for
the ones in fstab?)

Not sure how it works with Plymouth, but in its default console output,
systemd itself will already show which services are waiting to be stopped.
Syslog (journald) should be available the entire time.

The backup system should also run under `systemd-inhibit --what=shutdown`
as an additional layer of precaution – that way the user will know that
something is still running *before* they initiate the actual shutdown.

-- 
Mantas Mikulėnas


Re: [systemd-devel] logind: discontinuous TTYs?

2022-08-26 Thread Mantas Mikulėnas
Do they have to be autospawned by logind?

You can always statically start getty@.service on any tty you want (like it
used to be with inittab).

On Fri, Aug 26, 2022 at 7:11 PM Toomas Rosin  wrote:

> Hi,
>
> I would like to configure logind so that it spawns getties only on tty1
> and tty12.  I know I can set NAutoVTs to 12, but how to disable getties
> on tty2..tty11?
>
> Regards,
> T.
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] logging for socket-based services

2022-08-22 Thread Mantas Mikulėnas
As far as I know, only "[Service] LogLevelMax=notice" can hide those
messages, but it also has the side effect of discarding *all* lower-level
log messages generated by the service (even through syslog or journal
APIs), so IMO it's kind of a last-resort option.

But if your services receive so many connections that these messages are
overwhelming the system logs, they should probably be rewritten to accept
connections internally (i.e. use systemd Accept=no or xinetd wait=yes, so
that the service will receive the "listener" sockets from systemd, put them
in a regular event loop) instead of starting a new instance for each
connection.

On Mon, Aug 22, 2022 at 9:15 PM Allison Sherburne <
allison.k.sherbu...@gmail.com> wrote:

> Hello,
>
> I have recently ported a number of xinetd services to systemd socket-based
> services. The services are working as expected but my logs are now flooded
> with "systemd: Started ..." messages. Is there any way to tune the logging
> for these services to filter out these entries?
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?

2022-08-18 Thread Mantas Mikulėnas
On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 17.08.2022 um 15:17 in
> Nachricht
> :
> > On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms 
> wrote:
> >
> >> Hi,
> >>
> >> I'm developing an application for an embedded system that needs to
> >> wait for proper NTP synchronization. systemd-timesyncd is running and
> >> I can read NTPSynchronized from /org/freedesktop/timedate1 using
> >> D-Bus. I read in the manual that this property is not signaled, and
> >> that I need to do some weird magic with timerfd's
> >> TFD_TIMER_CANCEL_ON_SET flag.
> >>
> >> It works, but having the ECANCELLED on the read() means that something
> >> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially
> >> that I got a proper NTP synchronization. Then, I still need to query
> >> NTPSynchronized after, and retry the timerfd thing if it didn't switch
> >> to "true", which is still some kind of polling (but very unlikely,
> >> sure).
> >>
> >> As a result, I'm a bit curious, what was the rationale of not simply
> >> signaling NTPSynchronized?
> >>
> >
> > timedated itself doesn't have knowledge of that event, because it isn't
> the
> > daemon that performs actual synchronization (that's timesyncd), so all
> that
> > the D-Bus property does is report you the status of adjtimex() –
> > specifically it returns whether ".maxerror < 1600". Timedated would
> > still need to poll and/or do timerfd tricks in order to see that state
> > being reached. (Currently timedated is not a continuously running daemon
> –
> > it starts up only whenever properties are queried and exits when idle.)
> >
> > A better question is why the timesyncd daemon does not have such a D-Bus
> > signal; looks like it *almost* does
> > (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only
> > emits the raw messages and not whether they resulted in a successful
> sync.
>
> Maybe because a "successful sync" is actually not sharply defined.
> There can be very interesing scenarios (like requiring three "surviving
> clocks", but only two were found)
>

It's an SNTP client, it only deals with one timeserver at a time. And it
already has a specific definition of "synced" in the code because it sets a
flag file on the filesystem when that happens, just doesn't do the same via
D-Bus.

-- 
Mantas Mikulėnas


Re: [systemd-devel] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?

2022-08-17 Thread Mantas Mikulėnas
On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms  wrote:

> Hi,
>
> I'm developing an application for an embedded system that needs to
> wait for proper NTP synchronization. systemd-timesyncd is running and
> I can read NTPSynchronized from /org/freedesktop/timedate1 using
> D-Bus. I read in the manual that this property is not signaled, and
> that I need to do some weird magic with timerfd's
> TFD_TIMER_CANCEL_ON_SET flag.
>
> It works, but having the ECANCELLED on the read() means that something
> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially
> that I got a proper NTP synchronization. Then, I still need to query
> NTPSynchronized after, and retry the timerfd thing if it didn't switch
> to "true", which is still some kind of polling (but very unlikely,
> sure).
>
> As a result, I'm a bit curious, what was the rationale of not simply
> signaling NTPSynchronized?
>

timedated itself doesn't have knowledge of that event, because it isn't the
daemon that performs actual synchronization (that's timesyncd), so all that
the D-Bus property does is report you the status of adjtimex() –
specifically it returns whether ".maxerror < 1600". Timedated would
still need to poll and/or do timerfd tricks in order to see that state
being reached. (Currently timedated is not a continuously running daemon –
it starts up only whenever properties are queried and exits when idle.)

A better question is why the timesyncd daemon does not have such a D-Bus
signal; looks like it *almost* does
(org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only
emits the raw messages and not whether they resulted in a successful sync.

For now, if you're using timesyncd you can use inotify to watch
/run/systemd/timesync/synchronized, which is touched after a sync.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Detecting when running under systemd

2022-08-17 Thread Mantas Mikulėnas
On Wed, Aug 17, 2022 at 5:05 AM Peter Hoeg  wrote:

>
> Hi all,
>
> I have a small program that queries an external web API, massages the data
> and passes it off to something else. As I only need it to run during
> certain windows and I didn't want to have to bother with making sure it was
> alive, I am starting it using a systemd timer which is sufficiently
> flexible. All good and it's super nice to be able to "outsource" all that
> to systemd.
>
> My question is - what is the canonical way to detect that I'm running
> under systemd so that I can adjust accordingly? Currently I'm checking for
> the existence of the "_SYSTEMD_INVOCATION_ID" environment variable in order
> to change the logging function as the default logger includes a timestamp
> which is redundant when journald is picking it up.
>
> I'm also using LoadCredential for passing tokens but that just comes down
> to looking for the right file name where the CREDENTIALS_DIRECTORY variable
> points, so that really isn't systemd specific and there is a fallback in
> case that isn't set or the directory/file doesn't exist anyway.
>
> I could of course also add a --systemd flag that toggles this but if I can
> do "TheRightThing(tm)" out of the box, why not.
>

What *is* specific to systemd that you need to check for and how would that
change the program's behavior? It sounds to me that being started by pid1
is irrelevant here – if you want to alter your logging, then you want to
check specifically whether stderr is tied to the journal, for which you can
use JOURNAL_STREAM (like in
https://github.com/systemd/systemd/blob/main/src/basic/log.c#L217).

(In addition to disabling the timestamps you should *at least* add message
priority indicators as well, either by using SyslogLevelPrefix=, or by
avoiding stderr entirely and using the syslog() API for logging – if not
going all the way with sd_journal_send*().)

-- 
Mantas Mikulėnas


Re: [systemd-devel] How can we debug systemd-gpt-auto-generator failures?

2022-07-28 Thread Mantas Mikulėnas
On Thu, Jul 28, 2022 at 1:51 PM Kevin P. Fleming  wrote:

> I've got two systems that report a failure (exit code 1) every time
> systemd-gpt-auto-generator is run. There are a small number of reports
> of this affecting other users too:
>
> https://bugs.archlinux.org/task/73168
>
> This *may* be related to the use of ZFS, although I've got a
> half-dozen systems using ZFS and only two of them have this issue.
>
> Running the generator from the command line also produces exit code 1,
> but doesn't produce any output. is there any practical way to debug
> this failure?
>

Start with SYSTEMD_LOG_LEVEL=debug (and SYSTEMD_LOG_TARGET=console if you
want to run the tool from CLI, otherwise it logs to journal). If it only
fails as part of a daemon-reexec, `systemctl set-environment` (not sure if
`systemctl log-level` has any effect on non-pid1 processes). Since it uses
libblkid, there's also LIBBLKID_DEBUG=all.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Prefix delegation and IPv6 subnetting

2022-07-08 Thread Mantas Mikulėnas
On Fri, Jul 8, 2022, 09:22 Andrei Borzenkov  wrote:

> On 07.07.2022 18:25, Bent Bagger wrote:
> >
> > The prefix delegation problem starts with the interactions between net0
> > and net2. Net0 is delegated a /56 prefix from the main router (which
> > runs radvd and dhcpd6, not networkd, for historical reasons). I want
> > net2 to delegate a /60 subnet to net3, but it doesn't happen.
>
>
> networkd does not support prefix subdelegation. It supports querying
> upstream for delegated prefixes and allocating one /64 received prefix
> to downstream interface announcing it via RA. The same functionality as
> NetworkManager. Nor does networkd support DHCPv6 server functionality.
>
> For all practical purposes IPv6 on-link prefix can only be /64. So
> "delegated a /56 prefix" is misleading. You get delegated block of
> prefixes that are aggregated into /56 mask.
>

IME, "prefix" is a *very* common term for routed prefixes, not only on-link
ones – probably much more common than "/56 mask" (given that nothing uses
actual mask notation in IPv6). The upstream router doesn't care about
whether you're going to use it as on-link prefixes or not, anyway.


Re: [systemd-devel] Waiting for network routes to appear

2022-06-15 Thread Mantas Mikulėnas
I think it's better to use a custom tool. RequiresMountsFor relies on
knowing the exact mount points from the beginning and just waiting for them
to be done – but that might not exactly match networking, where you might
have two /24 routes today and a /23 tomorrow, so you can't exactly
predefine that in units.

A custom tool could more easily express logic like waiting for any route
matching the specified address, or any non-/0 route, or any route through
the specified interfaces.

(If you're in this situation, you probably also have several routing
tables, and perhaps a ton of routes. I would not want all that memory usage
in pid 1 – already went through this for systemd-networkd, and then once
more for nss_myhostname...)

On Wed, Jun 15, 2022, 14:32 Kevin P. Fleming  wrote:

> I've got a number of systems that use BIRD to learn the routes
> available on their networks, and as a result some services on those
> systems attempt to start up before the routes have been learned. If
> those services attempt to make network connections (even just DNS
> queries), they will fail, and that's unpleasant.
>
> I can't use existing systemd facilities to make these services wait,
> because there's no mechanism available for BIRD to indicate that any
> specific route has been learned, or a way to configure a service to
> wait for a specific route.
>
> I'm considering just writing a smallish Python program which will
> accept (via configuration) a list of routes, and will listen to
> netlink to wait for all of those routes to appear. I'd then make my
> services dependent on this service reporting success. However, since
> networkd already listens to netlink, it would certainly be possible
> for it to provide this facility in some way.
>
> If you'll pardon the analogy, I'm thinking of something like
> RequiresMountsFor=, which makes service startup wait until mount units
> have succeeded. Of course following this analogy we'd end up creating
> the concept of a 'route unit', and I'm not sure that's really the
> right thing to do here.
>
> Is it worth trying to design some way for networkd to provide this
> facility? if not, I'll just continue down the road of doing this
> outside of systemd proper.
>


Re: [systemd-devel] Q: Start network in chroot?

2022-06-13 Thread Mantas Mikulėnas
On Mon, Jun 13, 2022 at 11:09 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> Two questions:
> 1) Why can't I use "systemctl start network" in a chroot environment (e.g.
> mounting the system from a rescue medium to fix a defective kernel)?


Because you don't have systemd as init while inside a chroot.

2) How can I start the network using systemd?
>

Start it outside the chroot.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Why are journal files stored in machine-specific directories?

2022-05-26 Thread Mantas Mikulėnas
On Thu, May 26, 2022, 16:27 Jakub Piecuch  wrote:

> Hello,
>
> I'm wondering why journald stores journal files under
> /var/log/journal/$MACHINE_ID instead of just /var/log/journal.
>

It allows logs from remote systems to be collected using ordinary rsync or
NFS or other file-based tools. Similarly, for containers running on the
local system, their log directories can be directly symlinked under the
host's /var/log/journal.

In both cases `journalctl -m` would show logs from all machine IDs, while
the default is to only show logs from the local host.


Re: [systemd-devel] certificate and trust store feature for systemd

2022-05-26 Thread Mantas Mikulėnas
On Wed, May 25, 2022 at 4:28 PM SCOTT FIELDS 
wrote:

> I apologize for the very general inquiry.
>
>
>
> Are there any plans to have system natively support its own trust store
> for items like CAs, x509 certs, passwords & truststores akin to the
> keychain in Windows and OS X?
>
>
>
> I still find the management of PKIs in /etc/pki to be problematic.
>
>
>
> Having this available as a core service within systemd using like APIs
> either in (mostly deprecated) CAPI or the new CNG
>

This sounds more like the area of p11-kit, rather than systemd.

-- 
Mantas Mikulėnas


Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces

2022-05-09 Thread Mantas Mikulėnas
On Mon, May 9, 2022, 16:35 Peter Mattern  wrote:

> Hi, Petr.
>
>  > Do you need any systemd-resolved specific features?
> Primarily, it's about the way directive Domains allows for directing
> queries to particular DNS servers based on the queries' domains.
> I'm using it to restrict the ISP's DNS server to the ISP's domain, use a
> local DNS server for local subdomains and have a DNS server like Quad 9
> serve all the rest.
> This can be achieved with other applications, too, e. g. dnsmasq. But I
> find it more handy to configure with networkd/resolved, in particular,
> when these are already in use anyway.
>
>  > I don't think resolved considers it common to have more than one DNS
> server on the localhost.
> As I understand it, it's the very purpose of directive Domains to have
> systemd-resolved interact with various different DNS servers. So why
> shouldn't one of these run on the same host as resolved?
>
>  > unbound, knot-resolver
> These aren't an option. I do not need a cache only, but want to serve
> the said local-only subdomain, which also needs to comprise RRs other
> than [AAA]A like CNAME, MX or TXT.
>

I heard Unbound handles that quite well. See the `local-data` option.

(As does BIND9 of course.)

>


Re: [systemd-devel] [systemd] Behavior of "Requires" and "After" in service unit

2022-05-08 Thread Mantas Mikulėnas
On Mon, May 9, 2022 at 7:17 AM Hamza, Muhammad 
wrote:

> Hello,
>
>
>
> I am trying to use swupdate services to perform updates on my BSP but
> there is a problem that I am facing.
>
> When update usb is plugged in during the boot time, swupdate core and
> swupdate-usb service run right after
>
> each-other where swupdate-usb service is dependent on swupdate-core
> service. Therefore, the update fails as
>
> core has not initialized yet when swupdate-usb launches the client.
>
> I have tried adding service type as “exec” in swupdate core service and
> have tried both Requires and After in swupdate-usb
>
> service but in all case swupdate-usb does not wait for core to be
> initialized completely before launching.
>
> My understanding is that when service type is set to exec service manager
> will only assume that swupdate core service is
>
> launched once main process of core is executed and with “Requires” set in
> swupdate-usb service it should wait till
>
> swupdate core service has executed its main process and is assumed
> launched.
>

Even with Type=exec, systemd won't automatically know when your process has
"initialized completely". Type=exec only means that the kernel call to
start executing the process has been fired off – systemd has no automatic
visibility beyond that, since the initialization stage varies greatly from
one program to another.

(In fact, looking at your example, systemd thinks that *the shell script*
is the main process, it doesn't find out about the actual daemon until
later. Please get rid of the .sh script and change your ExecStart= to
directly launch the daemon binary.)

What you need is either Type=notify or Type=forking, and the process needs
to *explicitly notify* systemd that it has reached initialization – for
Type=notify it must send a READY=1 message over a socket (see sd_notify),
and for Type=forking it needs to "daemonize" at the correct point.

I checked the source code of swupdate on GitHub, and it seems it already
has support for sending READY – there's even a whole section about systemd
integration
<https://github.com/sbabic/swupdate/blob/master/doc/source/swupdate.rst#systemd-integration>
in its docs. So in short, you need to compile it with CONFIG_SYSTEMD, then
you'll be able to use Type=notify in the .service unit. Example taken from
the swupdate docs:

[Service]
*Type=notify*
*ExecStart=/usr/bin/swupdate* -u '-t default -u http://localhost -i 25'


(The "socket activation" part isn't required, but may help as well.)

Finally, Type=oneshot is for services where systemd waits for the main
process to start *and finish* (e.g. for services that perform a single
update and don't have a daemon at all). It sounds a bit like it would be
the right choice for swupdate-usb, but it's never correct to use oneshot
for daemons like swupdate-core.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Q: logger: "invalid structured data parameter: 'fo\o="b\"a\"r"'"

2022-05-02 Thread Mantas Mikulėnas
On Mon, May 2, 2022 at 12:47 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 02.05.2022 um 10:50 in
> Nachricht
> :
> > On Mon, May 2, 2022 at 11:40 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> Hi!
> >>
> >> If I understand it corrctly the logger from
> >> util-linux-systemd-2.33.2-4.18.1.x86_64 of SLES12 is part of systemd; if
> >> not,
> >>
> >
> > It's not. It's part of util-linux.
>
> Sorry, I was confused by the "-systemd" suffix.
>

I don't know how SLES works, but this sounds like they have two builds of
util-linux, one with libsystemd (for logger --journal) and another without.
Either way, it should have no relation to the --rfc5424 mode.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: logger: "invalid structured data parameter: 'fo\o="b\"a\"r"'"

2022-05-02 Thread Mantas Mikulėnas
On Mon, May 2, 2022 at 11:40 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> If I understand it corrctly the logger from
> util-linux-systemd-2.33.2-4.18.1.x86_64 of SLES12 is part of systemd; if
> not,
>

It's not. It's part of util-linux.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Starting transient services securely from other service without root

2022-04-28 Thread Mantas Mikulėnas
On Thu, Apr 28, 2022 at 6:56 PM Vašek Šraier  wrote:

> To update the current list of options:
>
> - PolicyKit
>   could technically help, but I've discovered that the documentation
>   explicitly prohibits our potential use-case:
>   "In particular, applications, [...] must never include any
>authorization rules."
>

That didn't stop many of them (including, apparently, systemd itself) from
doing so anyway.

$ pkgfile -vg '/usr/share/polkit-1/rules.d/*'
core/systemd 250.4-2
 /usr/share/polkit-1/rules.d/systemd-networkd.rules
extra/brltty 6.4-10
/usr/share/polkit-1/rules.d/org.a11y.brlapi.rules
extra/flatpak 1:1.12.7-1
 /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules
extra/geoclue 2.6.0-2
/usr/share/polkit-1/rules.d/org.freedesktop.GeoClue2.rules
extra/gnome-control-center 42.1-1
/usr/share/polkit-1/rules.d/gnome-control-center.rules
extra/gvfs 1.50.1-1
/usr/share/polkit-1/rules.d/org.gtk.vfs.file-operations.rules
extra/lightdm 1:1.30.0-4
 /usr/share/polkit-1/rules.d/lightdm.rules
extra/malcontent 0.10.3-2
/usr/share/polkit-1/rules.d/com.endlessm.ParentalControls.rules
extra/polkit 0.120-5
 /usr/share/polkit-1/rules.d/50-default.rules
community/bolt 0.9.2-1
 /usr/share/polkit-1/rules.d/org.freedesktop.bolt.rules
community/fwupd 1.7.7-1
/usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules
community/gnome-initial-setup 41.4-1
 /usr/share/polkit-1/rules.d/20-gnome-initial-setup.rules
community/libvirt 1:8.2.0-4
/usr/share/polkit-1/rules.d/50-libvirt.rules
community/libvirt-dbus 1.4.1-2
 /usr/share/polkit-1/rules.d/libvirt-dbus.rules
community/packagekit 1.2.5-1
 /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules

I found a bugzilla about this:
https://bugs.freedesktop.org/show_bug.cgi?id=80921

-- 
Mantas Mikulėnas


Re: [systemd-devel] [systemd‑devel] Antw: [EXT] Re: Q: non‑ASCII in syslog

2022-04-28 Thread Mantas Mikulėnas
On Thu, Apr 28, 2022 at 1:26 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Lennart Poettering  schrieb am 28.04.2022 um
> 10:27
> in
> Nachricht :
> > On Do, 28.04.22 09:32, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> Actually I wasn't quite sure about the default config in SLES12.
> >> It seems the flow is journald ‑> local rsyslogd ‑> remote syslogd
> >>
> >> > rsyslogd already knows if messages are UTF‑8 because the system's
> $LANG
> >> > (well, nl_langinfo) says so. And if rsyslog can't trust that for some
> >> > reason (e.g. because a user might have a different locale), then
> >> > systemd‑journald won't be able to trust it either, so it won't know
> whether
> >> > it could add the BOM.
> >>
> >> How could a remote syslog server know what the locale on the sending
> system
> >> is?
> >
> > Your local rsyslogd could add the BOM when it transforms journal
> > messages to syslog datagrams.
> >
> >> > RFC 3164 over the network to a remote server? Outside the scope for
> >> > systemd, since it doesn't generate the network packets; your local
> rsyslogd
> >> > forwarder does. (Also, why RFC 3164 and not 5425?)
> >>
> >> If you look outside the world of systemd, about 99% of systems create
> the
> > RFC
> >> 3164 type of messages.
> >
> > That's a wild claim, and simply wrong actually.
>
> Well actually as systemd cannot send syslog messages to remote, which
> systems
> do you know that send RFC 5424 messages?
> Actually I know none here.
>

syslog-ng does with destination{syslog()}, rsyslogd does with
RSYSLOG_SyslogProtocol23Format; the HP switches at $WORK (and I think the
Cisco ones) didn't even have BSD-format as an option, always producing
5424-format.


> >
> > systemd is focussed on reality: we generate and process the same
> > format glibc generates.
>
> I'm wondering which API all those programs use that create correct syslog
> entries.
>

It's not that they create correct syslog entries, it's that the syslogd
(well, the /dev/log listener, so including journald) *parses and rebuilds*
the entries that come from the API before storing them anywhere.

Whether you use rsyslog or syslog-ng, they don't just dump program-provided
data to /var/log – they both parse the input into date + hostname + pid +
message, then reformat according to whatever output format is specified.
(For example, we have syslog-ng configured to write RFC3339 timestamps.)
Journald also does the same by design.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Q: non-ASCII in syslog

2022-04-28 Thread Mantas Mikulėnas
On Thu, Apr 28, 2022 at 10:32 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 27.04.2022 um 12:03 in
> Nachricht
> :
> > On Wed, Apr 27, 2022 at 10:09 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> Hi!
> >>
> >> Having written an RFC 3164 compatible syslog daemon, I noticed that
> systemd
> >> created syslog messages with non-ASCII characters.
> >> The problem is that a remote syslogd can hardly guess the correct
> character
> >> set (I'm using rsyslog to forward local messages to a remote server).
> >>
> >> Example of such message:
> >> systemd-tmpfiles[3311]: [/usr/lib/tmpfiles.d/svnserve.conf:1] Line
> >> references
> >> path below legacy directory /var/run/, updating /var/run/svnserve →
> >> /run/svnserve; please update the tmpfiles.d/ drop-in file accordingly.
> >>
> >> (The arrow is encoded as three bytes (\xe2\x86\x92))
> >>
> >> RFC 5425 syslog messages require the use of a BOM (%xEF.BB.BF) at the
> >> beginning of a message if the message used UTF-8:
> >>
> >>   MSG = MSG-ANY / MSG-UTF8
> >>   MSG-ANY = *OCTET ; not starting with BOM
> >>   MSG-UTF8= BOM UTF-8-STRING
> >>   BOM = %xEF.BB.BF
> >>
> >> Wouldn't it make sense to add such a BOM for RFC 3164 syslog messages
> also
> >> if
> >> non-ASCII (i.e.: UTF-8) encoded characters are used?
> >>
> >
> > RFC 3164 over a local socket from journald to local rsyslogd? The local
>
> Actually I wasn't quite sure about the default config in SLES12.
> It seems the flow is journald -> local rsyslogd -> remote syslogd
>
> > rsyslogd already knows if messages are UTF-8 because the system's $LANG
> > (well, nl_langinfo) says so. And if rsyslog can't trust that for some
> > reason (e.g. because a user might have a different locale), then
> > systemd-journald won't be able to trust it either, so it won't know
> whether
> > it could add the BOM.
>
> How could a remote syslog server know what the locale on the sending system
> is?
>

It's not remote, it's local. I'm talking about the one that's receiving
messages from journald on the same machine.


>
> >
> > RFC 3164 over the network to a remote server? Outside the scope for
> > systemd, since it doesn't generate the network packets; your local
> rsyslogd
> > forwarder does. (Also, why RFC 3164 and not 5425?)
>
> If you look outside the world of systemd, about 99% of systems create the
> RFC
> 3164 type of messages.
> Some may send non-ASCII too, however.
>

Still outside the scope of systemd. Systemd doesn't send RFC 3164 messages
over the network, either.


>
> >
> > Generally, if a message successfully decodes as UTF-8 then it's most
> likely
> > actual UTF-8 (and if UTF-8 decode fails then you fall back to ISO8859-1).
> > Various old systems get away with this without needing a UTF-8 BOM.
>
> Yes, you can just output what you received, hoping the messages will be
> presented correctly.
> I't just like sending 8-bit E-Mmail without a coding system or charset in
> the
> past.
>

Which is not what I was saying, but sure, whatever.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: non-ASCII in syslog

2022-04-27 Thread Mantas Mikulėnas
On Wed, Apr 27, 2022 at 10:09 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> Having written an RFC 3164 compatible syslog daemon, I noticed that systemd
> created syslog messages with non-ASCII characters.
> The problem is that a remote syslogd can hardly guess the correct character
> set (I'm using rsyslog to forward local messages to a remote server).
>
> Example of such message:
> systemd-tmpfiles[3311]: [/usr/lib/tmpfiles.d/svnserve.conf:1] Line
> references
> path below legacy directory /var/run/, updating /var/run/svnserve →
> /run/svnserve; please update the tmpfiles.d/ drop-in file accordingly.
>
> (The arrow is encoded as three bytes (\xe2\x86\x92))
>
> RFC 5425 syslog messages require the use of a BOM (%xEF.BB.BF) at the
> beginning of a message if the message used UTF-8:
>
>   MSG = MSG-ANY / MSG-UTF8
>   MSG-ANY = *OCTET ; not starting with BOM
>   MSG-UTF8= BOM UTF-8-STRING
>   BOM = %xEF.BB.BF
>
> Wouldn't it make sense to add such a BOM for RFC 3164 syslog messages also
> if
> non-ASCII (i.e.: UTF-8) encoded characters are used?
>

RFC 3164 over a local socket from journald to local rsyslogd? The local
rsyslogd already knows if messages are UTF-8 because the system's $LANG
(well, nl_langinfo) says so. And if rsyslog can't trust that for some
reason (e.g. because a user might have a different locale), then
systemd-journald won't be able to trust it either, so it won't know whether
it could add the BOM.

RFC 3164 over the network to a remote server? Outside the scope for
systemd, since it doesn't generate the network packets; your local rsyslogd
forwarder does. (Also, why RFC 3164 and not 5425?)

Generally, if a message successfully decodes as UTF-8 then it's most likely
actual UTF-8 (and if UTF-8 decode fails then you fall back to ISO8859-1).
Various old systems get away with this without needing a UTF-8 BOM.

-- 
Mantas Mikulėnas


Re: [systemd-devel] LogsDirectory= permissions

2022-04-20 Thread Mantas Mikulėnas
On Wed, Apr 20, 2022, 23:43 Lennart Poettering 
wrote:

> On Mi, 20.04.22 22:18, Andrea Pappacoda (and...@pappacoda.it) wrote:
>
> > Hi! I've been playing around with various options documented in
> > systemd.exec(5) recently, and I'm having an issue with `LogsDirectory=`
> and
> > its permissions.
> >
> > In particular, I've tried setting `LogsDirectory=nginx` for
> nginx.service,
> > but it is now unable to write to the logs. This is because the nginx
> service
> > is started as root, and then drops its privileges to www-data (as I'm on
> > Debian). systemd can't know this, and chowns the /var/log/nginx
> directory to
> > root:root, making it impossible for nginx threads spawned as www-data to
> > write to them. It was previously set to www-data:adm
> >
> > Is it possible to specify the owner and group of the `LogsDirectory` (or
> of
> > any other directory specified by similar options)?
>
> Yes, use User=www-data + Group=www-data.
>
> And then use the "!" modifier in ExecStart= to tell systemd that even
> though the specified User=/Group= are the ones used by the service it
> should leave set setuid() call to be done by the daemon itself. If
> specified that way, systemd will invoke the main daemon binary as
> root:root.
>
> e.g.
>
> …
> [Service]
> ExecStart=!/usr/sbin/nginxd
> User=www-data
> Group=www-data
> LogsDirectory=nginx
> …
>
> That said, are you sure you need to run the nginx binary as root? My
> suspicion is that it would be much nixer if nginx would be fixed to
> just be able to be invoked unprivileged (or at worst, with some very
> limited ambient caps, such as CAP_NET_BIND_SERVICE).
>

Hmm, on the other hand: if nginx starts unprivileged and its log files (and
TLS certificate files, and config files) are owned by www-data... and your
webapps (e.g. php-fpm) are also running as www-data (as is very common),
then an exploitable webapp could do a bit more damage than if the
certs were only accessible to root, e.g. they could scribble all over
your past logs now.

I usually don't mind services like httpd or postfix dropping privileges on
their own because they can be more flexible about it, e.g. use different
UIDs for different purposes.


Re: [systemd-devel] device unit files

2022-04-11 Thread Mantas Mikulėnas
On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov 
wrote:

> How to track down the lifespan of the device unit file, i.e. the
> activating state? I have an embedded system where systemd-analyze plot
> shows that the unit file I am interested in, let’s say
> dev-mmcpartition.device, takes about 2 seconds to be become active. This
> partition (mmcpartition) holds my rootfs. I would like to know what is
> going on during those 2 seconds, what device unit file is doing, how to
> track what it is doing? Thanks in advance.
>

Really the only thing a .device unit "does" is wait for udev to report that
the corresponding actual device is ready. As soon as udev sends out the
uevent with ACTION=add and systemd receives it, the .device unit becomes
active, that's all.

So if that's slow, it might be the kernel not sending the initial 'add'
event *to* udev (AFAIK, systemd-udev-trigger.service is responsible for
triggering fake 'add' events for devices that already exist at boot time,
so check where that service shows up on the graph), or it might be udev
taking a long time to process its .rules for that device, or systemd not
catching up fast enough... Such delays for the mmcblk rootfs seem to be a
frequent question both here on the list as well as on IRC, but I don't
think I remember any specific answers.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Intercepting/Delaying the boot process

2022-04-08 Thread Mantas Mikulėnas
On Fri, Apr 8, 2022, 12:44 Andreas Hartmann  wrote:

> On Fri, 2022-04-08 at 12:07 +0300, Mantas Mikulėnas wrote:
> > On Fri, Apr 8, 2022 at 10:08 AM Andreas Hartmann  wrote:
> >
> > >
> > > To this end I was wondering whether it would be feasible to "hook" into
> > > the boot
> > > process, somewhere before the disks are decrypted, to only have it
> charge
> > > (or
> > > continue to boot when I press some magic button maybe). Looking at the
> > > order of
> > > service startup I was thinking about maybe intercepting the boot
> between
> > > "local-
> > > fs-pre.target" and "machines.target" because nothing happens there on
> my
> > > setup.
> > >
> >
> > That "between" doesn't make sense, because the boot process waits for
> > machines.target *in parallel* with waiting for all other services that
> are
> > started via multi-user. The systemd boot process is non-linear and
> doesn't
> > have a fixed order, it's a dependency graph.
> >
> > According to bootup(7), there are two main synchronization points,
> > sysinit.target and basic.target, which all non-"early" services will wait
> > for. So if you have a service with Before=basic.target, it'll delay
> startup
> > of all normal services. (It would then need to explicitly specify After=
> > for things it needs, like specific devices or sockets.)
>
> Good hint, thank you!
>
> >
> > If the device was using an initramfs (which has a fully separate boot
> > process, its own udevd, etc.) then you could make the initramfs decide
> > between starting a normal boot vs minimal boot depending on charger
> status.
> > If it doesn't have an initramfs, then systemd *generators* could also be
> > used to dynamically swap default.target (or alter units in general)
> > depending on some condition, as they also run after /sys is mounted but
> > before any units at all are started... though this would only work if
> your
> > wanted sysfs entries appear without needing udev.
>
> Interesting, I wasn't aware such things could be performed. About udev:
> The way I
> understand it, udev is mostly involved in dynamic device probing or
> managing/reacting to device events. Is that correct?
>

It doesn't probe devices (the kernel does that), but it does react to the
kernel's "device detected" events – loads additional kernel modules (e.g.
if a USB device with specific vid:pid was probed, udev loads the
corresponding .ko module), forwards events to userspace (e.g. to systemd),
etc.


> In my particular scenario, I have a complete devicetree that contains the
> nodes
> for all the hardware I need. So from my understanding that's enough for the
> kernel to load the drivers et al, or am I mistaken?
>

DT tells the kernel what devices exist without it needing to e.g. scan a
bus (which the kernel would do on its own anyway – that's not udev's job),
but it *doesn't* tell the kernel what .ko modules to load for them (that's
udev's job).

So if all necessary drivers are built-in, great. But if some of them are
modular, udev is usually still needed, whether the device was discovered
through DT or ACPI or something else.


> > > - After which stage in the boot process is the sysfs available?
> > >
> >
> > It is mounted by init before any units are started. (sysfs *is* how you
> > interact with the kernel though...)
>
> That will make my life a lot easier. I really meant I don't want to
> program the
> syscalls to the kernel myself etc.
>

There aren't any other syscalls that would do what /sys does, anyway. The
file-based interface (i.e. open/read/write syscalls on /sys) is often the
*only* interface.


> >
> > But that doesn't mean all *devices* are available in it – many things
> could
> > take some time to appear, and devices requiring drivers to be loaded as
> > modules would only become available some unspecified time after
> > systemd-udevd.service is started.
>
> But isn't really any device driver a module?


No, they can be compiled into the main kernel image as well (and on
embedded systems, most likely they all are, but...still). "Module"
specifically means a separate .ko file in /lib/modules, as opposed to the
driver being literally part of /vmlinuz. Usually the kernel has some mix of
built-in and modular drivers.

If udev is responsible for loading
> the kernel modules (drivers) then that would mean I can't access any
> device at
> this stage, right?
> I thought that statically defining the devices and their drivers in the
> devicetree makes them available without ''extra effort''.
>

The de

Re: [systemd-devel] Intercepting/Delaying the boot process

2022-04-08 Thread Mantas Mikulėnas
On Fri, Apr 8, 2022 at 10:08 AM Andreas Hartmann  wrote:

> Hi,
>
>
> I've been owning a Pinephone for a while now and one thing that I find
> rather
> annoying is that whenever I plug the charger in, the thing will perform a
> full
> boot. I often find myself just wanting to plug it in without performing a
> full
> boot, i.e. only to have it charge and maybe see how far it has charged
> already.
>
> To this end I was wondering whether it would be feasible to "hook" into
> the boot
> process, somewhere before the disks are decrypted, to only have it charge
> (or
> continue to boot when I press some magic button maybe). Looking at the
> order of
> service startup I was thinking about maybe intercepting the boot between
> "local-
> fs-pre.target" and "machines.target" because nothing happens there on my
> setup.
>

That "between" doesn't make sense, because the boot process waits for
machines.target *in parallel* with waiting for all other services that are
started via multi-user. The systemd boot process is non-linear and doesn't
have a fixed order, it's a dependency graph.

According to bootup(7), there are two main synchronization points,
sysinit.target and basic.target, which all non-"early" services will wait
for. So if you have a service with Before=basic.target, it'll delay startup
of all normal services. (It would then need to explicitly specify After=
for things it needs, like specific devices or sockets.)

If the device was using an initramfs (which has a fully separate boot
process, its own udevd, etc.) then you could make the initramfs decide
between starting a normal boot vs minimal boot depending on charger status.
If it doesn't have an initramfs, then systemd *generators* could also be
used to dynamically swap default.target (or alter units in general)
depending on some condition, as they also run after /sys is mounted but
before any units at all are started... though this would only work if your
wanted sysfs entries appear without needing udev.


> For this to work ideally I would like to have the sysfs available so I
> don't have
> to interact with the kernel directly. So here are my questions:


> - After which stage in the boot process is the sysfs available?
>

It is mounted by init before any units are started. (sysfs *is* how you
interact with the kernel though...)

But that doesn't mean all *devices* are available in it – many things could
take some time to appear, and devices requiring drivers to be loaded as
modules would only become available some unspecified time after
systemd-udevd.service is started.

If you need a specific /sys or /dev device that's not guaranteed to be
available statically, the correct way would be to use an After= dependency
on that specific device (like After=dev-sda.device). Systemd relies on udev
events for this.


> - Can I delay the boot for an indefinite amount of time, or will this
> cause some
> services later on in the process to timeout and fail?
>

In theory you could, similar to how systemd-fsck works, but I'm not sure if
that's the right way to do what you want.


> - Is it possible for a service during early boot to command a system
> shutdown
> instead of continuing to boot?
> - May I simply take control of the TTY and clear/rewrite it as I like, or
> does
> systemd use some magic for this?
>
> Thank you in advance!
>
>
> hartan
>
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: [EXT] Dropping split-usr/unmerged-usr support

2022-04-06 Thread Mantas Mikulėnas
On Wed, Apr 6, 2022 at 10:41 PM Wols Lists  wrote:

> On 06/04/2022 10:34, Luca Boccassi wrote:
> >> Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> >> IMHO.
> >>
> >> It seems systemd is the new Microsoft ("We know what is good for you;
> >> just accept it!");-)
>
> Well, I saw a link to WHY we have /bin, /usr/bin, /sbin etc. Interesting
> read ...
>
> / was disk0. /usr was apparently originally short for /user, on disk1.
> Then the system disk ran out of space, so they created /usr/bin to have
> more space. So when they got a 3rd disk, they called it /home and moved
> all the user directories across ...
>

Hmm, from what I managed to gather in various old docs, that "3rd disk" was
still /usr2 originally... until SunOS 4.0
<http://www.bitsavers.org/pdf/sun/sunos/4.0.3/800-3812-10A_Installing_the_SunOS_4.0.3_198904.pdf#page=39>,
which decided to implement a read-only /usr and did some major /usr
reorganization – kicked out home directories to /home, logs to /var/adm,
crontabs to /var/spool, and so on. And it apparently had "/bin => usr/bin"
and "/lib => /usr/lib" symlinks as part of that reorganization, in 1989.
(Though it still had a separate /sbin with barely anything except 'init'
and 'mount' inside.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Q: journalctl -b -g logrotate

2022-04-05 Thread Mantas Mikulėnas
On Tue, Apr 5, 2022 at 3:22 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 05.04.2022 um 11:08 in
> Nachricht
> :
> > On Tue, Apr 5, 2022 at 9:36 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> Hi!
> >>
> >> I have two questions for "journalctl -b -g logrotate":
> >>
> >> 1) I'm unsure what the exact rules for matching a "-g expression" are:
> >> Some kernel messages are matched, others not.
> >>
> >
> > All entries with a MESSAGE= are matched (after doing until/since/boot-id
> > checks). They might still be hidden for other reasons though, e.g.
> messages
> > containing weird escape characters (or accidental binary data) will be
> > hidden unless you use -a.
>
> And how do I find out whether a kernel message has a MESSAGE=?
>

Messages from kernel (kmsg) or from syslog always do, it's only userspace
messages from sd_journal_send() that might not have one. (Though if it
shows up in journalctl, then obviously it has a message.) Try different
`-o` modes though to see what fields each log entry actually has.


>
> As soon as I add _MESSAGE= I get no output any more (even with MESSAGE=.*).
>

It's MESSAGE, not _MESSAGE, and there's no regex support for this kind of
match. Journalctl can't search for "all entries that contain this key"
unfortunately. (Would be useful though.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: journalctl -b -g logrotate

2022-04-05 Thread Mantas Mikulėnas
On Tue, Apr 5, 2022 at 9:36 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I have two questions for "journalctl -b -g logrotate":
>
> 1) I'm unsure what the exact rules for matching a "-g expression" are:
> Some kernel messages are matched, others not.
>

All entries with a MESSAGE= are matched (after doing until/since/boot-id
checks). They might still be hidden for other reasons though, e.g. messages
containing weird escape characters (or accidental binary data) will be
hidden unless you use -a.


> 2) When the -b restricts messages to the current boot, why is output shown
> like this?:
> # journalctl -b -g logrotate
> -- Logs begin at Wed 2020-11-25 11:27:53 CET, end at Tue 2022-04-05
> 08:01:02 CEST. --
>
> I mean the boot was definitely in 2022, so I think the message is not
> really helpful. Why not show the date and time when the search starts (i.e.
> boot time)?
>

There's no such message in the current systemd version. See
https://github.com/systemd/systemd/pull/21775.


>
> The next thing is "-k": If I supply it, kernel messages are _not_ found:
> # journalctl -S 2022-04-02 -k | grep "OCFS2:" |head
> # journalctl -S 2022-04-02 | grep "OCFS2:" |head
> Apr 02 02:00:06 h18 kernel: OCFS2: ERROR (device dm-17):
> ocfs2_validate_gd_self: Group descriptor #209970 has bad signature EXBLK01
> Apr 02 02:00:06 h18 kernel: OCFS2: File system is now read-only.
> Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17):
> ocfs2_validate_gd_self: Group descriptor #209817 has bad signature EXBLK01
> Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17):
> ocfs2_validate_gd_self: Group descriptor #209946 has bad signature EXBLK01
>
> So can I find kernel messages from previous boots?
>

`journalctl -k` is meant to imitate dmesg (except with correct timestamps),
so it shows the current boot only. You can use _TRANSPORT=kernel to filter
for kernel messages if you don't want that.

$ journalctl _TRANSPORT=kernel -g BogoMIPS

-- 
Mantas Mikulėnas


Re: [systemd-devel] What is wrong with my .path setup?

2022-03-20 Thread Mantas Mikulėnas
On Sun, Mar 20, 2022, 23:27 John Ioannidis  wrote:

> Here are my .path and .service files:
>
> $ *cat /etc/systemd/system/trigg.path *
> [Path]
> DirectoryNotEmpty=/root/trigger
> MakeDirectory=true
>
> $ *cat /etc/systemd/system/trigg.service *
> [Unit]
> Description=Trigger Service
>
> [Service]
> ExecStart=/usr/bin/touch /root/wastriggered
> Type=oneshot
>
>
> Now, after robooting, I would have expected that /root/trigger would
> exist; it does not. And, of course, creating it manually and touching a
> file in there does not trigger the path.
>
> What am I missing? I have successfully used .path units in the past, and
> what I'm doing here looks right; unfortunately I do not have access to
> those old machines any more (previous employer).
>

Seems like there's nothing that would activate your .path unit itself –
path watches or timer schedules are only established while the .path or the
.timer is "started". So you will usually need:

[Install]
WantedBy=paths.target

and the corresponding 'systemctl enable'.


Re: [systemd-devel] timer "OnBootSec=15m" not triggering

2022-03-07 Thread Mantas Mikulėnas
On Mon, Mar 7, 2022 at 11:22 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I wrote some services that should run when booting and some time after
> booting.
> As it seems the service to run during boot works, but the timer-triggered
> one
> does not.
> I have no idea why.
>
> Here are the details:
> # systemctl status prevent-fencing-loop.service
> ● prevent-fencing-loop.service - Prevent Pacemaker Fencing-Loop
>  Loaded: loaded (/usr/lib/systemd/system/prevent-fencing-loop.service;
> enabled; vendor preset: disabled)
>  Active: inactive (dead) since Sat 2022-03-05 10:33:50 CET; 1 day 23h
> ago
>Docs: man:boot-loop-handler(8)
>Main PID: 5226 (code=exited, status=0/SUCCESS)
>
> Mar 05 10:33:50 h19 systemd[1]: Starting Prevent Pacemaker Fencing-Loop...
> Mar 05 10:33:50 h19 boot-loop-handler[5234]: 1 of 4 allowable boots
> Mar 05 10:33:50 h19 systemd[1]: prevent-fencing-loop.service: Succeeded.
> Mar 05 10:33:50 h19 systemd[1]: Finished Prevent Pacemaker Fencing-Loop.
>
> So this service ran during boot.
>
> # systemctl status reset-boot-counter.timer
> ● reset-boot-counter.timer - Reset Boot-Counter after 15 minutes
>  Loaded: loaded (/usr/lib/systemd/system/reset-boot-counter.timer;
> enabled; vendor preset: disabled)
>  Active: inactive (dead)
> Trigger: n/a
>

It's not a problem with any of the [Timer] On* configuration – the problem
is that the whole .timer unit isn't active, so its triggers won't get
scheduled in the first place.


> [Install]
> WantedBy=timer.target
>

The timer is not being scheduled because it's WantedBy a nonexistent
target. I think you meant 'timer*s*.target' here.

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd failing to close unwanted file descriptors & FDS spawning and crashing

2022-03-04 Thread Mantas Mikulėnas
On Fri, Mar 4, 2022 at 11:26 AM Christopher Obbard <
chris.obb...@collabora.com> wrote:

> Right, so it looks like the call to close_range fails. This is a 5.4
> kernel which doesn;t have close_range - so this is understandable.
>

No, if it was just a missing syscall, it would fail with -ENOSYS instead
(triggering systemd's fallback to a traditional close() loop). That's what
happens on vanilla 5.4 and older kernels.

If you're getting -EINVAL, then either your downstream patches tried to
backport close_range (unsuccessfully), or... added a whole different
syscall at the same syscall number, so check what your kernel's
arch/**/syscall.tbl says about number 436?

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd failing to close unwanted file descriptors & FDS spawning and crashing

2022-03-03 Thread Mantas Mikulėnas
Ah, right, I forgot – since this is done in the service child (right before
exec) and not in the main process, you probably need to add the -f option
to make strace follow forks...

On Thu, Mar 3, 2022, 22:08 Christopher Obbard 
wrote:

> Hi Mantas,
>
> On 03/03/2022 19:18, Mantas Mikulėnas wrote:
> > On Thu, Mar 3, 2022 at 9:09 PM Christopher Obbard
> > mailto:chris.obb...@collabora.com>> wrote:
> >
> > Hi systemd experts!
> >
> > I am using systemd-247 and systemd-250 on debian system, which is
> > running a minimal downstream 5.4 kernel for a Qualcomm board.
> >
> > systemd 241 in debian buster works fine, but systemd 247 (debian
> > bullseye) and systemd 250 (debian unstable) seem to get upset about
> > file
> > descriptors on services. These errors are consistant and the board
> > boots
> > just fine with init=/bin/sh
> >
> > I've got the required kernel config from README in my kernel, I am
> > using
> > a heavily patched downstream kernel, but from the following log can
> you
> > suggest anything I can do to debug this (other than throwing the
> board
> > out of the window) ?
> >
> >
> >  From the message, it looks like the error is returned by
> > close_all_fds() in src/basic/fd-util.c, where the only major change is
> > that it has been ported to call close_range() if that's available...
> >
> > I would boot with init=/bin/sh, then run `exec strace -D -o
> > /var/log/systemd.trace /lib/systemd/systemd` to get a trace, and see if
> > the EINVAL actually comes from calling close_range() or from something
> else.
> >
> > --
> > Mantas Mikulėnas
>
> Thanks for your reply. It reproduced nicely with the command you gave.
>
> Seems like nothing related to close_range returning EINVAL, only the
> following calls returned EINVAL:
>
> cat systemd-failing.trace | grep EINVAL
> prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = -1 EINVAL (Invalid
> argument)
> prctl(PR_CAPBSET_READ, CAP_PERFMON) = -1 EINVAL (Invalid argument)
> read(4, 0x55675a75b0, 4095) = -1 EINVAL (Invalid argument)
> mount("cgroup2", "/proc/self/fd/4", "cgroup2",
> MS_NOSUID|MS_NODEV|MS_NOEXEC, "nsdelegate,memory_recursiveprot") = -1
> EINVAL (Invalid argument)
>
>
> I have attached the full strace output, in case that would be useful?
>
> Thanks
> Chris


Re: [systemd-devel] systemd failing to close unwanted file descriptors & FDS spawning and crashing

2022-03-03 Thread Mantas Mikulėnas
On Thu, Mar 3, 2022 at 9:09 PM Christopher Obbard <
chris.obb...@collabora.com> wrote:

> Hi systemd experts!
>
> I am using systemd-247 and systemd-250 on debian system, which is
> running a minimal downstream 5.4 kernel for a Qualcomm board.
>
> systemd 241 in debian buster works fine, but systemd 247 (debian
> bullseye) and systemd 250 (debian unstable) seem to get upset about file
> descriptors on services. These errors are consistant and the board boots
> just fine with init=/bin/sh
>
> I've got the required kernel config from README in my kernel, I am using
> a heavily patched downstream kernel, but from the following log can you
> suggest anything I can do to debug this (other than throwing the board
> out of the window) ?
>

>From the message, it looks like the error is returned by close_all_fds() in
src/basic/fd-util.c, where the only major change is that it has been ported
to call close_range() if that's available...

I would boot with init=/bin/sh, then run `exec strace -D -o
/var/log/systemd.trace /lib/systemd/systemd` to get a trace, and see if the
EINVAL actually comes from calling close_range() or from something else.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Journald: Re-use /var/log/journal hash entry after system upgrade

2022-03-01 Thread Mantas Mikulėnas
On Tue, Mar 1, 2022 at 4:39 PM eric.zalu...@vertiv.com <
eric.zalu...@vertiv.com> wrote:

>  [ System Environment ] 
> On an embedded x86-64 Linux system, I’m running systemd v241. I have
> Systemd-Journald logging set to persistent with SystemMaxUse and
> RuntimeMaxUse both set to 512MB.
>
> The Linux system mount loops /var/log on start-up from a var-log.ext4
> file. The /var/log mount is given a fixed size of the disk (976MB). Systemd
> creates a journal entry directory given a hash name in
> /var/log/journal/.
>
>
>
>  [ System Information ] 
>
> Linux 4.19.0-6-2-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64
> GNU/Linux
>
>
>  [ Problem ] 
>
> When the system firmware is upgraded, Systemd creates a new journal entry
> directory with a different hash name and no longer recognizes the previous
> hash directory.
>
> The old logs from the previous journal entry can no longer be managed. The
> old logs are never rotated and cannot be manually rotated using the
> journaldctl cli. The disk usage calculator by Journald does not account for
> the previous journal entry meaning if there are two previous entries in
> /var/log that consume 900MB of space; then the new journal entry only has
> 76MB of space to work with. Eventually, disk space will be full. Journald
> cannot automatically flush, vacuum, clean, rotate previous logs because it
> does not recognize the previous journal entries.
>
> There must be a systemd journald check that occurs where it determines
> these other entries are not for it to manage.
>

This is not a 'hash' – it's the machine ID
<https://www.freedesktop.org/software/systemd/man/machine-id.html>, which
is directly read from /etc/machine-id. Normally the machine ID is randomly
generated during *first *boot (it's just a random UUID), and it is supposed
to be persistent afterwards.

It sounds like your /etc doesn't have that file and is on a read-only
rootfs, so systemd generates a new machine-id in tmpfs every boot. The
device probably has *some* persistent storage though, so try to find a way
to make /etc/machine-id persist as well (see the machine-id(5)
<https://www.freedesktop.org/software/systemd/man/machine-id.html> manual
page for a few possibilities).

The intent of using machine-id subdirectories is to allow containers'
journal directories to be symlinked on the host, or remote system journals
to be collected on a single system – there's actually the journalctl -m
option to make it look at "foreign" journals, so e.g. journalctl -m -f
could be used to watch logs of all containers.

(The machine ID is also used as the base for systemd-networkd's DHCPv4
Client ID, DHCPv6 DUID, and IPv6 address generation. But other than that,
though, I can't think of any its uses that would be visible externally –
aside from desktop-specific things like pulseaudio – so in some cases it
might be "good enough" to pre-define a fixed ID in the template image as a
last resort.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Syntax check for a new service?

2022-03-01 Thread Mantas Mikulėnas
On Tue, Mar 1, 2022 at 2:32 PM Tom Browder  wrote:

> On Sat, Feb 26, 2022 at 12:06 Mantas Mikulėnas  wrote:
> ...
>
>> Use the Environment= option to set environment variables.
>>
>
> Thanks, Mantas. That works great.
>
> One more question: I'm thinking of making the service have myself as the
> user (non-privileged). Is that a bad practice since I'm also the root user
> (and currently the only user)?
>

That actually makes it relatively privileged – it has full access to *your*
files and processes... So unless accessing your data is the service's
explicit purpose (e.g. Transmission or MPD or Xvnc), then it should have
its own account, or at least have something like an AppArmor policy loaded.

[1] Obligatory https://xkcd.com/1200/

-- 
Mantas Mikulėnas


Re: [systemd-devel] Syntax check for a new service?

2022-02-26 Thread Mantas Mikulėnas
On Sat, Feb 26, 2022 at 7:05 PM Tom Browder  wrote:

> On Sat, Feb 26, 2022 at 09:38 Dave Howorth  wrote:
>
>> On Sat, 26 Feb 2022 09:17:38 -0600
>> Tom Browder  wrote:
>> > Is there any way to get a plain syntax check of a potential new
>> > service file?
>>
>> systemd-analyze verify FILE...
>
>
> Thanks, Dave.
>
> I'm apparently having problems with the executable file and I'm not sure
> if I need
> the Type to be simple or oneshot.
>
> The service I'm trying to create is to emulate a user at the CLI executing
> a script running in the foreground who never logs out.
>
> The script loops infinitely listening and responding to a specific port
> behind an apache reverse proxy. The script is programmed to stop with a
> Ctr-C. It can be left with "nohup &" (but I'm not sure if that interferes
> with its design yet).
>

Right, that's basically how all services work. (It's not really something I
would call "emulating a user" – that just feels backwards. It's more like
*the user* with 'nohup' is emulating a service manager here...)

If the service remains running in foreground, it's Type=simple. (Services
which go into background, i.e. have a 'daemonize' function, would be
Type=forking.)

Type=oneshot is for "one-shot" tasks which do something relatively quick
and exit; for example, if another unit had "After=an-oneshot.service", it
would wait until that service *exits,* rather than until it's "started".
It's not suitable for actual long-running services like yours – if you
tried to use Type=oneshot, systemd would think your service was "starting"
forever.


>
> I do know I have to set an environment variable for the executable to find
> its libraries, and I'm not sure how to do that in the service file to
> emulate this:
>
> export MYLIB=/path/to/lib; /path/to/prog
>
> I have tried both Type=oneshot and Type=simple but neither like the single
> ExecStart= line with that command.
>

Neither of them invoke /bin/sh to parse the command – the *shell* is what
normally would interpret the "export ..." in a shell script, but that
doesn't happen in systemd services. In all cases, ExecStart is minimally
parsed by systemd itself and then just directly execve()'d.

Use the Environment= option to set environment variables.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: Wanting a target

2022-02-23 Thread Mantas Mikulėnas
On Wed, Feb 23, 2022 at 3:40 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I think there was a recent discussion saying that no unit should Want= or
> Require= a target, but only use them for ordering.
> I have basically three questions:
>
> 1) Is the statement above correct?
>

Not for all targets in general. It may be correct for some .targets but not
others, and for some services but not others, but something *does* need to
pull the target in as a dependency, otherwise it would never be started –
there's (almost) nothing special in ordering against targets,
After=foo.target only waits for foo.target to become "started" like for
other unit types.

Some of the systemd-provided targets differ in whether the "provider" vs
"consumer" should Want them. For example, systemd.special(7) says that
Wants=network.target should go in the network provider (so other services
only need an After), while Wants=network-online.target would go in the
"consumer" service that wants to *wait* for network (as the target itself
has dependencies that shouldn't be started unless needed).

For some targets, "Wants or no Wants" follows the same rules as for
services – e.g. tinc VPN became multi-instance and got a .target to cover
all instances, so if you previously wouldn't have used Wants=tinc.service
but only After, then the same applies to the new .target as well.


>
> 2) When is a target displayed as "started" by sysctemctl status then?
>

When it gets started.


>
> 3: Which of the following (form current SLES12 SP5, grep-style) are wrong?:
>
> /usr/lib/systemd/system/ntpd.service:Wants=network.target
> /usr/lib/systemd/system/ntpd.service:After=network.target
>
> /usr/lib/systemd/system/nfs-server.service:Requires= network.target
> proc-fs-nfsd.mount
> /usr/lib/systemd/system/nfs-server.service:After= network.target
> proc-fs-nfsd.mount rpcbind.socket nfs-mountd.service
>
> /usr/lib/systemd/system/nmb.service:After=network.target
>

According to docs for network.target, it's the first two that are "wrong".

-- 
Mantas Mikulėnas


Re: [systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG

2022-02-16 Thread Mantas Mikulėnas
On Wed, Feb 16, 2022 at 2:27 PM Lennart Poettering 
wrote:

> On Di, 15.02.22 19:05, Stefan Schröder (ste...@tokonoma.de) wrote:
>
> > Situation:
> >
> > Many packages in a distribution ship with a default configuration
> > that is not considered 'secure'.
>
> Do they? What dos "secure" mean? If there's a security vulnerability,
> maybe talk to the distro about that? They should be interested...
>
> > Hardening guidelines are available for all major distributions. Each is
> a little different.
> > Many configuration suggestions are common-sense among security-conscious
> administrators, who have to apply more secure configuration using some
> automation framework after installation.
> >
> > PROPOSAL
> >
> > os-release or machine-info should be amended with a field
> >
> >   PREFER_HARDENED_CONFIG
> >
> > If the value is '1' or 'True' or 'yes' a package manager can opt to
> > configure an alternative, more secure default configuration (if
> > avaialble).
>
> I am not sure what "hardening" means, sounds awfully vague to me. I
> mean, i'd assume that a well meaning distro would lock everything down
> as much as they can *by*default*, except if this comes at too high a
> price on performance or maintainance or so. But how is a single
> boolean going to address that?
>
> If security was as easy as just turning on a boolean, then why would
> anyone want to set that to false?
>
> > According to the 'Securing Debian Manual' [1] the login configuration is
> configured as
> > auth   optional   pam_faildelay.so  delay=300
> > whereas
> > delay=1000
> > would provide a more secure default.
> >
> > The package 'login' contains the file /etc/pam.d/login. If dpkg (or
> > apt or rpm or pacman or whatever) detected that os-release asks for
> > secure defaults, the alternative /etc/pam.d./login.harden could be
> > made the default. (This file doesn't exist yet, the details are left
> > to the packaging infrastructure or package maintainer.)
>
> If the default settings are too low, why nor raise them for everyone?
>
> I must say, I am very sure that the primar focus should always be on
> locking things down as well as we can for *everyone* and as
> *default*. Making security an opt-in sounds like a systematically
> wrong approach. If specific security tech cannot be enabled by
> default, then work should be done to make it something that can be
> enabled by default. And if that's not possible then it apparently
> comes at some price, but a simple config boolean somewhere can't
> decide whether that price is worth it...


IMO "locking things down by default" is already overdone a bit...

Arch now ships pam_faillock in its /etc/pam.d/login, and the upstream PAM
default is to lock you out after three consecutive password failures.
*Three.* I'd say that's too high for local console logins even on servers,
but even if it's right for servers it is *way* too strict for personal
machines (e.g. even iPhones allow five wrong PINs).

Especially with GNOME still having a broken keyboard layout indicator
that's stuck permanently on "en", so half the time I resume the laptop and
get three failures for free just because the keyboard is different. You're
in a hurry to check on some problem, make three typos, you're locked out
for 10 minutes, and you're about to throw the computer out the window :-|

I don't think it's a good idea to stick a "lockdown" knob in machine-info,
though (and definitely not os-release) – most admins who want it probably
won't be satisfied with what it does anyway, they'll want their specific
parameters anyway. And in this particular example, maybe the parameters
should be different for *local vs network* logins, rather than depending on
machine type... (I mean, if a machine deserves "hardened" settings, it's
going to be in a locked room and you can't just walk up to it and start
trying passwords anyway.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] [RFC] systemd-resolved: Send d-bus signal after DNS resolution

2022-02-16 Thread Mantas Mikulėnas
On Wed, Feb 16, 2022 at 12:37 AM Suraj Krishnan 
wrote:

> Hello,
>
>
>
> I’m reaching out to the community to gather feedback about a feature to
> broadcast a d-bus signal notification from systemd-resolved when a DNS
> query is completed. The message would contain information about the query
> and IP addresses received from the DNS server.
>

IMO, broadcasts that are visible to everyone on the system bus are *really
not a good idea*, especially for multi-user systems. (Not a fan of
`ipconfig.exe /displaydns` being open to non-admins, either.) If such
logging has to exist at all, it should only go to some specific destination.

I'm kinda guessing you want this for situations where resolved uses
DNS-over-TLS? If audit logging is necessary, maybe it would be better to
use the existing "audit framework" – systemd already links to libaudit for
service start/stop operations (via audit_log_user_comm_message).

Not sure how or why domain resolution be integrated with the firewall,
though.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Service activation

2022-02-13 Thread Mantas Mikulėnas
On Sun, Feb 13, 2022 at 1:09 PM Wols Lists  wrote:

> On 13/02/2022 09:54, Mantas Mikulėnas wrote:
> > On Sun, Feb 13, 2022 at 2:03 AM Wol  > <mailto:antli...@youngman.org.uk>> wrote:
> >
> > More fun getting things to work ... :-)
> >
> > So I've got a service, scarletdme.service, which fires up my db
> backend
> > for running interactively. However, I also need a socket service for
> > remote connections.
> >
> > I've got the xinetd files, but if I'm running systemd, I want to use
> > systemd :-)
> >
> > So I've written scarletdme.socket, and scarletdme@.service, but the
> > more
> > I read, the more I don't understand ...
> >
> > Do I enable scarletdme.socket the same as anything else eg "systemctl
> > enable scarletdme.socket"? How does it know the difference between
> > scarletdme.service and scarletdme@.service? I get the impression I
> need
> > to put something in the .socket file to make it use scarletdme@
> rather
> > than scarletdme?
> >
> >
> > If it's a 'nowait' socket (which is "[Socket] Accept=yes" in systemd
> > terms), then it will use the templated @.service, starting a new
> > instance for each "accepted" socket (i.e. instance per connection). See
> > oidentd.socket for comparison.
> >
> > Otherwise (by default) it uses the non-templated service and directly
> > gives it the "listening" socket, letting the service itself handle
> accept().
> >
> ??? Sorry, that's double dutch to me.
>
> Are you telling me that just copying the files into /lib/systemd/system
> will enable them? That seems weird to me because it doesn't do it for
> normal services afaik. (Or shouldn't I be copying it direct into
> /lib/systemd/system? I just don't know ...)
>

No, I was not talking about any of that. You asked how systemd knows the
difference between dme.service and dme@.service.

Sockets (and other units) are "started" and/or "enabled" the same way
services are. If you want a service to launch its process right now, you
`systemctl start` it. Likewise, if you want a .socket to *start listening*
right now, you `systemctl start` it, and if you want a .timer to start
scheduling right now, you `systemctl start` it.

You use `systemctl enable` if you want a unit to be automatically started *at
boot time *– or whatever else its [Install] section says. The "enable"
command sets up dependency symlinks from the [Install] section, where you
have "WantedBy=sockets.target" or similar. (If there's no [Install] section
yet, then `systemctl enable` will do nothing.)

Now whether dme.socket uses dme.service vs dme@.service has absolutely no
relationship to any of the above.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Service activation

2022-02-13 Thread Mantas Mikulėnas
On Sun, Feb 13, 2022 at 2:03 AM Wol  wrote:

> More fun getting things to work ... :-)
>
> So I've got a service, scarletdme.service, which fires up my db backend
> for running interactively. However, I also need a socket service for
> remote connections.
>
> I've got the xinetd files, but if I'm running systemd, I want to use
> systemd :-)
>
> So I've written scarletdme.socket, and scarletdme@.service, but the more
> I read, the more I don't understand ...
>
> Do I enable scarletdme.socket the same as anything else eg "systemctl
> enable scarletdme.socket"? How does it know the difference between
> scarletdme.service and scarletdme@.service? I get the impression I need
> to put something in the .socket file to make it use scarletdme@ rather
> than scarletdme?
>

If it's a 'nowait' socket (which is "[Socket] Accept=yes" in systemd
terms), then it will use the templated @.service, starting a new instance
for each "accepted" socket (i.e. instance per connection). See
oidentd.socket for comparison.

Otherwise (by default) it uses the non-templated service and directly gives
it the "listening" socket, letting the service itself handle accept().


>
>
> And once I've got all that sorted, I'm betting I'm going to have grief
> getting it to work properly, so while it's not much to do with systemd,
> is there any way I can get systemd to log all traffic back and forth so
> I can debug it?
>

No, the traffic doesn't even go through systemd in the first place.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)

2022-02-10 Thread Mantas Mikulėnas
On Thu, Feb 10, 2022 at 3:08 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 10.02.2022 um 12:30 in
> Nachricht
> :
> > On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht
> <6204E61B.426
> >> :
> >> 161 :
> >> 60728>:
> >> >>>> Mantas Mikulenas  schrieb am 10.02.2022 um
> 10:34
> >> in
> >> > Nachricht
> >> > :
> >> > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <
> >> > > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >> > >
> >> > >> Hi!
> >> > >>
> >> > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64)
> >> where
> >> > >> smartd is restarted for no obvious reason. Support says everything
> is
> >> fine,
> >> > >> but I disagree.
> >> > >> Specifically smartd.service uses:
> >> > >>
> >> > >> [Service]
> >> > >> Type=notify
> >> > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts
> >> > >> ExecStart=/usr/sbin/smartd -n $smartd_opts
> >> > >> ExecReload=/bin/kill -HUP $MAINPID
> >> > >>
> >> > >> And mostly I wonder to what types of changes "notify" does react.
> >> > >>
> >> > >
> >> > > None. It's not an activation mechanism and not a configuration
> >> monitoring
> >> > > mechanism – it's a readiness indication mechanism.
> >> > >
> >> > > Type=notify expects the service to send a message to a Unix socket
> (at
> >> > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some
> >> custom
> >> > > text to show in 'systemctl status'.)
> >> >
> >> > Mantas,
> >> >
> >> > thanks for explaining; obviously I was wrong. But still: How can I
> find
> >> out
> >>
> >> > why the smartd.service restarts?
> >>
> >> Hi!
> >>
> >> I digged further into it:
> >> smartd_generate_opts.path has:
> >> [Path]
> >> Unit=smartd_generate_opts.service
> >> PathChanged=/etc/sysconfig/smartmontools
> >>
> >> smartd_generate_opts.service has:
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/usr/lib/smartmontools/generate_smartd_opts
> >>
> >> Finally /usr/lib/smartmontools/generate_smartd_opts is not documented.
> >>
> >> But running that program causes a restart of smartd!
> >>
> >
> > I'm not saying this is complete garbage but ugh.
> >
> > At least it doesn't seem to be an upstream thing.
> >
> >
> >> The "Change" date was most likely caused by backup software resetting
> the
> >> Access time.
> >>
> >
> > The backup software really ought to start using open(O_NOATIME) and avoid
> > having to "reset" anything in the first place...
> >
> >
> >> So back to systemd: What time stamp does it use for PathChanged=?
> >>
> >
> > Technically none – it watches *inotify* events (all except IN_MODIFY).
> > Specifically PathChanged= reacts to:
> >
> > [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB |
> > IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO,
> >
> > (https://github.com/systemd/systemd/blob/main/src/core/path.c#L37)
> >
> > So basically a) any kind of rename, delete, attribute change (stuff that
> > changes ctime), or b) whenever the file gets *closed* after it has been
> > written to (stuff that changes mtime).
>
> Hi!
>
> So a unit using PathChanged= is expected to check again what actually has
> changed?
>

Yes, .path units (not unlike .timer units) only activate another unit but
can't inform it of *why* it just got activated.


> Doesn't really sound like being useful, as must users probably assume that
> "Changed" refers to file content change.
>

Which is what PathChanged= includes. (The difference between PathChanged
and PathModified is that the latter triggers immediately for each
individual write (IN_MODIFY), while PathChanged delays the trigger until
the file is closed. That makes PathModified the less useful one, in most
situations.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Antw: Re: [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts

2022-02-10 Thread Mantas Mikulėnas
On Thu, Feb 10, 2022 at 3:11 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Etienne Champetier  schrieb am
> 10.02.2022 um
> 12:47 in Nachricht
> :
> > Le jeu. 10 févr. 2022 à 11:49, Ulrich Windl
> >  a écrit :
> >>
> >> >>> Lennart Poettering  schrieb am 10.02.2022
> um
> 11:31
> >> in
> >> Nachricht :
> >> > On Mi, 09.02.22 22:05, Etienne Champetier (
> champetier.etie...@gmail.com)
> >> > wrote:
> >> >
> >> >> Hello systemd hackers,
> >> >>
> >> >> After flashing the firmware of some pcie card I need to power cycle
> >> >> the server to finish the flashing process.
> >> >> For now I have a simple script in lib/systemd/system-shutdown/
> running
> >> >> "ipmitool power cycle" but I would like to make sure it runs after
> >> >> other scripts like fwupd.shutdown or mdadm.shutdown
> >> >>
> >> >> Is there any way to have systemd cleanly power cycle my server
> instead
> >> >> of rebooting it ?
> >> >
> >> > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't
> >> > "systemctl reboot" suffice?
> >>
> >> My guess is that some smart cards with their own firmware and CPu do not
> >> reboot unless they are power cycled, so maybe if the firmware upgrade on
> the
> >> card does not force it to reboot, it my need a power cycle.
> >>
> >> >
> >> > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS
> >> > transitions back into the initrd — the initrd will then detach the
> >> > root fs (i.e. undo what it attached at boot) and actually reboot. This
> >> > means if your command turns off the power source you should stick it
> >> > in the initrd's shutdown logic, and not into
> >> > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means
> >> > into dracut. But adding it there is something to better discuss with
> >> > the dracut community than here.
> >>
> >> My guess is that it would be handled best by some special GRUB boot
> menu
> > entry
> >> (like "boot 'power cycle' once).
> >
> > This is pretty clean but it means going through "BIOS" init twice
> > which can be pretty long on physical servers
>
> Hi!
>
> Of course I have a better solution: Use an external server and just before
> restarting send a command to that server that will, after a carefully tuned
> delay, will trigger the IPMI power-cycle remotely ;-)
> I believe that it's almost impossible to trigger a power cycle through IPMI
> while also doing a clean shutdown/reboot, unless the the IPMI features a
> delayed execution itself.
>

Asking the BMC to power the system off is no different than asking the
system to power itself off – what makes it a "clean shutdown" is stopping
services, syncing and unmounting filesystems, etc. So in theory these
shutdown hooks should do the job.

Though a better place would be a "shutdown initramfs" which runs from a
tmpfs after *all* storage has been unmounted. I think Dracut has that, and
explicitly specifies the order for its shutdown hooks, so it should be
possible to put ipmitool there.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)

2022-02-10 Thread Mantas Mikulėnas
On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426
> :
> 161 :
> 60728>:
> >>>> Mantas Mikulenas  schrieb am 10.02.2022 um 10:34
> in
> > Nachricht
> > :
> > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <
> > > ulrich.wi...@rz.uni-regensburg.de> wrote:
> > >
> > >> Hi!
> > >>
> > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64)
> where
> > >> smartd is restarted for no obvious reason. Support says everything is
> fine,
> > >> but I disagree.
> > >> Specifically smartd.service uses:
> > >>
> > >> [Service]
> > >> Type=notify
> > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts
> > >> ExecStart=/usr/sbin/smartd -n $smartd_opts
> > >> ExecReload=/bin/kill -HUP $MAINPID
> > >>
> > >> And mostly I wonder to what types of changes "notify" does react.
> > >>
> > >
> > > None. It's not an activation mechanism and not a configuration
> monitoring
> > > mechanism – it's a readiness indication mechanism.
> > >
> > > Type=notify expects the service to send a message to a Unix socket (at
> > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some
> custom
> > > text to show in 'systemctl status'.)
> >
> > Mantas,
> >
> > thanks for explaining; obviously I was wrong. But still: How can I find
> out
>
> > why the smartd.service restarts?
>
> Hi!
>
> I digged further into it:
> smartd_generate_opts.path has:
> [Path]
> Unit=smartd_generate_opts.service
> PathChanged=/etc/sysconfig/smartmontools
>
> smartd_generate_opts.service has:
> [Service]
> Type=oneshot
> ExecStart=/usr/lib/smartmontools/generate_smartd_opts
>
> Finally /usr/lib/smartmontools/generate_smartd_opts is not documented.
>
> But running that program causes a restart of smartd!
>

I'm not saying this is complete garbage but ugh.

At least it doesn't seem to be an upstream thing.


> The "Change" date was most likely caused by backup software resetting the
> Access time.
>

The backup software really ought to start using open(O_NOATIME) and avoid
having to "reset" anything in the first place...


> So back to systemd: What time stamp does it use for PathChanged=?
>

Technically none – it watches *inotify* events (all except IN_MODIFY).
Specifically PathChanged= reacts to:

[PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB |
IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO,

(https://github.com/systemd/systemd/blob/main/src/core/path.c#L37)

So basically a) any kind of rename, delete, attribute change (stuff that
changes ctime), or b) whenever the file gets *closed* after it has been
written to (stuff that changes mtime).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Help understanding "notify" (SLES15 SP3 restarting smartd)

2022-02-10 Thread Mantas Mikulėnas
On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) where
> smartd is restarted for no obvious reason. Support says everything is fine,
> but I disagree.
> Specifically smartd.service uses:
>
> [Service]
> Type=notify
> EnvironmentFile=-/var/lib/smartmontools/smartd_opts
> ExecStart=/usr/sbin/smartd -n $smartd_opts
> ExecReload=/bin/kill -HUP $MAINPID
>
> And mostly I wonder to what types of changes "notify" does react.
>

None. It's not an activation mechanism and not a configuration monitoring
mechanism – it's a readiness indication mechanism.

Type=notify expects the service to send a message to a Unix socket (at
$NOTIFY_SOCKET) indicating that it is "ready". (And optionally some custom
text to show in 'systemctl status'.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Odd behaviour on boot

2022-02-07 Thread Mantas Mikulėnas
On Mon, Feb 7, 2022, 22:06 Tomasz Torcz  wrote:

> On Mon, Feb 07, 2022 at 07:28:46PM +, Wols Lists wrote:
> > On 07/02/2022 17:55, Mantas Mikulėnas wrote:
> > > Basically you have *a lot* of service daemons getting killed – some of
> > > them restart cleanly, others not – and it looks a bit like scarletdme
> is
> > > the one doing it. It even looks like it ended up killing itself, too.
> >
> > Thank you very much. I think that explains WHAT is going on, now to find
> out
> > why. But that's not your problem.
>
>   It does not explain. It's just an educated guesswork. We won't reach
> explanation until you check journal logs.
>

What else did I base that guesswork on...


Re: [systemd-devel] Odd behaviour on boot

2022-02-07 Thread Mantas Mikulėnas
On Mon, Feb 7, 2022, 19:43 Wols Lists  wrote:

> On 07/02/2022 14:06, Mantas Mikulėnas wrote:
> > On Mon, Feb 7, 2022 at 2:54 PM Wols Lists  > <mailto:antli...@youngman.org.uk>> wrote:
> >
> > Bear in mind I did have a malformed scarletdme.service file, it was
> > missing "Type=forking", but it shouldn't be bringing down unrelated
> > services, should it?
> >
> > This is the output from dovecot, which clearly failed to start on
> > boot...
> >
> > thewolery /dev # systemctl status dovecot
> > × dovecot.service - Dovecot IMAP/POP3 email server
> >Loaded: loaded (/lib/systemd/system/dovecot.service; enabled;
> > vendor preset: disabled)
> >Active: failed (Result: exit-code) since Mon 2022-02-07
> 07:55:11
> > GMT; 3min 53s ago
> >  Docs: man:dovecot(1)
> > https://doc.dovecot.org/ <https://doc.dovecot.org/>
> >   Process: 1511 ExecStart=/usr/sbin/dovecot -F (code=killed,
> > signal=TERM)
> >   Process: 1529 ExecStop=/usr/bin/doveadm stop (code=exited,
> > status=75)
> >  Main PID: 1511 (code=killed, signal=TERM)
> >   CPU: 22ms
> >
> > Feb 07 07:55:09 thewolery systemd[1]: Started Dovecot IMAP/POP3 email
> > server.
> > Feb 07 07:55:11 thewolery doveadm[1529]: Fatal: Dovecot is not
> running
> > (read from /run/dovecot/ma>
> > Feb 07 07:55:11 thewolery systemd[1]: dovecot.service: Control
> process
> > exited, code=exited, statu>
> > Feb 07 07:55:11 thewolery systemd[1]: dovecot.service: Failed with
> > result 'exit-code'.
> > thewolery /dev # systemctl restart dovecot
> >
> > But both samba and sshd failed similarly. I have vague recollections
> > somewhere of seeing a reference to qm in either the sshd or samba
> > output
> > pre-restart, but don't know how to get back to it. (qm is the program
> > started by scarletdme.service.)
> >
> > Any ideas, anybody suspect it might be a bug in systemd? I've fixed
> the
> > scarletdme.service, but it's a bit weird that it's the first time I
> > booted with the broken .service, and three (at least) other services
> > failed. Although my system does seem to have stability problems, so I
> > don't know for certain where to place any blame.
> >
> >
> > Have you checked the whole `journalctl -b` for messages that happened
> > around the actual failure? Could be just about anything, from services
> > getting stopped due to their dependencies failing, to something missing
> > due to *lack of* dependencies, to OOM killing random processes...
> >
> eb 07 07:55:09 thewolery systemd[1]: Reached target Socket Units.
> Feb 07 07:55:09 thewolery systemd[1]: Reached target Basic System.
> Feb 07 07:55:09 thewolery systemd[1]: Condition check resulted in
> Save/Restore Sound Card State being skipped.
> Feb 07 07:55:09 thewolery systemd[1]: Condition check resulted in Manage
> Sound Card State (restore and store) being skipped.
> Feb 07 07:55:09 thewolery systemd[1]: Reached target Sound Card.
> Feb 07 07:55:09 thewolery systemd[1]: Started D-Bus System Message Bus.
> Feb 07 07:55:09 thewolery systemd[1]: Started Dovecot IMAP/POP3 email
> server.
> Feb 07 07:55:09 thewolery systemd[1]: Starting Postfix Mail Transport
> Agent...
> Feb 07 07:55:09 thewolery systemd[1]: Started ScarletDME service start.
> Feb 07 07:55:09 thewolery systemd[1]: Starting Samba SMB Daemon...
> Feb 07 07:55:09 thewolery systemd[1]: Starting OpenSSH server daemon...
> Feb 07 07:55:09 thewolery systemd[1]: Starting User Login Management...
> Feb 07 07:55:09 thewolery systemd[1]: Starting Permit User Sessions...
> Feb 07 07:55:09 thewolery systemd[1]: Finished Permit User Sessions.
> Feb 07 07:55:09 thewolery qm[1513]: ScarletDME (64 Bit) has been started
> Feb 07 07:55:09 thewolery systemd-journald[1105]: Journal stopped
> Feb 07 07:55:10 thewolery systemd-journald[1105]: Received SIGTERM from
> PID 1521 (qm).
>

Well that's interesting.

Looks like the 'qm' service here randomly killed systemd-journald – this
alone can cause several problems, as many services' stdout goes to
journald, so killing it would cause many services to get -EPIPE as soon as
they log a message.

Feb 07 07:55:09 thewolery systemd[1]: Started Dovecot IMAP/POP3 email
> server.
> Feb 07 07:55:09 thewolery systemd[1]: Starting Postfix Mail Transport
> Agent...
> Feb 07 07:55:09 thewolery systemd[1]: Started ScarletDME service start.
> Feb 07 07:55:09 thewolery systemd[1]: Starting Samba SMB Daemon...
> Fe

Re: [systemd-devel] Odd behaviour on boot

2022-02-07 Thread Mantas Mikulėnas
On Mon, Feb 7, 2022 at 2:54 PM Wols Lists  wrote:

> Bear in mind I did have a malformed scarletdme.service file, it was
> missing "Type=forking", but it shouldn't be bringing down unrelated
> services, should it?
>
> This is the output from dovecot, which clearly failed to start on boot...
>
> thewolery /dev # systemctl status dovecot
> × dovecot.service - Dovecot IMAP/POP3 email server
>   Loaded: loaded (/lib/systemd/system/dovecot.service; enabled;
> vendor preset: disabled)
>   Active: failed (Result: exit-code) since Mon 2022-02-07 07:55:11
> GMT; 3min 53s ago
> Docs: man:dovecot(1)
>   https://doc.dovecot.org/
>  Process: 1511 ExecStart=/usr/sbin/dovecot -F (code=killed,
> signal=TERM)
>  Process: 1529 ExecStop=/usr/bin/doveadm stop (code=exited, status=75)
> Main PID: 1511 (code=killed, signal=TERM)
>  CPU: 22ms
>
> Feb 07 07:55:09 thewolery systemd[1]: Started Dovecot IMAP/POP3 email
> server.
> Feb 07 07:55:11 thewolery doveadm[1529]: Fatal: Dovecot is not running
> (read from /run/dovecot/ma>
> Feb 07 07:55:11 thewolery systemd[1]: dovecot.service: Control process
> exited, code=exited, statu>
> Feb 07 07:55:11 thewolery systemd[1]: dovecot.service: Failed with
> result 'exit-code'.
> thewolery /dev # systemctl restart dovecot
>
> But both samba and sshd failed similarly. I have vague recollections
> somewhere of seeing a reference to qm in either the sshd or samba output
> pre-restart, but don't know how to get back to it. (qm is the program
> started by scarletdme.service.)
>
> Any ideas, anybody suspect it might be a bug in systemd? I've fixed the
> scarletdme.service, but it's a bit weird that it's the first time I
> booted with the broken .service, and three (at least) other services
> failed. Although my system does seem to have stability problems, so I
> don't know for certain where to place any blame.
>

Have you checked the whole `journalctl -b` for messages that happened
around the actual failure? Could be just about anything, from services
getting stopped due to their dependencies failing, to something missing due
to *lack of* dependencies, to OOM killing random processes...

-- 
Mantas Mikulėnas


Re: [systemd-devel] network interface scripting

2022-02-05 Thread Mantas Mikulėnas
On Sat, Feb 5, 2022 at 9:46 AM Kamil Jońca  wrote:

>
> Hello.
>
> Current situation:
> debian laptop with interfaces defined in /etc/network/interfaces
> + resolvconf + dnsmasq packages and bunch of scripts wchich configures
> network
> (routes and name resolving) according to interfaces and vpn up down.
> For example
> 1.  I am connected to  home1 network (connected by wifi, no default
> routing ), this network sets routing to some subnets with dhcp option
> 121 (and dhclient scripts handles this)
> 2. I am connected via etch to router with default gateway
> 3. I am connected to work1 network via openvpn tunnel.
> 4. I am connected to work2 network via ipsec gateway.
>
> I want to (and with my current config this is done)
> that:
> 1. proper routes are established (especially these with option 121)
> 2. name resolving is properly configured:
>   ie. home1.tld DNS queries are forwarded to home1 network
>   work1.tld DNS queries are forwarded to work1 network (via openvpn
> tunnel)
>   work2.tld DNS queries are forwarded to work2 network (via ipsec
>   tunnel)
>   rest DNS is forwarded to default gateway
>

Systemd-networkd has supported the "classless static routes" option since
v215.

Per-suffix query forwarding is mostly built into systemd-resolved, although
with the restriction that domains/nameservers are grouped by interface – so
your IPsec tunnel will need its own interface (e.g. xfrmi0, or at least a
'dummy0' interface to stand in). The DNS= and Domains= configuration can be
loaded either from networkd's .network files, or through resolvectl, or
systemd's compat implementation of the `resolvconf` tool.

Netplan is, as far as I know, an Ubuntu-specific tool that just generates
systemd-networkd (or NetworkManager) configs. In case you wanted those to
be YAML-based.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Configuring wakeup-online at runtime with networkctl

2022-02-03 Thread Mantas Mikulėnas
On Thu, Feb 3, 2022 at 9:45 AM Francis Moreau 
wrote:

> Hello,
>
> I would like to know if it's possible to configure an interface at
> runtime to enable wol without rebooting my machine.
>
> I tried to create a link file that has WakeOnLan=magic and did
> 'networkctl reconfigure ens0' but it doesn't work.
>

I don't think networkd ever looks at .link files – they are generally
processed only through udev rules, when the interface is created.

Try `udevadm trigger [-c add] /sys/class/net/ens0` though.

If that doesn't help, do it manually via `ethtool -s wol g ens0`.

Also is it possible to display the status of wakeup online with
> 'networkctl status' ?
>

I'd say open a RFE on GitHub issues, although personally I think
`networkctl status` is already a bit overloaded...

-- 
Mantas Mikulėnas


Re: [systemd-devel] Launching script that needs network before suspend

2022-01-31 Thread Mantas Mikulėnas
On Mon, Jan 31, 2022 at 2:01 PM Lennart Poettering 
wrote:

> On So, 23.01.22 22:13, Tomáš Hnyk (tomash...@gmail.com) wrote:
>
> > Hello,
> > I have my computer hooked up to an AVR that runs my home cinema and
> ideally
> > I would like the computer to turn off the AVR when I turn it off or
> suspend
> > it. The only way to do this is over network and I wrote a simple script
> that
> > does just that. Hooking it to shutdown was quite easy using
> network.target
> > that is defined when shutting down.
> >
> >
> > I am struggling to make it work with suspend though. When I look at the
> > logs, terminating network seems to be the first thing that happens when
> > suspend is invoked.
>
> That shouldn't happen. Normally networking shouldn't be shut down
> during suspend. If your network management solution does this
> explicitly, I am puzzled, why it would do that.
>

NetworkManager does that, especially for Wi-Fi; I don't remember the
rationale though. (It uses systemd's delay inhibitors.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Where to put unix sockets while SELinux enforces on init_t?

2022-01-30 Thread Mantas Mikulėnas
On Sun, Jan 30, 2022 at 12:47 AM Daniel Farina  wrote:

> I am using SELinux enforced AlmaLinux, and am wondering where the
> customary place to put a ListenStream directive that is opening a unix
> socket should be.
>
> Old-school customarily, /tmp suffices, but SELinux blocks that: "init_t"
> is not allowed to create the socket there.
>
> Looking through definitions, /var/run/systemd is a place that systemd can
> create unix socket files, and indeed my prototype using this works, but I'm
> not sure if this is where they "belong."
>
> Does anyone have an opinion on this?
>

I'm not familiar with SELinux defaults, but the standard location for
sockets has long been [/var]/run (with /run being the preferred spelling on
Linux nowadays), and currently systemd has already been creating lots of
sockets under /run in general – on my system I see /run/rpcbind.sock,
/run/dmeventd-client, /run/avahi-daemon/socket, all of them created by pid1
through .socket units (see `systemctl list-sockets`) and not by the actual
daemons themselves. This makes me assume that on distros with SELinux, the
default policy would just allow systemd to do that.

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd killing processes on monitor wakeup?

2022-01-30 Thread Mantas Mikulėnas
On Sat, Jan 29, 2022 at 5:29 AM Raman Gupta  wrote:

> Try to set the systemd user instance's log level to 'debug'; I'm guessing
>> it's not that systemd kills processes directly but that something triggers
>> a 'systemctl stop' of the session .scope that they were in.
>
>
> Here are the logs at debug level with some annotations inline:
>
> **
>
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Application
> 'plasmashell' crashing...
> Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Attempting to start
> /usr/libexec/drkonqi
>
> *https://bugs.kde.org/show_bug.cgi?id=396359
> <https://bugs.kde.org/show_bug.cgi?id=396359>, could be related to
> subsequent events but I'm pretty sure I've seen this same problem even when
> Plasma doesn't crash>*
>
> Jan 28 21:57:34 edison systemd[2551]: Got message type=signal
> sender=org.freedesktop.DBus destination=n/a path=/org/freedesktop/DBus
> interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4294967295
> reply_cookie=0 signature=sss error-name=n/a error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: D-Bus
> name org.kde.plasmashell now not owned by anyone.
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Changed
> running -> stop-sigterm
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10389 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a
> destination=n/a
> path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged
> cookie=10390 reply_cookie=0 signature=sa{sv}as error-name=n/a
> error-message=n/a
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3326812
> (idea.sh).
> Jan 28 21:57:34 edison systemd[2551]: Child 3326812 (idea.sh) died
> (code=killed, status=15/TERM)
>
> * died. Not sure why killsnoop.py seems to think that systemd is the process
> that sends the SIGTERM -- it's still unclear to me where IDEA is receiving
> the SIGTERM from>*
>

Processes get SIGCHLD for all children that exit -- it's not suppressed
just because the same process sent a SIGTERM recently.


>
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3326812 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3114994 (kio_http_cache_) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3114994 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Child 3328167 (adb) died
> (code=killed, status=15/TERM)
> Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child
> 3328167 belongs to plasma-plasmashell.service.
> Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3328167
> (n/a).
>
> **
>

Honestly this just sounds like systemd killing "leftover" processes within
the plasma-plasmashell cgroup, after the "main" process of that service has
exited. That's not a bug; that's standard behavior for systemd services.

For special cases like desktop environments, I think this means the
.service should have KillMode=process (as long as that's still supported,
anyway), *or* Plasma should be improved to no longer spawn apps directly
but to put them in new systemd units (like gnome-shell does).

-- 
Mantas Mikulėnas


Re: [systemd-devel] systemd killing processes on monitor wakeup?

2022-01-28 Thread Mantas Mikulėnas
Try to set the systemd user instance's log level to 'debug'; I'm guessing
it's not that systemd kills processes directly but that something triggers
a 'systemctl stop' of the session .scope that they were in.

Can't think of any events directly related to monitor wakeup that systemd
would react to (unless you meant the processes die on full system suspend
that usually follows). Do you have any screensaver running? Do the
processes actually get killed when the monitor goes to sleep or only when
it wakes up?

On Wed, Jan 26, 2022, 15:39 Raman Gupta  wrote:

> Does anyone have any tips for debugging this or getting more information?
> Should I create an issue for this?
>
> On Sun, Jan 23, 2022 at 3:43 PM Raman Gupta  wrote:
>
>> (A variation of this message was originally sent to fedora-users)
>>
>> I have a couple processes that have been consistently dying every time I
>> wake up my monitors after the system has been idle. One is Slack Desktop
>> and the other is IntelliJ IDEA.
>>
>> I used an eBPF program (killsnoop.py at
>> https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py) to trace
>> where the signal to shut down these processes was coming from, and it
>> appears that systemd is sending pretty much every active process signal 15
>> and then 18.
>>
>> TIME  PIDCOMM SIG  TPID   RESULT
>> ... on monitor wakeup ...
>> 12:16:58  2551   systemd  15   2938613 0
>> 12:16:58  2551   systemd  18   2938613 0
>> 12:16:58  2551   systemd  15   2938814 0
>> 12:16:58  2551   systemd  18   2938814 0
>> 12:16:58  2551   systemd  15   2938832 0
>> 12:16:58  2551   systemd  18   2938832 0
>> 12:16:58  2551   systemd  15   2938978 0
>> 12:16:58  2551   systemd  18   2938978 0
>> 12:16:58  2551   systemd  15   2939432 0
>> 12:16:58  2551   systemd  18   2939432 0
>> 12:16:58  2551   systemd  15   2939899 0
>> 12:16:58  2551   systemd  18   2939899 0
>> 12:16:58  2551   systemd  15   2942192 0
>> 12:16:58  2551   systemd  18   2942192 0
>> ...
>>
>> Process 2551 is the PDF of the source of the signal according to
>> killsnoop, 15 and 18 are the signals being sent, and TPID is the target
>> PID, which among many others, does include my dying processes. Process 2551
>> is indeed systemd, specifically the user process:
>>
>> raman   2551   1  0 Jan07 ?00:00:10
>> /usr/lib/systemd/systemd --user
>>
>> This behavior is relatively new. What is going on here? I haven't found
>> any other reports of this behavior anywhere else.
>>
>> I'm using systemd-249.9-1.fc35 on Fedora 35.
>>
>> Regards,
>> Raman
>>
>>


Re: [systemd-devel] [EXT] Re: Q: "systemd[1]: var-tmp-AP_0x6tWaHS.mount: Succeeded."

2022-01-28 Thread Mantas Mikulėnas
On Fri, Jan 28, 2022, 11:59 Ulrich Windl 
wrote:

> >>> Mantas Mikulenas  schrieb am 28.01.2022 um 10:27 in
> Nachricht
> :
> > On Fri, Jan 28, 2022 at 10:50 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> Hi!
> >>
> >> When upgrading SLES15 to SP3, a newer version of systemd was installed
> >> (246.16+suse.191.g3850086c65).
> >> Since then I see new journal messages like these that I cannot associate
> >> with a unit:
> >>
> >> Jan 27 09:29:30 h16 systemd[1]: var-tmp-AP_0xC5KDJP.mount: Succeeded.
> >> Jan 27 09:29:30 h16 systemd[22591]: var-tmp-AP_0xC5KDJP.mount:
> Succeeded.
> >>
> >> Where do these messages originate from, and couldn't they be improved?
> Or
> >> is it some debug-leftover?
> >> I do not see corresponding names in /var/tmp.
> >>
> >
> > If I understand correctly, the messages indicate that the filesystem was
> > *unmounted*, and the same program which did mounting/unmounting
> immediately
> > cleaned up the mountpoint as well.
> >
> > (systemd reacts to external mounts as those also contribute to
> > dependencies.)
> >
> > If OpenSuSE has the kernel audit subsystem enabled, try using `auditctl`
> to
> > monitor a) what process executes mount-related syscalls, b) what process
> > creates directories under /var/tmp.
>
> Thanks,
>
> probably these messages are related to mounting a virtual CD, as nearby are
> these messages:
> Jan 27 09:29:29 h16 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
> Jan 27 09:29:29 h16 kernel: ISO 9660 Extensions: RRIP_1991A
> Jan 27 09:29:30 h16 systemd[1]: var-tmp-AP_0xC5KDJP.mount: Succeeded.
> Jan 27 09:29:30 h16 systemd[22591]: var-tmp-AP_0xC5KDJP.mount: Succeeded.
> Jan 27 09:29:30 h16 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
> Jan 27 09:29:30 h16 kernel: ISO 9660 Extensions: RRIP_1991A
> Jan 27 09:29:31 h16 systemd[22591]: var-tmp-AP_0x6tWaHS.mount: Succeeded.
> Jan 27 09:29:31 h16 systemd[1]: var-tmp-AP_0x6tWaHS.mount: Succeeded.
>
> Still I wonder what this is all about (systemd finding a CD, mounting it,
> just
> to find out that no-one needs it?)...
>

Why do you think systemd is finding and/or mounting it?

>


Re: [systemd-devel] Q: "systemd[1]: var-tmp-AP_0x6tWaHS.mount: Succeeded."

2022-01-28 Thread Mantas Mikulėnas
On Fri, Jan 28, 2022 at 10:50 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> When upgrading SLES15 to SP3, a newer version of systemd was installed
> (246.16+suse.191.g3850086c65).
> Since then I see new journal messages like these that I cannot associate
> with a unit:
>
> Jan 27 09:29:30 h16 systemd[1]: var-tmp-AP_0xC5KDJP.mount: Succeeded.
> Jan 27 09:29:30 h16 systemd[22591]: var-tmp-AP_0xC5KDJP.mount: Succeeded.
>
> Where do these messages originate from, and couldn't they be improved? Or
> is it some debug-leftover?
> I do not see corresponding names in /var/tmp.
>

If I understand correctly, the messages indicate that the filesystem was
*unmounted*, and the same program which did mounting/unmounting immediately
cleaned up the mountpoint as well.

(systemd reacts to external mounts as those also contribute to
dependencies.)

If OpenSuSE has the kernel audit subsystem enabled, try using `auditctl` to
monitor a) what process executes mount-related syscalls, b) what process
creates directories under /var/tmp.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Automatically moving forked processes in a different cgroup based on children's UID

2022-01-09 Thread Mantas Mikulėnas
On Fri, Jan 7, 2022 at 4:11 PM Michal Koutný  wrote:

> More viable way seems to me to modify the apache2-mpm-itk to put
> children into respective cgroups.
>

I'm assuming that the resource usage primarily comes from something like
webapps running via mod_php, rather than Apache itself, in which case a
better approach would be to move the webapps out of apache entirely. At
work we also looked into mpm-itk for a student "shared hosting" server,
but instead ended up with a setup where each user automatically gets their
own PHP-FPM pool (with each vhost configured to talk to their own PHP-FPM
socket), so resource limits could be set either at PHP-FPM level, or if
needed multiple php-fpm@.service instances could be run with their own
cgroups.

-- 
Mantas Mikulėnas


Re: [systemd-devel] How to check watchdog status?

2022-01-07 Thread Mantas Mikulėnas
On Fri, Jan 7, 2022 at 4:56 PM Adam Nielsen  wrote:

> Hi all,
>
> If I have asked systemd to make use of a hardware watchdog by setting
> RuntimeWatchdogSec in systemd.conf, how can I work out whether systemd
> is actually using the hardware watchdog or not?
>
> There is a non-systemd command "wdctl" which queries /dev/watchdog0 and
> tells you things like what the current timeout is set to, however
> on some of my machines this works, but on others it gives an error
> saying /dev/watchdog0 is unavailable.
>
> Some reading suggests only one program can access /dev/watchdog0 at a
> time, so I am not sure whether this means systemd is already using the
> watchdog and that's why wdctl can't access it, or does it mean the
> watchdog hardware isn't working properly?  On the machines where wdctl
> does print details about /dev/watchdog0, does this mean systemd has not
> taken ownership of it, or does that device allow multiple instances of
> the watchdog?
>

Recent versions of util-linux will obtain the information through /sys if
they're unable to open the watchdog device for whatever reason. Older
versions just give up.

Generally, if systemd or something else is actively using the watchdog,
then wdctl will report a "Timeleft" value lower than the total "Timeout" as
it is actively counting down. (If it does report identical values, that
*could* mean systemd just pinged the watchdog, so wait 1-2 seconds and
check again.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists

2022-01-06 Thread Mantas Mikulėnas
On Thu, Jan 6, 2022 at 10:42 AM Harald Dunkel 
wrote:

> On 2022-01-05 21:48:11, Michael Biebl wrote:
> > Am Mi., 5. Jan. 2022 um 13:50 Uhr schrieb Mantas Mikulėnas <
> graw...@gmail.com>:
> >> It does, yes, but note this part:
> >>
> >> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4:
> renamed from eth2
> >> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5:
> renamed from eth3
> >>
> >> Here the kernel-assigned names (eth2, eth3) are being renamed to custom
> names (eth4, eth5). That's not something systemd or udev does by default.
> It suggests that you likely have old "70-persistent-net" udev rules (or
> something similar) that assign custom eth* names separately from the
> slot-based "predictable" naming – perhaps a leftover from Debian 7.
> >>
> >> These interfaces aren't being skipped due to an earlier conflict – they
> are intentionally skipped by 80-net-setup-link.rules because they already
> have a custom 'NAME=' assigned by an earlier rule, so the "predictable"
> name is not applied to avoid breaking existing configuration.
> >
> > Yes, please check if you have a leftover file
> > /etc/udev/rules.d/70-persistent-net.rules
> > See also the relevant NEWS entry in /usr/share/doc/udev/NEWS.Debian.gz
> >
>
> You are right about Debian 7 wrt 70-persistent-net.rules, but for Debian
> 10 I had used net.ifnames=0. It was changed to 1 after(!) the upgrade to
> Debian 11:
>

That's really irrelevant to what I was saying. The net.ifnames= option only
disables the "predictable naming" udev helper; it does nothing about custom
udev rules that directly set NAME= on network interfaces (and are
apparently setting NAME="eth4" on your system).

Grep your entire /etc for those interface names (starting with /etc/udev),
find out where they're defined, and remove them – that should bring the
enp* names back. (Also grep for "eno1" just in case.)

As for 'index' and 'acpi_index' attributes, they're in /sys on the parent
PCI device of the network interface (e.g.
/sys/class/net/eth2/../../{acpi_,}index or
/sys/bus/pci/devices/:02:00.2/{acpi_,}index), another way to see them
is `udevadm info -a /sys/class/net/eth2`.

-- 
Mantas Mikulėnas


Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists

2022-01-05 Thread Mantas Mikulėnas
On Wed, Jan 5, 2022 at 9:46 AM Harald Dunkel 
wrote:

> On 2022-01-04 16:14:16, Andrei Borzenkov wrote:
> >
> > You have two interfaces which export the same onboard interface index.
> > There is not much udev can do here; the only option is to disable
> > onboard interface name policy. The attributes that are used by udev
> > are "acpi_index"  and "index". Check values of these attributes for
> > all interfaces.
> >
>
> I will check, but please note that I didn't enable this. AFAIU Debian
> uses the settings according to the guidelines of upstream.
>
> >
> > As is obvious from the log you provided, they did not "keep" their
> > names but were renamed. Whether this is correct depends on rules your
> > distribution is using.
> >
>
> AFAICS the kernel of today still assigns the "legacy" interface names,
> which are renamed by udev later. I would suggest to improve conflict
>

It does, yes, but note this part:

Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed
from eth2
Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed
from eth3

Here the kernel-assigned names (eth2, eth3) are being renamed to custom
names (eth4, eth5). That's not something systemd or udev does by default.
It suggests that you likely have old "70-persistent-net" udev rules (or
something similar) that assign custom eth* names separately from the
slot-based "predictable" naming – perhaps a leftover from Debian 7.

These interfaces aren't being skipped due to an earlier conflict – they are
intentionally skipped by 80-net-setup-link.rules because they already have
a custom 'NAME=' assigned by an earlier rule, so the "predictable" name is
not applied to avoid breaking existing configuration.

It also makes me wonder whether one of your interfaces might actually have
the "eno1" name assigned manually (through another udev rule) and not
really through the "predictable" naming.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Context for "exitrd"

2021-12-31 Thread Mantas Mikulėnas
On Fri, 31 Dec 2021 at 20:46, Albert Brox  wrote:

> Hi all,
>
> I'm interested in working on this item from the TODO file:
>
> * add concept for "exitrd" as inverse of "initrd", that we can
> transition to at
>shutdown, and has similar security semantics. This should then take
> the place
>of dracut's shutdown logic. Should probably support sysexts too. Care
> needs
>to be taken that the resulting logic ends up in RAM, i.e. is copied
> out of
>on-disk storage.
>
> I'm wondering if anyone can elaborate/give context for this.
> Specifically, what is the motivation for replacing the dracut shutdown
> logic with exitrd? It seems like dracut already handles shutdown
> processes within a ramdisk/fs. And as I understand, initrd is not part
> of systemd (merely interfaced with), so why are we bringing this
> "exitrd" under the umbrella of systemd?


If I remember right, this whole concept of having init pivot_root back into
/run to let root be unmounted (aka "shutdown initramfs") *was* originally
introduced by systemd in the first place.

(Init has to be involved because it's the one process that can't be killed
to relinquish its open handles on /, it has to be nicely asked to do so.
Sysvinit didn't have such a thing as far as I remember, but systemd was
changed in 2011 to optionally pivot_root to /run/initramfs and execute the
'shutdown' binary found there instead of powering off. That's what allows
dracut shutdown logic to be run.)

But while the initramfs is a pre-built image that can be distributed and
signed, the shutdown logic is not; it's instead unpacked or even generated
on the fly by an ordinary .service that runs before every shutdown. At
least on Arch it literally runs mkinitcpio; not sure about dracut.

So I'm assuming that the whole idea of "exitrd" is just to make the same
"initramfs update" process generate both halves as static cpio images at
the same time, so that it would become systemd's job to simply unpack it to
/run (and maybe validate a signature or two).
-- 
Mantas Mikulėnas


Re: [systemd-devel] User authentication service isn't killed fully

2021-12-28 Thread Mantas Mikulėnas
On Tue, Dec 28, 2021, 16:39 beroal  wrote:

> I was not aware of `PAMName`. After reading its documentation, it's still
> not clear to me what it does and how it can be used. What's a PAM session?
> Do you have any references? Google search wasn't very helpful. AFAIK from
> the PAM documentation, session is not an entity, for example, it has no
> identifier. Is it a session stored in logind?
>

It's the abstract thing between pam_open_session() and pam_close_session().
Each module has its own definition of what a session really is –
pam_systemd makes it an entity that exists within systemd-logind,
pam_loginuid makes it an entity that exists within the kernel's audit
subsystem, pam_unix just writes "user foo logged in" to the syslog. I guess
you could call the entire child process tree (including reparented ones)
the session.

What PAMName= does is similar to your program: it initializes PAM with the
provided name, skips pam_authenticate but calls pam_acct_mgmt and
pam_open_session before starting the program. It's often used for
auto-login services.


> I would also like to know how systemd is supposed to handle authentication
> programs that can start a process for any user, not the one in the systemd
> unit file. I posted just a minimal example.


It doesn't get involved in those. If your program starts as root and "logs
in" arbitrary users (like sshd or getty/login or lightdm), then it doesn't
use PAMName= but continues calling PAM directly, like it always has.

>


Re: [systemd-devel] User authentication service isn't killed fully

2021-12-28 Thread Mantas Mikulėnas
On Sun, Dec 26, 2021 at 3:03 PM beroal  wrote:

> Hi. I have an autologin program which authenticates a user without asking
> for a password and starts a child process executing a user shell (for
> example, Bash, Xorg, or a Wayland compositor).
>
> This program is a systemd service. I discovered that systemd kills the
> autologin program, but does not kill the child of the autologin program. As
> I understand from the systemd documentation, systemd should kill both.
>

Systemd doesn't kill *child* processes when stopping a service – it only
kills processes found in the service's cgroup. As pam_systemd has
intentionally moved your processes to a separate per-session .slice cgroup,
they're no longer tied to the original .service's lifetime.

(I'm not very familiar with Wayland's requirements, but does your autologin
program do anything specific that the built-in [Service] PAMName= wouldn't
do anyway?)

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: journal filtering and unit failures

2021-12-27 Thread Mantas Mikulėnas
On Mon, Dec 27, 2021 at 11:26 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> debugging a problem I found out some surprising fact:
> When filtering the journal with "journalctl -b
> _SYSTEMD_UNIT=logrotate.service", I see an error only once, like this:
> -- Logs begin at Mon 2020-11-30 11:35:08 CET, end at Mon 2021-12-27
> 10:19:31 CET. --
> Dec 18 00:00:20 h16 logrotate[41799]: Failed to kill unit
> \x7b__SERVICE__\x7d.service: Unit \x7b__SERVICE__\x7d.s...
> Dec 18 00:00:20 h16 logrotate[41799]: error: error running shared
> postrotate script for '/var/log/iotwatch/MD10/...
>
> However when inspecting the full journal I also see:
> Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Main process exited,
> code=exited, status=1/FAILURE
> Dec 18 00:00:20 h16 systemd[1]: Failed to start Rotate log files.
> Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Unit entered failed
> state.
> Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Failed with result
> 'exit-code'.
>
> Actually I am surprised that those unit-related messages are not covered
> by the filter.
>

They're not generated **by** a process within logrotate.service, and
journald does not allow a (fake) _SYSTEMD_UNIT to be set – not even if the
sender is pid1. The same also applies to messages logged by
systemd-coredump.


> Is there a better way to get such related messages when filtering?
>

Use `journalctl -u logrotate`, which combines several filters to get all
messages related to the specified unit.

The actual filtering used by -u (as seen with SYSTEMD_LOG_LEVEL=debug) is a
union of four filters – the equivalent command would be:

journalctl _SYSTEMD_UNIT=logrotate.service \
  + MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
_UID=0 COREDUMP_UNIT=logrotate.service \
  + _PID=1 UNIT=logrotate.service \
  + _UID=0 OBJECT_SYSTEMD_UNIT=logrotate.service

The fourth is a generic filter (any process running as root can specify
OBJECT_SYSTEMD_UNIT=) which I think came a bit later than the special-case
pid1 and coredump ones.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: journal logging and "{xyz}"

2021-12-27 Thread Mantas Mikulėnas
On Mon, Dec 27, 2021 at 10:53 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I just noticed that systemctl kill logs a (mis-named) service
> "{__SERVICE__}" as "\x7b__SERVICE__\x7d.service".
> Is that intended? Are braces considered bad?
>

As per systemd.unit(5),

*Valid unit names consist of a "name prefix" and a dot and a suffix
specifying the unit type. The "unit prefix" must consist of one or more
valid characters (ASCII letters, digits, ":", "-", "_", ".", and "\").*

Anything else goes through C-style escaping (see systemd-escape) before it
even leaves systemctl.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [systemd-networkd] Can use IPv6SendRA and IPv6AcceptRA in a same .network file

2021-12-12 Thread Mantas Mikulėnas
Hmm, I don't understand why you need to send RAs on eth0, if that's the
connection to your VPS provider?

On Sun, Dec 12, 2021 at 5:17 AM jackyzy823  wrote:

> Dear developers.
>
> I have a question about if i can use IPv6SendRA and IPv6AcceptRA in a same
> .network file.
>
> Here's the situation. My VPS provider offers an IPv6 /64 prefix for my
> machine.
>
> I can achieve SLAAC via radvd + systemd-networkd using following config.
>
>
> /etc/radvd.conf
> ```
> interface eth0
> {
> AdvSendAdvert on;
> MinRtrAdvInterval 30;
> MaxRtrAdvInterval 100;
> prefix ::/64
> {
> AdvOnLink on;
> AdvAutonomous on;
> AdvRouterAddr off;
> };
> RDNSS  
> {
> };
> };
>
> ```
>
> /etc/systemd/network/eth0.network
> ```
> [Match]
> Name=eth0
>
> [Network]
> IPv6AcceptRA=yes
> Gateway=fe80::1
>
> ...other ipv4 config
>
> ```
>
>
> However, i found that systemd-networkd have IPv6SendRA options, so i tried
> to do all things in systemd-networkd , but it failed to get an IPv6 address.
>
> here's my config
> /etc/systemd/network/eth0.network
> ```
> [Match]
> Name=eth0
>
> [Network]
> IPv6AcceptRA=yes
> IPv6SendRA=yes
> Gateway=fe80::1
>
>
> [IPv6SendRA]
> DNS=
> DNSLifetimeSec=100
>
> [IPv6PRefix]
> Prefix=
>
> ```
>
> I also tried adding RouterLifetimeSec=0 to [IPv6SendRA] section but it
> still failed to get an IPv6 address.
>
> I did a tcpdump : `tcpdump - -n -i any icmp6`. and i can see `router
> solicitation` and `router advertisement` messages.
>
> So is my configuration wrong ,or does systemd-networkd  support this kind
> of operation ?
>
> Systemd version
> `
> systemctl --version
> systemd 249 (249.7-2-arch)
> +PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS
> +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD
> +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4
> +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified
> `
>
> Thanks.
>
> Best regards,
> Jack
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] Run reboot as normal user

2021-11-30 Thread Mantas Mikulėnas
On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha <
fodha.mohamed@gmail.com> wrote:

> Hello,
>
> I want to run reboot as normal user using the following command:
> dbus-send --system --print-reply --reply-timeout=2000 --type=method_call
> --dest=org.freedesktop.login1 /org/freedesktop/login1
> org.freedesktop.login1.Manager.Reboot boolean:false
>
> but I got a Permission denied error.
>
> I checked that verify_shutdown_creds (in logind-dbus.c) calls
> bus_verify_polkit_async, could it be the reason why I got permission denied
> error while polkit is not installed?
>

Yes. Polkit is the authorization system that decides whether to allow
normal users to do privileged actions or not.


> I don't want to use Polkit or sudo, is there any solution ?
>

No.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

2021-11-16 Thread Mantas Mikulėnas
Most of this looks like it could be done with systemd-networkd to create a
bond .netdev, with a small oneshot service for i2c. (What's the exact
criteria for when it should be run? Does it depend on bond0 being there,
does it need to be last, etc?)

On Tue, Nov 16, 2021, 02:58 Brian Hutchinson  wrote:

> Hi,
>
> I'm on a IMX8 platform and have a Microchip KSZ9567 Ethernet switch.  I
> can use IP commands to manually bring lan1 and lan2 interfaces up and then
> create a redundant/failover bond ... but I'm having difficulty figuring out
> how to do this the "systemd" way.
>
> My first attempt was to just have systemd run a script of all the commands
> I do manually but during system startup there appears to be race conditions
> so I have to set my service type to "Idle" and sometimes even that doesn't
> work. So I want to exploit any systemd support for DSA and bonding.
>
> Here is script my manual steps which is what I want systemd to ultimately
> do:
>
> #!/bin/bash
>
> # Create a redundant bond between ksz9567 DSA lan1 and lan2 interfaces
>
> # Load bonding kernel module
> modprobe bonding
>
> # Bring up CPU interface (cpu to switch port 7 - the RGMII link)
> ip link set eth0 up
>
> # Create a bond
> echo +bond0 > /sys/class/net/bonding_masters
>
> # Set mode to active-backup (redundancy failover)
> echo active-backup > /sys/class/net/bond0/bonding/mode
>
> # Set time it takes (in ms) for slave to move when a link goes down
> echo 1000 > /sys/class/net/bond0/bonding/miimon
>
> # Add slaves to bond
>
> echo +lan1 > /sys/class/net/bond0/bonding/slaves
> echo +lan2 > /sys/class/net/bond0/bonding/slaves
>
> # Set IP and netmask of the bond
> ip addr add 192.168.0.4/24 dev bond0
>
> # And bring bond up.  Pings and network connectivity should work now
> ip link set bond0 up
>
> # For a board that doesn't have Ethernet switch hardware strapped to
> enable at boot .. enable it now
> i2cset -f -y 0 0x5f 0x03 0x00 0x01 i
>
> Thanks for any information, pointers etc.
>
> Regards,
>
> Brian
>


Re: [systemd-devel] 回复: Is it possible to send a string to the journal of one specific systemd unit

2021-10-22 Thread Mantas Mikulėnas
This option was added with util-linux v2.25 in 2014. If you're using an
older version or the Busybox `logger` instead, well, it won't have that.

The alternative is to write your own C tool that uses libsystemd and calls
sd_journal_send
<https://manpages.debian.org/testing/libsystemd-dev/sd_journal_send.3.en.html>()
with the correct fields (libsystemd is definitely going to be present), or
a Python tool that uses systemd.journal.send(). (Or maybe call libsystemd
through python ctypes or whatever other FFI mechanism is available.)



On Fri, Oct 22, 2021 at 4:32 PM DHAIY DHAIY  wrote:

> Thanks a lot Mantas.
> But in my sytem, logger does not have "--journal".
> Are you aware of other tools from bash which can be used?
>
> BR
> ------
> *发件人:* Mantas Mikulėnas 
> *发送时间:* 2021年10月22日 18:45
> *收件人:* DHAIY DHAIY 
> *抄送:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Re: [systemd-devel] 回复: Is it possible to send a string to the
> journal of one specific systemd unit
>
> If you have root privileges (i.e. UID 0), then yes, you can send a journal
> message with the "OBJECT_SYSTEMD_UNIT=myservice.service" field and
> journalctl will automatically look for that.
>
> In C, specify the field when calling sd_journal_sendv(); in bash you can
> use `logger --journal`:
>
> (echo "OBJECT_SYSTEMD_UNIT=sshd.service";
>  echo "MESSAGE=Hello world!") | sudo logger --journal
>
> On Fri, Oct 22, 2021 at 11:43 AM DHAIY DHAIY  wrote:
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
> --
> *发件人:* DHAIY DHAIY
> *发送时间:* 2021年10月22日 16:40
> *收件人:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Is it possible to send a string to the journal of one specific
> systemd unit
>
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
>
>
> --
> Mantas Mikulėnas
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] 回复: Is it possible to send a string to the journal of one specific systemd unit

2021-10-22 Thread Mantas Mikulėnas
If you have root privileges (i.e. UID 0), then yes, you can send a journal
message with the "OBJECT_SYSTEMD_UNIT=myservice.service" field and
journalctl will automatically look for that.

In C, specify the field when calling sd_journal_sendv(); in bash you can
use `logger --journal`:

(echo "OBJECT_SYSTEMD_UNIT=sshd.service";
 echo "MESSAGE=Hello world!") | sudo logger --journal

On Fri, Oct 22, 2021 at 11:43 AM DHAIY DHAIY  wrote:

> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
> --
> *发件人:* DHAIY DHAIY
> *发送时间:* 2021年10月22日 16:40
> *收件人:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Is it possible to send a string to the journal of one specific
> systemd unit
>
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] D-feet displays an error message when using sd-bus

2021-10-19 Thread Mantas Mikulėnas
On Tue, Oct 19, 2021, 18:29 yves baumes  wrote:

> Hello,
>
> First I am not sure it is the correct place to ask questions about lib
> sd-bus. Is it? Here is my issues:
>
> I am trying to use the lib sd-bus, following this blog post:
> http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html .
>
> I am able to launch my own service on the *user* bus.
> When I launch it on the *system* bus, problems appear.
> First I had a permission denied issue, and to correct it I had to create a
> configuration file in /etc/dbus-1/system.d/net.poettering.Calculator.conf .
> As stated in
> https://stackoverflow.com/questions/32828468/sd-bus-api-sd-bus-request-name-returns-permission-denied
> .
> Thus the executable launches perfectly (no more 'permission denied'
> errors).
>

This is normal as the system bus is "deny everything by default", to make
sure unprivileged users can't impersonate a service.


> Now I am trying to inspect the service with D-feet. The service is well
> listed on the left pane: net.poettering.Calculator, but when I click on it,
> I get an error window stating :
> 'net.poettering.Calculator: g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message,
> 1 matched rules; type="method_call", sender=":-1.1996" (uid=1000
> pid=3110822 comm="/usr/bin/python3 /usr/bin/d-feet" label"unconfined")
> interface="org.freedesktop.DBus.Introspectable" member="Introspect" error
> name ="(unset)" requested_reply="0" destination=net.poettering.Calculator"
> (uid=0 pid=3110595 comm="./-bus-service" label="unconfined")(9)' .
>

This also means you need to allow things in the dbus-daemon policy. Not
only does the service need permissions to claim a name, but everyone also
needs permissions to send it messages (and receive replies).

In many cases you can copy a basic policy that just allows everything from
any UID to your service (possibly still limited by interface), like how
UDisks2.conf does it.


Re: [systemd-devel] PIDFile creation logic

2021-10-19 Thread Mantas Mikulėnas
On Tue, Oct 19, 2021, 08:45 Andrei Borzenkov  wrote:

> On 18.10.2021 23:08, Silvio Knizek wrote:
> > Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
> >> I just installed the new-to-EPEL ndppd service and am seeing this in my
> log:
> >>
> >> Oct 17 21:10:08 saruman systemd: Can't open PID file
> >> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
> >>
>
> That is just an information. May be it could be downgraded to debug, at
> least initially.
>
> >> Examining the source, I see that the pidfile is created by the child
> >> process, not the parent. I'm guessing that systemd is expecting the
> pidfile
> >> to exist when the parent exits? (I want to file the issue on the
> upstream
> >> program and want to make sure I understand how this should work.)
> >>
> >> Source in question. Note how daemonize() forks and exits and main()
> invokes
> >> daemonize and then creates the pidfile. I'm thinking that daemonize()
> >> should create the pidfile before it invokes exit().
> >>
> >> 
> >>
> > Hi,
> >
> > just don't demonize and don't use a PIDFile= at all. systemd is
> > actually quite apt in figuring out which process is the right main one.
>
> It is not about "main process". It is about notifying systemd that your
> service is ready and systemd can proceed with After dependencies.
> Without PIDFile your service is "ready" as soon as it forked. This most
> likely is not correct.
>

Not quite as soon as it forked, but as soon as the parent exits.

This doesn't depend on pidfiles, and in general seems to be something that
services get right more often than pidfile creation. Initialize, fork, exit
in parent.


Re: [systemd-devel] firmware times reported were incorrect.

2021-10-13 Thread Mantas Mikulėnas
Looks like boot-timestamps.c first tries to read the ACPI FPDT table (it
seems acpi-fpdt.c uses the "OS Loader StartImage Start" and
"ExitBootServices Exit" fields), but if that's unavailable, then it uses
timestamps stored by systemd-boot in EFI variables
(/sys/firmware/efi/efivars/LoaderTime*). The latter seems to be estimating
it from RDTSC (src/boot/efi/util.c).

On Wed, Oct 13, 2021 at 3:05 PM jiansong Xu  wrote:

> *This is bios from oracle, we noticed that the firmware times reported
> were incorrect.*
>
> *Startup finished in** 59min 7.944s** (firmware) + 33.051s (loader) +
> 4.428s*
> *(kernel) + 1min 18.870s (initrd) + 44.494s (userspace) = 1h 1min 48.789s*
>
>
>
> *May I ask what is the source of the **firmware** ?  is it read from acpi
> table? *
>
>
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] Prefix for direct logging

2021-09-28 Thread Mantas Mikulėnas
On Tue, Sep 28, 2021, 06:07 Arjun D R  wrote:

> Thank you Mantas for the details.
> How do you currently get the logs "every few seconds"?
> > Actually we have a script that will be triggered every 10 seconds. That
> script will run "journalctl -u " and redirect the output to the
> respective log file. We will run journalctl for around 40-50 services for
> every 10 seconds and redirect it to the respective log files. That may be a
> bad idea, but this is how we are collecting logs as of now. We need to
> separate the logs for every service and that's why we ended up with this
> implementation.
>

So replace it with 40-50 instances of continuously running `[stdbuf -o0]
journalctl -f -u `.

Although syslogd might be easier, since then you'd only need one process
doing the monitoring. (I know both syslogds can access journal fields like
_SYSTEMD_UNIT, but I don't know how, so usually I just filter by the
traditional "program name" and it does the job.)

You could also have a custom daemon that reads from `journalctl -f -o json`
and writes to the appropriate text log...


>
> Ah, ok so StandardOutput:file: will allow the service to open
> the fd and directly connect it to the service stdout.
>

Yes, so if you want timestamps they have to be provided by your service,
pretty much like how most services implement direct logging to files.
(Probably the only advantage of StandardOutput is that the service doesn't
need permissions to /var/log...)

>


Re: [systemd-devel] Prefix for direct logging

2021-09-27 Thread Mantas Mikulėnas
On Mon, Sep 27, 2021 at 1:11 PM Arjun D R  wrote:

> Hi Folks,
>
> Currently we are using systemd-journald for service logging. We run
> journalctl for a bunch of services and redirect those to the custom log
> files for every few seconds. This takes up the CPU for that particular
> time period since we have lot of IO operations as well. We came to know
> that systemd version v236+ supports direct logging
> (StandardOutput:file:) to the custom log file by the service. I
> would like to use that facility but we don't get the prefix that we used to
> get when using the journal.
>
> Is there a way to prepare a custom patch locally to add the necessary
> prefix to the stdout before writing to the custom log file? Is that a good
> idea? Any other suggestions?
>

Probably not easily, as it's not systemd that is writing to the log file –
it's your service process itself that directly gets a FD for the log file
as its stdout. It's not specifically a "direct logging" feature, but rather
just an equivalent to `myservice > log_file`.

How do you currently get the logs "every few seconds"? Instead of repeated
grabbing, have you tried using `journalctl --follow` to monitor logs
continuously? This should use far less I/O than repeated `journalctl |
tail` which is what it sounds like you're doing. (Wrap in `stdbuf -o0` if
necessary.)

Alternatively, set up the traditional rsyslogd or syslog-ng – writing to
custom log files is basically what they *do*, and both of them are capable
of receiving logs from journald (either by directly monitoring .journal
files or by having the messages forwarded via socket).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Mantas Mikulėnas
On Sun, Sep 19, 2021 at 4:48 PM Ed Greshko  wrote:

> On 19/09/2021 21:39, Michael Biebl wrote:
>
> A useful command in this context is
>
> systemctl --user show-environment
>
>
> OK, that was helpful.  But leads to another question.
>
> How to run the service only if KDE_FULL_SESSION=true?
>

To be sure, do you mean "if" or "when"?

You could check using [Unit] ConditionEnvironment=, sure, but if the actual
problem is that the unit is started too early, this won't help -- it won't
actually get delayed "until KDE_FULL_SESSION becomes true", it just won't
be run at all.

You said that the service runs at the login screen -- I'm not sure how this
can happen if your service is installed into plasma-core.target.wants/ (and
*not* in default.target.wants nor basic.target.wants)...

-- 
Mantas Mikulėnas


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Mantas Mikulėnas
On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko  wrote:

> Not a everyday systemd service writer
>
> I've written a user service file to start an app on login.  It works well
> for Xorg with Environment=DISPLAY=:0.
>
> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg
> and login to a
> Wayland session.
>
> What would be the proper way to get the DISPLAY environment varible use it
> as opposed
> to "hard" coding it?
>

The proper way is to have *the desktop environment* upload DISPLAY (and
whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or
XDG_SESSION_TYPE) into systemd --user, so that it would be automatically
available to your service *without *doing anything special.

For example, gnome-session does this for GNOME (it calls systemd's
UnsetAndSetEnvironment in gsm-util.c), and
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for
other Xorg-based desktops (when startx is used).

If KDE integrates with systemd --user in any way (i.e. if it actually has a
"plasma-core.target" that you mention), I'd really expect it to do the same
before it tries to start its own targets, otherwise they would be kind of
useless.

-- 
Mantas Mikulėnas


Re: [systemd-devel] when mount is delayed - start unit which depends on it - ?

2021-09-18 Thread Mantas Mikulėnas
On Fri, Sep 17, 2021 at 2:40 PM lejeczek  wrote:

> Hi guys.
>
> I'm trying to have unit to start...
> well,
> I have a luks device which waits for manual passphrase
> input, when that happens 'systemd' mounts, without user
> intervention(which is great), that luks device.
> fstab:
> /dev/mapper/luks.devs /devs   ext4
> noatime,nobarrier,noatime,x-systemd.device-timeout=2,nofail 1 2
> and now I'll have many units/services which depend on that
> mount, because they need to get to paths to get their
> configs & other bits.
>
> Question - how do I make such a unit to re/start when
> 'systemd' does the mount? Naturally, ideally without any
> ways external to 'systemd'.
>

If units need this mount, then *actually* make them depend on this mount –
as in, "Requires=devs.mount" and "After=devs.mount" in each service's
[Unit].

-- 
Mantas Mikulėnas


Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages

2021-09-13 Thread Mantas Mikulėnas
On Tue, Sep 14, 2021 at 4:08 AM Ryan McClue 
wrote:

> I understand this is slightly off-topic, but I'm completely new to BPF.
> Analyzing libudev source and Internet I understand the general idea.
> However, I don't understand how information/what information is passed to
> the filter from the socket. For example, in my case the socket payload,
> i.e. buf_str =
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14*
> 1. How do I pass this string to the *sock_filter/sock_fprog* structures?
>

As far as I know – you don't. Once you attach the filter to the socket, it
automatically gets invoked with each packet's payload as the input
(whatever counts as "input" for BPF, I'm not entirely sure), and you don't
need to pass anything anywhere manually.

Note that this is not eBPF but the traditional cBPF that's used e.g. by
tcpdump/libpcap.


> 2. Is a correct way of filtering these to implement string parsing to
> check for '/event' sub-string in EPF bytecode?
>

See sd_device_monitor_filter_update() in
src/libsystemd/sd-device/device-monitor.c (nowadays, sd-device has all the
interesting code, while libudev is a thin wrapper around it).

-- 
Mantas Mikulėnas


  1   2   3   4   5   6   7   8   9   10   >