Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts

2021-01-04 Thread Phillip Susi 


Reindl Harald writes:

> i have seen "user manager" instances hanging for way too long and way 
> more than 3 minutes over the last 10 years

The default timeout is 3 minutes iirc, so at that point it should be
forcibly killed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts

2021-01-04 Thread Phillip Susi 


Reindl Harald writes:

> topic missed - it makes no difference if it can hold the power 3 
> minutes, 3 hours or even 3 days at the point where it decides "i need to 
> shutdown everything because the battery goes empty"

It is that point that really should be at least 3 minutes before power
fails.  As long as the battery lasts for at least 3 minutes, then the
monitoring daemon should easily be able to begin the shutdown when 3
minutes remain.

I'm not sure that forcibly killing services to quickly shut down is
really much better than the sudden power loss you are trying to avoid.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timesyncd on systems without battery

2021-01-04 Thread Lennart Poettering 
On So, 03.01.21 10:39, Dan Tihelka (dtihe...@gmail.com) wrote:

> Hello,
> I run systemd on a NAS without internal-clock-holding battery, so I think that
> the systemd-timesyncd sets the time to the last known value after restart and
> syncs it from the network when on-line. Is it right?

Yes.

> Now, I have a shutdown timer unit, which powers the NAS off at the given time.
> However, sometimes (about 50% of cases), when the device is powerd-on, it
> switches off immediately. When switched-on again, it boots as
> expected.

Why does it do so, because the clock is incorrectly set?

> The question is, is there a way of fixing the issue? I have tried to add sleep
> to skip to the next minute, but unsuccessfully.

Two options:

1. Consider explcitly ordering your timer unit after
   "time-set.target". (This will be done implicitly starting with the
   upcoming release of systemd, see
   fe934b42e480473afba8a29a4a0d3d0e789543ac). THis effectively means
   timesyncd has to finish initialization before the timer is
   started, and that in turn means the clock is roughly monotonic for
   all calculations of the calendar time of the timer unit.

2. Consider enabling "systemd-time-wait-sync.service", which is a
   small service that blocks until the clock is synchronized. Calendar
   based timer units are implicitly ordered after it, once
   enabled. This means the timers will only start once the clock is
   synced to some network reference clock. This is a much stronger
   option, but means the boot process will be delayed based on network
   availability.

Coincidentally we documented this recently in more detail, see git
commit b149d230ea23c14bac2dfe79c47e58782623200f which also will be in
the next release.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] require a system service unit to start a user service as a dependency

2021-01-04 Thread Lennart Poettering 
On Do, 24.12.20 05:38, John (gray...@archlinux.us) wrote:

> On Thu, Dec 24, 2020 at 3:29 AM Andrei Borzenkov  wrote:
> >
> > On Thu, Dec 24, 2020 at 5:48 AM John  wrote:
> > >
> > > I need to have the following start
> > > /usr/lib/systemd/user/pulseaudio.service so it can make use of
> > > pulseaudio.  Using a After= or Wants= does not work.  What is the
> > > correct way to have a system service like this run a user service
> > > unit?
> > >
> >
> > No, that's not possible. PA also supports system service, if this is a
> > kiosk system, maybe you can use it instead.
>
> Thank you for the reply.  There are security risks running pulseaudio
> in system mode[1].

Well, but what you are doing is worse, you reverse the layers of the
stack...

If you want a system service that shall use PA, then PA should be a
system service too.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] require a system service unit to start a user service as a dependency

2021-01-04 Thread Lennart Poettering 
On Mi, 23.12.20 21:47, John (gray...@archlinux.us) wrote:

> I need to have the following start
> /usr/lib/systemd/user/pulseaudio.service so it can make use of
> pulseaudio.  Using a After= or Wants= does not work.  What is the
> correct way to have a system service like this run a user service
> unit?
>
> % cat /usr/lib/systemd/system/kodi.service
> [Unit]
> Description=Kodi standalone (GBM)
> After=remote-fs.target network-online.target nss-lookup.target
> sound.target bluetooth.target polkit.service upower.service
> mysqld.service
> Wants=network-online.target polkit.service upower.service
> Conflicts=getty@tty1.service
>
> [Service]
> User=kodi
> Group=kodi
> EnvironmentFile=-/etc/conf.d/kodi-standalone
> TTYPath=/dev/tty1
> Environment=WINDOWING=gbm
> ExecStart=/usr/bin/kodi-standalone
> ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-gbm
> Restart=on-abort
> StandardInput=tty
> StandardOutput=journal
>
> [Install]
> Alias=display-manager.service

This is not a supported setup. System services should not be clients
to per-user services. The opposite is OK, but you are reversing your
stack here...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Failed unmounting /etc/machine-id

2021-01-04 Thread Lennart Poettering 
On Do, 24.12.20 11:27, Mohamed Ali Fodha (fodha.mohamed@gmail.com) wrote:

> Hello,
>
> I have unmounting issues during reboot as mentioned below for
> */etc/machine-id*
> and */etc*, what could be the problem?
> For information, after the boot I got an ID in /etc/machine-id

Most likely something has that file open still.

Maybe turn on debug logging ("systemd-analyze log-level debug") and
check logs on next boot, and check what the precise error was.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts

2021-01-04 Thread Ulrich Windl 
>>> Reindl Harald  schrieb am 04.01.2021 um 14:53 in
Nachricht <49b8413f-3131-658f-e21a-a1ee448a0...@thelounge.net>:

> 
> Am 04.01.21 um 13:42 schrieb Ulrich Windl:
> Germano Massullo  schrieb am 27.12.2020 um
>> 14:26 in
>> Nachricht :
>>> Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
>>> package maintainers on Fedora/CentOS/RHEL.
>>> After a power failure, apcupsd shuts down the system with a command
>>> almost identical to
>>> shutdown ‑h ‑H now
>>> Usually when you normally shutdown your system, you may notice certain
>>> services taking too much time to terminate and triggering a timeout
>>> value before systemd forces them to terminate. I would like to ask if
>>> there is a way to force the system to shutdown without waiting for these
>>> timeouts in case an emergency like a power failure.
>> 
>> Basically if the UPS cannot provide power for at least 3 minutes, it's 
> simply
>> the wrong UPS (IMHO)
> 
> topic missed - it makes no difference if it can hold the power 3 
> minutes, 3 hours or even 3 days at the point where it decides "i need to 
> shutdown everything because the battery goes empty"

Harald,

I did not say anything against shutting down everything. Maybe re-read.

Ulrich





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts

2021-01-04 Thread Reindl Harald 



Am 04.01.21 um 13:42 schrieb Ulrich Windl:

Germano Massullo  schrieb am 27.12.2020 um

14:26 in
Nachricht :

Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
package maintainers on Fedora/CentOS/RHEL.
After a power failure, apcupsd shuts down the system with a command
almost identical to
shutdown ‑h ‑H now
Usually when you normally shutdown your system, you may notice certain
services taking too much time to terminate and triggering a timeout
value before systemd forces them to terminate. I would like to ask if
there is a way to force the system to shutdown without waiting for these
timeouts in case an emergency like a power failure.


Basically if the UPS cannot provide power for at least 3 minutes, it's simply
the wrong UPS (IMHO)


topic missed - it makes no difference if it can hold the power 3 
minutes, 3 hours or even 3 days at the point where it decides "i need to 
shutdown everything because the battery goes empty"

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] log_assert_failed_realm crash in systemd journal-file

2021-01-04 Thread Aditya Tayade 
Hi Lennart,

Apology for the late reply and wish you happy new year!

We are using Yocto 3.1 dunfell with systemd v244-stable on arm64.

Let me know if any other additional information is needed, I am happy to
share.


Regards,
Aditya Tayade

On Mon, Dec 21, 2020 at 8:53 PM Lennart Poettering 
wrote:

> On Do, 17.12.20 13:20, Aditya Tayade (adityadtay...@gmail.com) wrote:
>
> > Hi,
> >
> > I am getting below crash in our CI environment with systemd v244-stable
> > which looks similar to issue #14943
> > . So could you please
> > confirm if it is the same issue and whether the PR:
> > https://github.com/systemd/systemd/pull/15557 (already merged in v246)
> will
> > fix this? If yes then we need back port of these PR to v244-stable as
> well
> > and if not then could you please help to understand what can be cause of
> > this?:
>
> 15557 is the supposed fix for 14943. That I can confirm. if it fixes
> your specific issue I don't know, since I do not have access to your
> platform.
>
> The question you are asking cannot reasonably answered, in particular
> without any informaiton about used distro/arch/… and all those things.
>
> Either way, I'd recommend you to try it out and see if it fixes your
> CI problems? That's the only way you can now for sure...
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts

2021-01-04 Thread Ulrich Windl 
>>> Germano Massullo  schrieb am 27.12.2020 um
14:26 in
Nachricht :
> Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
> package maintainers on Fedora/CentOS/RHEL.
> After a power failure, apcupsd shuts down the system with a command
> almost identical to
> shutdown ‑h ‑H now
> Usually when you normally shutdown your system, you may notice certain
> services taking too much time to terminate and triggering a timeout
> value before systemd forces them to terminate. I would like to ask if
> there is a way to force the system to shutdown without waiting for these
> timeouts in case an emergency like a power failure.

Basically if the UPS cannot provide power for at least 3 minutes, it's simply
the wrong UPS (IMHO).
Somedatabases need several minutes to shut down cleanly.
Despite of that you could prefix your shutdown command with a sync, keeping
fingers crossed while watching how far it (the regular shutdown) gets...

> 
> Thank you
> 
> 
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: Q: (simple) socket activation

2021-01-04 Thread Ulrich Windl 
>>> Lennart Poettering  schrieb am 21.12.2020 um 16:18
in
Nachricht <20201221151821.GC50805@gardel-login>:
> On Fr, 18.12.20 08:44, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> I have a simple question: For a socket‑unit I have:
>> LISTENUNIT
> ACTIVATES
>> [::]:16514libvirtd‑tls.socket 
> libvirtd.service
>>
>> I had enabled/started libvirtd.service first, then configured TLS later, 
> enabling/starting the libvirtd‑tls.socket.
>> Should I disable libvirtd.service again, or would that block 
> libvirtd‑tls.socket from working?
>> At the moment I can't restart libvirtd‑tls.socket when libvirtd.service is

> running: I first have to stop libvirtd.service.
> 
> This really depends on how the libvirt object put together its unit
> files, and cannot be answered out of thin air.
> 
> Not sure what "configured TLS later" is even supposed to mean.

Obviously libvirtd-tls.socket uses TLS and it can't be started when TLS is not
configured (certificates, CAs, etc.).


libvirt.service has:
[Unit]
Description=Virtualization daemon
Requires=virtlogd.socket
Requires=virtlockd.socket
# Use Wants instead of Requires so that users
# can disable these three .socket units to revert
# to a traditional non-activation deployment setup
Wants=libvirtd.socket
Wants=libvirtd-ro.socket
Wants=libvirtd-admin.socket
Wants=systemd-machined.service
Before=libvirt-guests.service
After=network.target
After=dbus.service
After=iscsid.service
After=apparmor.service
After=local-fs.target
After=remote-fs.target
After=systemd-logind.service
After=systemd-machined.service
After=xencommons.service
Conflicts=xendomains.service
Documentation=man:libvirtd(8)
Documentation=https://libvirt.org
...

/usr/lib/systemd/system/libvirtd.socket has:
[Unit]
Description=Libvirt local socket
Before=libvirtd.service


[Socket]
# The directory must match the /etc/libvirt/libvirtd.conf unix_sock_dir
setting
# when using systemd version < 227
ListenStream=/run/libvirt/libvirt-sock
Service=libvirtd.service
SocketMode=0666


/usr/lib/systemd/system/libvirtd-tls.socket has:
[Unit]
Description=Libvirt TLS IP socket
Before=libvirtd.service
BindsTo=libvirtd.socket
After=libvirtd.socket


[Socket]
# This must match the /etc/libvirt/libvirtd.conf tls_port setting
# when using systemd version < 227
ListenStream=16514
Service=libvirtd.service
...

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Skip ExecStop after service end or failure

2021-01-04 Thread Ulrich Windl 
>>> Robert Dahlem  schrieb am 20.12.2020 um 12:48 in
Nachricht :
> Hi,
> 
> is there a way to NOT run ExecStop, when a service started successfully,
> but ends later without being stopped?
> 
> My scenario: I have an ExecStop that should only run after
> 
>   systemctl stop XXX.service
> 
> which means: only when someone administratively shuts down the service.
> 
> It must not run, when the service terminates by whatever means (exit 0,
> exit 1, signal). In this case, systemd shall just mark the service as
> failed and leave it be.
> 
> Can this be configured?

What should the status be then? Started?

> 
> Regards,
> Robert
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: journalctl -f after restart of journald

2021-01-04 Thread Ulrich Windl 
>>> Lennart Poettering  schrieb am 19.12.2020 um 13:44
in
Nachricht <20201219124443.GM48346@gardel-login>:
> On Mo, 30.11.20 12:08, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> I just made an "interesting" observation: When running "journalctl
>> ‑f" there is no message when journald restarts, meaning you'll have
>> to restart "journalctl ‑f", too to see any messages after journald
>> has been restarted.
>>
>> Is this the way it is designed?
> 
> Sounds like a bug. But journald typically doesn't restart?

Typical situation: One windows runs "journalctl -f" while another window
performs OS updates.

> 
> Given the old version of systemd you appear to be using, please report
> to your downstream distro. They'll propagate this back to us if this
> is still a problem in current versions.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: Why is journalctl -b so slow?

2021-01-04 Thread Ulrich Windl 
>>> Lennart Poettering  schrieb am 19.12.2020 um 13:34
in
Nachricht <20201219123435.GJ48346@gardel-login>:
> On Fr, 20.11.20 10:39, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> journactl ‑b is quite fast to display the first lines, but when I
>> want to see the last lines, it's quite slow.
> 
> How to you jump to the last lines? You are in "less" (i.e. the usual
> auto‑paging) and press ?  If so, the full journal needs to be

I press 'G' ;-)

> streamed to less first. That is necessarily slow if you have a lot of
> log data, since it all needs to be read into memory, passed to less
> which then buffers it again, counts lines and finds the "end" of it).
> 
>> The journal is on BtrFS
>> that is on a hardware RAID made from two SSDs, so the _filesystem_
>> should not be the problem (actually it seems the journal is in tmpfs
>> actually):
> 
> Performance deteriorates with the number of journal files. There are
> some O(n)'isms with the number of journal files currently. These
> should be addressable though, but so far noone spent the time on this
> (i.e. we can move a tiny bit more information from the file contents
> into the file name so that we don't have to even open the files to be
> able to know where they belong in the chronology of things)
> 
> btrfs makes things a lot worse btw, since the write pattern we employ
> that are very unfriendly to CoW file systems (i.e. we do random
> writes; CoW file systems can't really handle anything that aren't
> linear writes). In upstream defaults we thus turn off cow for these
> files, not sure if your distro undoes that though.

At the time being, the journal was in tmpfs only. It seems the problem might
be either:
Many very similar messages repeating in groups (like A, B, C, A, B, C, ...)
Related to Unicode processing (There exists a similar slowness in "wc")

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] timesyncd on systems without battery

2021-01-04 Thread Daniel Tihelka 
Hello,
I run systemd on a NAS without internal-clock-holding battery, so I think
that
the systemd-timesyncd sets the time to the last known value after restart
and
syncs it from the network when on-line. Is it right?

Now, I have a shutdown timer unit, which powers the NAS off at the given
time.
However, sometimes (about 50% of cases), when the device is powered-on, it
switches off immediately. When switched-on again, it boots as expected.

The question is, is there a way of fixing this issue? I have tried to add
sleep
to skip to the next minute (ExecStart should be triggered one after
another), but unsuccessfully.

Thank you,
DT


Here are the unit files.
timer:

[Unit]
Description=Poweroff the system on scheduled time

[Timer]
# Power off at the given time
OnCalendar=Mon,Tue,Wed,Thu,Fri *-*-* 01:10:00
OnCalendar=Sat,Sun *-*-* 01:55:00

[Install]
WantedBy=timers.target

---
service:

[Unit]
Description=Poweroff the system

[Service]
Type=oneshot
ExecStart=/bin/sleep 80
ExecStart=/usr/bin/systemctl poweroff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel