[systemd-devel] Antw: Re: Antw: [EXT] [systemd‑devel] Why is using fstab the preferred approach according to systemd.mount man page?

[Ulrich Windl]

>>> Thomas HUMMEL  schrieb am 07.02.2022 um 18:36 in
Nachricht <3aa03772-1981-eea4-ecd2-c50b9c0d0...@pasteur.fr>:

> 
> On 10/01/2022 21:50, Zbigniew Jędrzejewski-Szmek wrote:
> 
>> Pretty much. There isn't any big benefit to using mount units (since the
>> fstab syntax supports all the important use cases), and people are
familiar
>> with fstab. More tools support it too.
> 
> Hello,
> 
> well although I'm not currently using it, I can see one :
> 
> it may be easier to configure .mount units independently (like dropping 
> a config file into a .d/ directory) instead of editing one single file 
> when done with tools like ansible for instance where you have to regexp 
> match lines to edit or use blockinfile like strategies ?

Amazingly that seems to be one case where a human has less problems (adding or
changing a line in /etc/fstab) than tools do.
Maybe that's the true state of artificial intelligence...
For a human mount units are much more complicated (IMHO).

Regards,
Ulrich

> 
> Thanks
> 
> --
> Thomas HUMMEL

Re: [systemd-devel] Odd behaviour on boot

[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

[Tomasz Torcz]

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.

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen

Re: [systemd-devel] Odd behaviour on boot

[Wols Lists]

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.


Basically, ScarletDME is an old fashioned daemon - a database backend. 
So you start it off as super-user with a --start option, it forks and 
backgrounds itself. Because the service file did not contain 
"Type=forking", systemd promptly ran the --stop option. Which for some 
reason started killing everything left right and centre!


I didn't notice it before because I wrote although I wrote the .service 
file, I didn't add the ExecStop. It was only when my system crashed and 
rebooted with the updated service file that things went wrong ... big 
time :-)


(And of course, as a database background daemon, it doesn't normally get 
shut down unless the system gets shut down.)


Cheers,
Wol

Re: [systemd-devel] Odd behaviour on boot

[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  > > 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...
> >
> 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...
> 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 

Re: [systemd-devel] Odd behaviour on boot

[Wols Lists]

On 07/02/2022 14:06, Mantas Mikulėnas wrote:
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...



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).
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).
Feb 07 07:55:10 thewolery systemd[1]: systemd-journald.service: 
Scheduled restart job, restart counter is at 1.

Feb 07 07:55:10 thewolery systemd[1]: Stopped Journal Service.
Feb 07 07:55:10 thewolery systemd[1]: Starting Journal Service...
Feb 07 07:55:10 thewolery systemd-journald[1539]: Journal started
Feb 07 07:55:10 thewolery systemd-journald[1539]: System Journal 
(/var/log/journal/053db4036a25efc6f8d2186a603c3f79) is 768.4M, m>Feb 07 
07:55:09 thewolery systemd[1]: dbus.service: Deactivated 

Re: [systemd-devel] Antw: [EXT] [systemd‑devel] Why is using fstab the preferred approach according to systemd.mount man page?

[Thomas HUMMEL]

On 10/01/2022 21:50, Zbigniew Jędrzejewski-Szmek wrote:


Pretty much. There isn't any big benefit to using mount units (since the
fstab syntax supports all the important use cases), and people are familiar
with fstab. More tools support it too.


Hello,

well although I'm not currently using it, I can see one :

it may be easier to configure .mount units independently (like dropping 
a config file into a .d/ directory) instead of editing one single file 
when done with tools like ansible for instance where you have to regexp 
match lines to edit or use blockinfile like strategies ?


Thanks

--
Thomas HUMMEL

Re: [systemd-devel] Failed to add PIDs to scope's control group: No such process

[Gena Makhomed]

On 03.02.2022 18:39, Gena Makhomed wrote:


Periodically I see in /var/log/messages error message about

Failed to add PIDs to scope's control group: No such process
Failed with result 'resources'.

How I can resolve or workaround this error?

# rpm -q systemd
systemd-239-51.el8_5.3.x86_64

# cat /var/log/messages
Feb  3 18:13:36 server systemd-logind[2981]: New session 14287 of user 
root.
Feb  3 18:14:26 server systemd[1]: Started User runtime directory 
/run/user/0.

Feb  3 18:14:26 server systemd[1]: Starting User Manager for UID 0...
Feb  3 18:14:28 server systemd[1]: Started User Manager for UID 0.
Feb  3 18:14:28 server systemd[1]: session-14287.scope: Failed to add 
PIDs to scope's control group: No such process
Feb  3 18:14:28 server systemd[1]: session-14287.scope: Failed with 
result 'resources'.


I found workaround for this issue:

# loginctl show-user root | grep Linger
Linger=no

# loginctl enable-linger root

# loginctl show-user root | grep Linger
Linger=yes

After enabling linger - no more such errors in /var/log/messages

--
Best regards,
 Gena

Re: [systemd-devel] Odd behaviour on boot

[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

[systemd-devel] Odd behaviour on boot

[Wols Lists]

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.


Cheers,
Wol

Re: [systemd-devel] Strange behavior of socket activation units

[Lennart Poettering]

On Mo, 07.02.22 09:01, Tuukka Pasanen (pasanen.tuu...@gmail.com) wrote:

> Hello,
> I have encountered this kind of problem. This particularly is MariaDB 10.6
> installation to Debian.
> Nearly every application that is restarted/started dies on:
>
>
> Failed to get properties: Unit name mariadb-extra@.socket is missing the
> instance name.
> Failed to get properties: Unit name mariadb@.socket is missing the instance
> name.
>
>
> This is kind of strange as those are for multi target version and should not
> be launched if I don't have mariadb@something.service added or make
> specified systemctl enable mariadb@something.socker which I haven't.
> They don't show up in dependencies of mariadb.service or other service file?

My educated guess is that some script specific to mariadb in debian
assumes that you only run templated instances of mariadb, and if you
don#t things break. Plese work with the mariadb people at Debian to
figure this out, there's nothing much we can do from systemd upstream
about that.

Lennart

--
Lennart Poettering, Berlin