[systemd-devel] Antw: [EXT] Re: [dm-devel] RFC: one more time: SCSI device identification

2021-04-27 Thread Ulrich Windl
>>> Hannes Reinecke  schrieb am 27.04.2021 um 10:21 in Nachricht
<2a6903e4-ff2b-67d5-e772-6971db844...@suse.de>:
> On 4/27/21 10:10 AM, Martin Wilck wrote:
>> On Tue, 2021‑04‑27 at 13:48 +1000, Erwin van Londen wrote:

 Wrt 1), we can only hope that it's the case. But 2) and 3) need work,
 afaics.

>>> In my view the WWID should never change. 
>> 
>> In an ideal world, perhaps not. But in the dm‑multipath realm, we know
>> that WWID changes can happen with certain storage arrays. See 
>> https://listman.redhat.com/archives/dm‑devel/2021‑February/msg00116.html 
>> and follow‑ups, for example.
>> 
> And it's actually something which might happen quite easily.
> The storage array can unmap a LUN, delete it, create a new one, and map
> that one into the same LUN number than the old one.
> If we didn't do I/O during that interval upon the next I/O we will be
> getting the dreaded 'Power‑On/Reset' sense code.
> _And nothing else_, due to the arcane rules for sense code generation in
> SAM.
> But we end up with a completely different device.
> 
> The only way out of it is to do a rescan for every POR sense code, and
> disable the device eg via DID_NO_CONNECT whenever we find that the
> identification has changed. We already have a copy of the original VPD
> page 0x83 at hand, so that should be reasonably easy.

I don't know the depth of the SCSI or FC protocol, but storage systems
typically signal such events, maybe either via some unit attention or some FC
event. Older kernels logged that there was a change, but a manual SCSI bus scan
is needed, while newer kernels find new devices "automagically" for some
products. The HP EVA 6000 series wored that way, a 3PAR SotorServ 8000 series
also seems to work that way, but not Pure Storage X70 R3. FOr the latter you
need something like a FC LIP to make the kernel detect the new devices (LUNs).
I'm unsure where the problem is, but in principle the kernel can be
notified...

> 
> I had a rather lengthy discussion with Fred Knight @ NetApp about
> Power‑On/Reset handling, what with him complaining that we don't handle
> is correctly. So this really is something we should be looking into,
> even independently of multipathing.
> 
> But actually I like the idea from Martin Petersen to expose the parsed
> VPD identifiers to sysfs; that would allow us to drop sg_inq completely
> from the udev rules.

Talking of VPDs: Somewhere in the last 12 years (within SLES 11)there was a
kernel change regarding trailing blanks in VPD data. That change blew up
several configurations being unable to re-recognize the devices. In one case
the software even had bound a license to a specific device with serial number,
and that software found "new" devices while missing the "old" ones...

Regards,
Ulrich

> 
> Cheers,
> 
> Hannes
> ‑‑ 
> Dr. Hannes Reinecke   Kernel Storage Architect
> h...@suse.de +49 911 74053 688
> SUSE Software Solutions Germany GmbH, 90409 Nürnberg
> GF: F. Imendörffer, HRB 36809 (AG Nürnberg)



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


[systemd-devel] Antw: [EXT] Re: [dm-devel] RFC: one more time: SCSI device identification

2021-04-27 Thread Ulrich Windl
>>> Erwin van Londen  schrieb am 27.04.2021 um 05:48 
>>> in
Nachricht
:

> 
> On Mon, 2021-04-26 at 13:16 +, Martin Wilck wrote:
>> On Mon, 2021-04-26 at 13:14 +0200, Ulrich Windl wrote:
>> > > > 
>> > > 
>> > > While we're at it, I'd like to mention another issue: WWID
>> > > changes.
>> > > 
>> > > This is a big problem for multipathd. The gist is that the device
>> > > identification attributes in sysfs only change after rescanning
>> > > the
>> > > device. Thus if a user changes LUN assignments on a storage
>> > > system,
>> > > it can happen that a direct INQUIRY returns a different WWID as
>> > > in
>> > > sysfs, which is fatal. If we plan to rely more on sysfs for
>> > > device
>> > > identification in the future, the problem gets worse. 
>> > 
>> > I think many devices rely on the fact that they are identified by
>> > Vendor/model/serial_nr, because in most professional SAN storage
>> > systems you
>> > can pre-set the serial number to a custom value; so if you want a
>> > new
>> > disk
>> > (maybe a snapshot) to be compatible with the old one, just assign
>> > the
>> > same
>> > serial number. I guess that's the idea behind.
>> 
>> What you are saying sounds dangerous to me. If a snapshot has the
>> same
>> WWID as the device it's a snapshot of, it must not be exposed to any
>> host(s) at the same time with its origin, otherwise the host may
>> happily combine it with the origin into one multipath map, and data
>> corruption will almost certainly result. 
>> 
>> My argument is about how the host is supposed to deal with a WWID
>> change if it happens. Here, "WWID change" means that a given H:C:T:L
>> suddenly exposes different device designators than it used to, while
>> this device is in use by a host. Here, too, data corruption is
>> imminent, and can happen in a blink of an eye. To avoid this, several
>> things are needed:
>> 
>>  1) the host needs to get notified about the change (likely by an UA
>> of
>> some sort)
>>  2) the kernel needs to react to the notification immediately, e.g.
>> by
>> blocking IO to the device,
>>  3) userspace tooling such as udev or multipathd need to figure out
>> how
>> to  how to deal with the situation cleanly, and eventually unblock
>> it.
>> 
>> Wrt 1), we can only hope that it's the case. But 2) and 3) need work,
>> afaics.
>> 
> In my view the WWID should never change. If a snapshot is created it
> should either obtain a new WWID. An example out of a Hitachi array is
> 
> Device Identification VPD page:
> Addressed logical unit:
> designator type: T10 vendor identification, code set: ASCII
> vendor id: HITACHI 
> vendor specific: 50403B050709
> designator type: NAA, code set: Binary
> 0x60060e80123b050050403b050709
> 
> The majority of the naa wwid is tied to the storage subsystem and
> identifies the vendor oui, model, serial etc. The last 4 in this
> example indicate the LDEV ID (Sorry mainframe heritage here..). When a
> snapshot is taken these 4 will change as a new LDEV ID is assigned to
> the snapshot. This sort of behaviour should be consistent across all
> storage vendors imho.

It's getting off-topic, but in automatic desaster recovery scenarios one might 
want that the "new disk" (maybe a snapshot of the original disk before it got 
corrupted) looks like the "old disk", so that the OS can boot without needing 
any adjustments.

Regards,
Ulrich

> 
>> Martin
>> 




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


[systemd-devel] Antw: [EXT] Re: systemctl reboot get terminated by signal 15

2021-04-26 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 23.04.2021 um 21:33
in
Nachricht :
> On Fr, 23.04.21 14:15, Pengpeng Sun (pengpe...@vmware.com) wrote:
> 
>> Hi Lennart,
>>
>> The issue reproduced at 2021‑04‑22T15:45:30.230Z,  I ran 'sudo journalctl
‑b', 
> the log began at Apr 22 15:45:48 which is later than the issue reproduced.
>> How can I get more early and detailed systemd log?
> 
> man 5 journald.conf
> 
> Maybe your distro didn't enable persistent storage of journald, and
> thus journald uses only in‑memory storage in /run, and is thus
> constrained by its diminutive size?

In SLES it seems to be just "mkdir /var/log/journal" and restarting journald.

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: RFC: one more time: SCSI device identification

2021-04-26 Thread Ulrich Windl
>>> Martin Wilck  schrieb am 23.04.2021 um 12:28 in
Nachricht :
> On Thu, 2021‑04‑22 at 21:40 ‑0400, Martin K. Petersen wrote:
>> 
>> Martin,
>> 
>> > I suppose 99.9% of users never bother with customizing the udev
>> > rules.
>> 
>> Except for the other 99.9%, perhaps? :) We definitely have many users
>> that tweak udev storage rules for a variety of reasons. Including
>> being
>> able to use RII for LUN naming purposes.
>> 
>> > But we can actually combine both approaches. If "wwid" yields a
>> > good
>> > value most of the time (which is true IMO), we could make user
>> > space
>> > rely on it by default, and make it possible to set an udev property
>> > (e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID
>> > differently. User‑space apps like multipath could check the
>> > ID_LEGACY
>> > property to determine whether or not reading the "wwid" attribute
>> > would
>> > be consistent with udev. That would simplify matters a lot for us
>> > (Ben,
>> > do you agree?), without the need of adding endless BLIST entries.
>> 
>> That's fine with me.
>> 
>> > AFAICT, no major distribution uses "wwid" for this purpose (yet).
>> 
>> We definitely have users that currently rely on wwid, although
>> probably
>> not through standard distro scripts.
>> 
>> > In a recent discussion with Hannes, the idea came up that the
>> > priority
>> > of "SCSI name string" designators should actually depend on their
>> > subtype. "naa." name strings should map to the respective NAA
>> > descriptors, and "eui.", likewise (only "iqn." descriptors have no
>> > binary counterpart; we thought they should rather be put below NAA,
>> > prio‑wise).
>> 
>> I like what NVMe did wrt. to exporting eui, nguid, uuid separately
>> from
>> the best‑effort wwid. That's why I suggested separate sysfs files for
>> the various page 0x83 descriptors. I like the idea of being able to
>> explicitly ask for an eui if that's what I need. But that appears to
>> be
>> somewhat orthogonal to your request.
>> 
>> > I wonder if you'd agree with a change made that way for "wwid". I
>> > suppose you don't. I'd then propose to add a new attribute
>> > following
>> > this logic. It could simply be an additional attribute with a
>> > different
>> > name. Or this new attribute could be a property of the block device
>> > rather than the SCSI device, like NVMe does it
>> > (/sys/block/nvme0n2/wwid).
>> 
>> That's fine. I am not a big fan of the idea that block/foo/wwid and
>> block/foo/device/wwid could end up being different. But I do think
>> that
>> from a userland tooling perspective the consistency with NVMe is more
>> important.
> 
> OK, then here's the plan: Change SCSI (block) device identification to
> work similar to NVMe (in addition to what we have now).
> 
>  1. add a new sysfs attribute for SCSI block devices as
> /sys/block/sd$X/wwid, the value derived similar to the current "wwid"
> SCSI device attribute, but using the same prio for SCSI name strings as
> for their binary counterparts, as described above.
> 
>  2. add "naa" and "eui" attributes, too, for user‑space applications
> that are interested in these specific attributes. 
> Fixme: should we differentiate between different "naa" or eui subtypes,
> like "naa_regext", "eui64" or similar? If the device defines multiple
> "naa" designators, which one should we choose?
> 
>  3. Change udev rules such that they primarily look at the attribute in
> 1.) on new installments, and introduce a variable ID_LEGACY to tell the
> rules to fall back to the current algorithm. I suppose it makes sense
> to have at least ID_VENDOR and ID_PRODUCT available when making this
> decision, so that it doesn't have to be a global setting on a given
> host.
> 
> While we're at it, I'd like to mention another issue: WWID changes.
> 
> This is a big problem for multipathd. The gist is that the device
> identification attributes in sysfs only change after rescanning the
> device. Thus if a user changes LUN assignments on a storage system, 
> it can happen that a direct INQUIRY returns a different WWID as in
> sysfs, which is fatal. If we plan to rely more on sysfs for device
> identification in the future, the problem gets worse. 

I think many devices rely on the fact that they are identified by
Vendor/model/serial_nr, because in most professional SAN storage systems you
can pre-set the serial number to a custom value; so if you want a new disk
(maybe a snapshot) to be compatible with the old one, just assign the same
serial number. I guess that's the idea behind.

> 
> I wonder if there's a chance that future kernels would automatically
> update the attributes if a corresponding UNIT ATTENTION condition such
> as INQUIRY DATA HAS CHANGED is received (*), or if we can find some
> other way to avoid data corruption resulting from writing to the wrong
> device.
> 
> Regards,
> Martin
> 
> (*) I've been told that WWID changes can happen even without receiving
> an UA. But in that case I'm inclined to put the blame on 

[systemd-devel] Antw: [EXT] Re: "Correct" way to obtain DHCP lease info?

2021-04-23 Thread Ulrich Windl
>>> "Bruce A. Johnson"  schrieb am 22.04.2021
um
22:14 in Nachricht
<5aaf83b2-9857-425d-2d7f-b9660abf9...@blueridgenetworks.com>:
> I'm still trying to get an explanation of why having a valid DHCP 
> address is not in itself good enough. The only reason I've been able to 
> see is that after the lease is issued, and before the time comes to 
> refresh the lease, there could be a communication failure somewhere 
> between the switch the DHCP client is on and the home office where the 
> DHCP server is. One would assume that application failures would be a 
> reasonable clue Regardless, it seems to me that it's not 
> unreasonable for an application outside of systemd-networkd to be able 
> to obtain the DHCP lease information. Am I off base here?

Hi!

I did not follow the discussion closely, but using USB tehering with my
smartphone typically results in DHCP leases of one hour.
I had made the experience that network stopped many times after about one hour
(when the DHCP lease should have been refreshed, but wasn't).
I ran "watch ip r sh" in a terminal to monitor: Once the "usb0" interface was
gone, I knew there is a problem. Restarting the tethering fixed the problem in
practically all cases.
So long story short: I think there is a valid reason to be able to debug DHCP
and fellows...

Regars,
Ulrich


> 
> Bruce A. Johnson | Firmware Engineer
> Blue Ridge Networks, Inc.
> 14120 Parke Long Court Suite 103 | Chantilly, VA 20151
> Main: 1.800.722.1168 | Direct: 703-633-7332
> http://www.blueridgenetworks.com 
> OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ 
> 
> On 22/04/2021 12:00, Mantas Mikulėnas wrote:
>> On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson 
>> > > wrote:
>>
>> Silvio, thanks for the suggestion. I'm not concerned with keeping
>> the lease forever; the system actually experiences a topology
>> change as it's switched from one network to another, and I can
>> catch that from the DBus events that occur. The problem we're
>> trying to solve is to contact some address that we're sure exists
>> on the network, without knowing anything about that network. The
>> default gateway was an obvious choice, but someone wants to cover
>> the case of there being a private LAN with no gateway. The only
>> other choice I could see is the DHCP server that issues the lease.
>>
>> Hmm, don't you also have the case of there being a private LAN with no 
>> gateway and no DHCP? Or possibly the case of a DHCP relay. And since 
>> you don't know anything about the network, you also don't know whether 
>> the address will respond to your communication attempts (other than 
>> ARP) -- it might be pingable but it might be not.
>>
>> I'm curious about what brought this problem into existence in the 
>> first place. Why *is* it necessary to contact a random address within 
>> the network? (If it's to check that the physical interface is working, 
>> then just the fact that you somehow acquired a lease would be enough. no?)
>>
>> -- 
>> Mantas Mikulėnas



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


[systemd-devel] Antw: [EXT] Kdump with full-disk LUKS encryption

2021-04-20 Thread Ulrich Windl
>>> Kairui Song  schrieb am 19.04.2021 um 12:00 in
Nachricht
:
> Hi all,
> 
> I'm currently trying to add kdump support for systemd with full‑disk
> LUKS encryption. vmcores contain sensitive data so they should also be
> protected, and network dumps sometimes are not available. So kdump has
> to open the LUKS encrypted device in the kdump environment.
> 
> I'm using systemd/dracut, my work machine is running Fedora 34, and
> there are several problems I'm trying to solve:
> 1. Users have to input the password in the kdump kernel environment.
> But users often don't have shell access to the kdump environment.
> (headless server, graphic card not working after kexec, both are very
> common)
> 2. LUKS2 prefers Argon2 as the key derivation function, designed to
> use a lot of memory. kdump is expected to use a minimal amount of
> memory. Users will have to reserve a huge amount of memory for kdump
> to work (eg. 1G reserve for kdump with 4G total memory which is not
> reasonable).

I'm not a LUKS specialist, but can't you use different KDFs in a different key
slot?
That may weaken the security of course.

> 
> To fix these problems, I tried to pass the master key to the second
> kernel directly via initramfs. Kdump will modify the initramfs in
> ramfs to include the key, kexec_load it, and never write to any actual
> back storage. This worked with old LUKS configurations.
> 
> But LUKS2/cryptsetup now stores the key in the kernel keyring by
> default. The key is accessible from userspace.
> 
> Users can enter the password to start kdump manually and then it will
> work, but usually people expect kdump service to start automatically.
> 
> (WIP patch series:
> https://lists.fedoraproject.org/archives/list/ke...@lists.fedoraproject.org/

> thread/RTYJEQ4BV25JYVYJHTTPOK476FUEJOWW/)
> 
> I've several ideas about how to improve it but not sure which one is
> better, and if this is a good idea after all:
> 1. Simply introduce a config to let systemd‑cryptsetup disable kernel
> keyring on setup, there is currently no such option.
> 
> 2. If we can let the key stay in userspace for a little longer, eg.
> for systems booted with dracut/systemd, when
> systemd‑cryptsetup@%s.service opens the crypt device, keep the key in
> dm‑crypt. And later when services like kdump have finished loading,
> cryptsetup can refresh the device and store the key in the kernel
> keyring again.
> 
> 3. Let kdump use some custom helper/service to load all needed
> resources in the early initrd boot stage, prior to
> systemd‑cryptsetup@%s.service. It will ask the password / parse the
> keyfile and load kdump, then provide info for systemd‑cryptsetup or
> just do the setup. Or maybe let systemd‑cryptsetup support some kind
> of "plugins" so other tools can use it.
> 
> 4. A better and safer solution seems to keep a consistent key ring
> between kexec boots but also more complex and difficult as different
> arch implements kexec differently.
> 
> Any suggestions are welcomed!
> 
> ‑‑
> Best Regards,
> Kairui Song
> 
> ___
> 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] Q: asymmetry of ExecStop and ExecStart

2021-04-14 Thread Ulrich Windl
Hi!

I have two services defined, one using ExecStart only, the other ExecStop only.
Then I discovered some asymmetry:
systemd is still starting the service with the ExecStop only, while the one 
with the ExecStart only never is stopped.

Is that intended, or do I have some configuration error in the ExecStart only 
service?

The units look like this:
# /usr/lib/systemd/system/dellcd-log-start.service
[Unit]
Description=Log Start on Dell LCD
Documentation=man:dellcd(1)
DefaultDependencies=no
After=local-fs.target
Before=sysinit.target
Requires=local-fs.target
ConditionPathExists=/usr/bin/...

[Service]
Type=oneshot
TimeoutSec=10
ExecStart=/usr/bin/...

[Install]
WantedBy=sysinit.target

# /usr/lib/systemd/system/dellcd-log-stop.service
[Unit]
Description=Log Stop on Dell LCD
Documentation=man:dellcd(1)
DefaultDependencies=no
After=default.target
Requires=local-fs.target
ConditionPathExists=/usr/bin/...

[Service]
Type=oneshot
TimeoutSec=5
RemainAfterExit=yes
ExecStop=/usr/bin/...

[Install]
WantedBy=default.target

---
Regards,
Ulrich


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


[systemd-devel] Antw: [EXT] .local searches not working

2021-04-12 Thread Ulrich Windl
>>> Phillip Susi  schrieb am 09.04.2021 um 20:27 in
Nachricht
<874kgfqphb@vps.thesusis.net>:
> What special treatment does systemd‑resolved give to .local domains?
> The corporate windows network uses a .local domain and even when I point
> systemd‑resolved at the domain controller, it fails the query without
> bothering to ask the dc saying:
> 
> resolve call failed: No appropriate name servers or networks for name
> found

I don't know who established using ".local" for Windows AD "DNS" names, but
RFC 6762 says:
  1. Users may use these names as they would other DNS names,
 entering them anywhere that they would otherwise enter a
 conventional DNS name, or a dotted decimal IPv4 address, or a
 literal IPv6 address.
 Since there is no central authority responsible for assigning
 dot-local names, and all devices on the local network are
 equally entitled to claim any dot-local name, users SHOULD be
 aware of this and SHOULD exercise appropriate caution.  In an
 untrusted or unfamiliar network environment, users SHOULD be
 aware that using a name like "www.local" may not actually
 connect them to the web site they expected, and could easily
 connect them to a different web page, or even a fake or spoof
 of their intended web site, designed to trick them into
 revealing confidential information. (...)
  3. Name resolution APIs and libraries SHOULD recognize these names
 as special and SHOULD NOT send queries for these names to their
 configured (unicast) caching DNS server(s). (...)
  4. Caching DNS servers SHOULD recognize these names as special and
 SHOULD NOT attempt to look up NS records for them, or otherwise
 query authoritative DNS servers in an attempt to resolve these
 names.(...)
  5. Authoritative DNS servers SHOULD NOT by default be configurable
 to answer queries for these names, and, like caching DNS
 servers, SHOULD generate immediate NXDOMAIN responses for all
 such queries they may receive.(...)
  6. DNS server operators SHOULD NOT attempt to configure
 authoritative DNS servers to act as authoritative for any of
 these names.(...)
  7. DNS Registrars MUST NOT allow any of these names to be
 registered in the normal way to any person or entity. (...)

RFC 7368 (Home Networking):
   If, however, a global name space is not available, the homenet will
   need to pick and use a local name space, which would only have
   meaning within the local homenet (i.e., it would not be used for
   remote access to the homenet).  The .local name space currently has a
   special meaning for certain existing protocols that have link-local
   scope and is thus not appropriate for multi-subnet home networks.

Regards,
Ulrich

> 
> ___
> 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: Only start a tomcat server when you are sure that time-sync.target is online

2021-03-25 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 25.03.2021 um 15:03 in
Nachricht :

...
> there are really very few cases when Requires is really what someone wants
there are really very few cases when someone wants Requires ;-)





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


[systemd-devel] Antw: [EXT] Only start a tomcat server when you are sure that time-sync.target is online

2021-03-25 Thread Ulrich Windl
>>> Jan Hugo Prins  schrieb am 25.03.2021 um 14:41 in
Nachricht
<227be317-1e1e-42b9-f871-70b790594...@jhprins.org>:
> Hello,
> 
> In our platform we have a dependency where we want to be sure that the
> time‑sync.target is online before we start our application servers. We
> do this because we really want to be sure that the time on the
> application server is in sync with our NTP servers. The downside of the
> way we have done this at the moment is that making a configuration
> change on ntp.conf results in a restart of ntpd, which in turn results
> in a restart of the application servers. This is really not what we
> want, because we actually want to be sure that the time is correct, and
> a restart of the ntpd service on a server doesn't put the time on the
> server at risk immediately.

Actually it depends: If your time was off, because the ntp configuration was
broken,
it might make sense to wait. Despite of that many changes can be applied to
ntp by runtime reconfiguration, so you can avoid restarting ntp in a lot of
cases.

> 
> Our current configuration looks roughly like this:
> 
> [Unit]
> Description=Apache Tomcat Web Application Container
> After=syslog.target time‑sync.target
> Requires=time‑sync.target
> 
> [Service]
> Type=simple
> ExecStart=Startscripts
> ExecStop=Stopscript
> SuccessExitStatus=143
> User=tomcatuser
> Group=tomcatuser
> Restart=on‑failure
> 
> [Install]
> WantedBy=multi‑user.target
> 
> 
> The problem line is the Requires line in there I think.
> 
> Does systemd give me a different way to check if the time is in sync?
> Is there a way to create this dependency without implying a restart when
> ntpd restarts?
> 
> Jan Hugo Prins
> 
> 
> ___
> 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] Journalctl exits under heavy logs

2021-03-22 Thread Ulrich Windl
>>> Ravindran Shanmugam  schrieb am 20.03.2021 um
20:50
in Nachricht
:
> Hi,
> 
> 
> 
> Bug / Issue:
> 
> Under heavy logs entering the systemd-journald, journalctl Exits with one
> of the following error messages:
> 
> 
> 
> Failed to iterate through journal: Bad message
> 
> Failed to get realtime timestamp: Bad message
> 
> Failed to get monotonic timestamp: Bad message

In theory with recent machines, you can get two identical timestamps even with
nanosecond resolution on subsequent calls.
I learned that some months ago.

> 
> 
> 
> The systemd is at version 243
> 
> 
> 
> Is this an Upstream bug which was fixed.?
> 
> 
> 
> N.B:-
> 
> As of now, not planning to upgrade to latest systemd version(247) for some
> legacy reasons.
> 
> 
> 
> 
> 
> Repro steps:-
> 
> 1)Change the following 2 options in the file "/etc/systemd/journald.conf"
> from
> 
> 
> 
> RateLimitIntervalSec=1s
> 
> RateLimitBurst=2000
> 
>   to
> 
> RateLimitIntervalSec=0
> 
> RateLimitBurst=0
> 
> 
> 
> to turn off rate limiting, and then kill the "systemd-journald" process so
> that the new one
> 
> will be spawned and picks up the new jounald.conf
> 
> 
> 
> 
> 
> 
> 
> 2) Start ‘journalctl’ with this command:
> 
>   "/bin/journalctl -o json
>
--output-fields=_SOURCE_REALTIME_TIMESTAMP,__REALTIME_TIMESTAMP,SYSLOG_IDENT
> IFIER,_SYSTEMD_UNIT,SYSLOG_FACILITY,MESSAGE,PRIORITY
> -f --no-tail > /dev/null 2>&1 &"
> 
> 
> 
> 
> 
> 
> 
> 3)Create following bash script and run it as "test.sh 100 1"
> 
> 
> 
> #! /bin/bash
> 
> 
> 
> if [[ ! -e /tmp/lines1.txt ]]; then
> 
> for i in $(seq 1 50001); do echo "abc1-$i" >> /tmp/lines1.txt; done
> 
> for i in $(seq 1 50001); do echo "abc2-$i" >> /tmp/lines2.txt; done
> 
> for i in $(seq 1 50001); do echo "abc3-$i" >> /tmp/lines3.txt; done
> 
> for i in $(seq 1 50001); do echo "abc4-$i" >> /tmp/lines4.txt; done
> 
> for i in $(seq 1 50001); do echo "abc5-$i" >> /tmp/lines5.txt; done
> 
> fi
> 
> 
> 
> loggernum=${1}
> 
> if [[ -z ${loggernum} ]]; then
> 
> loggernum=10
> 
> fi
> 
> loopnum=$((loggernum/5+1))
> 
> 
> 
> foreverloop='no'
> 
> if [[ -n "$2" ]]; then
> 
> foreverloop='yes'
> 
> fi
> 
> 
> 
> while [[ 1 ]]; do
> 
> for i in $(seq 1 ${loopnum}); do
> 
> logger -p local0.3 -f /tmp/lines1.txt &
> 
> logger -p local0.3 -f /tmp/lines2.txt &
> 
> logger -p local0.3 -f /tmp/lines3.txt &
> 
> logger -p local0.3 -f /tmp/lines4.txt &
> 
> logger -p local0.3 -f /tmp/lines5.txt &
> 
> done
> 
> 
> 
> sleep 1
> 
> ps aux | grep logger | wc -l
> 
> 
> 
> if [[ "${foreverloop}" == "yes" ]]; then
> 
> echo 'wait for loggers to exit'
> 
> wait
> 
> journalctl_pid=$(pidof journalctl)
> 
> if [[ -z "${journalctl_pid}" ]]; then
> 
> echo "journalctl dead, exit"
> 
> exit 1
> 
> fi
> 
> else
> 
> exit 0
> 
> fi
> 
> done
> 
> 
> 
> 
> 
> 4) Wait for until the message "journalctl dead, exit" appears on the
> console, this means journalclt exited.
> 
> 
> 
> 
> 
> Rgds,
> 
> --Ravi



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


Re: [systemd-devel] Antw: [EXT] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload

2021-03-19 Thread Ulrich Windl
>>> Alan Stern  schrieb am 18.03.2021 um 16:03 in
Nachricht <20210318150309.gb527...@rowland.harvard.edu>:
> On Thu, Mar 18, 2021 at 08:10:56AM +0100, Ulrich Windl wrote:
>> >>> Alan Stern  schrieb am 17.03.2021 um 20:06 in
>> Nachricht <20210317190654.ga497...@rowland.harvard.edu>:
>> > Matthias reports that the Amazon Kindle automatically removes its
>> > emulated media if it doesn't receive another SCSI command within about
>> > one second after a SYNCHRONIZE CACHE.  It does so even when the host
>> > has sent a PREVENT MEDIUM REMOVAL command.  The reason for this
>> > behavior isn't clear, although it's not hard to make some guesses.
>> 
>> Actually I think Amazon should fix the firmware.
> 
> You are free to suggest to them that they change it.  Even if you do 
> find the right people to ask about this, I'd be very surprised if they 
> agreed to make the change.
> 
>> It seems the main goal was to prevent the use of open software to manage the
>> content.
> 
> This is guesswork on your part, and I disagree.  I think the main goal 

Yes, it's guessing, but the real story is: Recently I tried different bluetooth 
"ear plugs with noise cancelling". Those from Samsung just worked out of the 
box (regarding audio output at least), while those from Sony did not.
Now you can decide to patch the kernel, or simply buy the other product...

> was to improve the user experience by making the Kindle return to normal 
> operating mode automatically when file transfers are finished, rather 
> than requiring the user to do something extra.  But that's also just a 
> guess.
> 
> Alan Stern




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


[systemd-devel] Antw: [EXT] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload

2021-03-18 Thread Ulrich Windl
>>> Alan Stern  schrieb am 17.03.2021 um 20:06 in
Nachricht <20210317190654.ga497...@rowland.harvard.edu>:
> Matthias reports that the Amazon Kindle automatically removes its
> emulated media if it doesn't receive another SCSI command within about
> one second after a SYNCHRONIZE CACHE.  It does so even when the host
> has sent a PREVENT MEDIUM REMOVAL command.  The reason for this
> behavior isn't clear, although it's not hard to make some guesses.

Actually I think Amazon should fix the firmware.
It seems the main goal was to prevent the use of open software to manage the
content.

> 
> At any rate, the results can be unexpected for anyone who tries to
> access the Kindle in an unusual fashion, and in theory they can lead
> to data loss (for example, if one file is closed and synchronized
> while other files are still in the middle of being written).
> 
> To avoid such problems, this patch creates a new usb‑storage quirks
> flag telling the driver always to issue a REQUEST SENSE following a
> SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
> Kindle with the flag set.  This is sufficient to prevent the Kindle
> from doing its automatic unload, without interfering with proper
> operation.
> 
> Another possible way to deal with this would be to increase the
> frequency of TEST UNIT READY polling that the kernel normally carries
> out for removable‑media storage devices.  However that would increase
> the overall load on the system and it is not as reliable, because the
> user can override the polling interval.  Changing the driver's
> behavior is safer and has minimal overhead.
> 
> Reported‑and‑tested‑by: Matthias Schwarzott 
> Signed‑off‑by: Alan Stern 
> CC: 
> 
> ‑‑‑
> 
> 
> [as1953]
> 
> 
>  drivers/usb/storage/transport.c|7 +++
>  drivers/usb/storage/unusual_devs.h |   12 
>  include/linux/usb_usual.h  |2 ++
>  3 files changed, 21 insertions(+)
> 
> Index: usb‑devel/drivers/usb/storage/transport.c
> ===
> ‑‑‑ usb‑devel.orig/drivers/usb/storage/transport.c
> +++ usb‑devel/drivers/usb/storage/transport.c
> @@ ‑656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
>   need_auto_sense = 1;
>   }
>  
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if ((us‑>fflags & US_FL_SENSE_AFTER_SYNC) &&
> + srb‑>cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "‑‑ sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
>   /*
>* If we have a failure, we're going to do a REQUEST_SENSE 
>* automatically.  Note that we differentiate between a command
> Index: usb‑devel/drivers/usb/storage/unusual_devs.h
> ===
> ‑‑‑ usb‑devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb‑devel/drivers/usb/storage/unusual_devs.h
> @@ ‑2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
>   US_FL_NO_READ_DISC_INFO ),
>  
>  /*
> + * Reported by Matthias Schwarzott 
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * emulated media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x, 0x,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_SENSE_AFTER_SYNC ),
> +
> +/*
>   * Reported by Oliver Neukum 
>   * This device morphes spontaneously into another device if the access
>   * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb‑devel/include/linux/usb_usual.h
> ===
> ‑‑‑ usb‑devel.orig/include/linux/usb_usual.h
> +++ usb‑devel/include/linux/usb_usual.h
> @@ ‑86,6 +86,8 @@
>   /* lies about caching, so always sync */\
>   US_FLAG(NO_SAME, 0x4000)\
>   /* Cannot handle WRITE_SAME */  \
> + US_FLAG(SENSE_AFTER_SYNC, 0x8000)   \
> + /* Do REQUEST_SENSE after SYNCHRONIZE_CACHE */  \
>  
>  #define US_FLAG(name, value) US_FL_##name = value ,
>  enum { US_DO_ALL_FLAGS };
> ___
> 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: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache

2021-03-18 Thread Ulrich Windl
>>> Matthias Schwarzott  schrieb am 17.03.2021 um 18:56 in
Nachricht <5f8c0755-0884-f505-c4e8-3a5e89001...@gentoo.org>:
> Am 17.03.21 um 16:17 schrieb Alan Stern:
>> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/16/21 6:04 PM, Alan Stern wrote:
 I think it would be mildly better, but not a whole lot.  Since the
 Kindle describes itself as having removable media, the kernel normally
 probes it periodically to make sure the media remains present.  The
 default probing interval is 2 seconds.  Reducing it to 0.9 seconds
 doesn't represent an exorbitant additional load IMO ‑‑ especially since
 Kindles don't tend to spend huge amounts of time connected to computers.
>>>
>>> Ah, I did not know that the default polling interval was that low(ish),
>>> given that the default indeed is already that low, then changing it to
>>> 0.8 seconds would not be a big change.  And we probably have a lot of
>>> lower hanging fruit for unnecessary wakeups then that.
>> 
>> So we need to make a decision: Should the patch be merged, or should we
>> punt the issue to userspace tools?
>> 
>> On the plus side, the patch is rather small and non‑invasive (although
>> it does allocate the last remaining bit in the 32‑bit fflags field).
>> There's also the advantage of sending the extra command only when it is
>> needed, as opposed to increasing the overall frequency of TUR polling.
>> 
>> Any opinions?
> 
> I would vote to do in kernel as that is a cleaner solution:
> 
> 1. It will work out of the box.

...once you have the right kernel

> 2. It only sends one extra command when needed.
> 3. It makes the block‑device not break if user‑space adjusts the poll 
> interval to higher values.
> 
> Matthias
> ___
> 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: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache

2021-03-18 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 17.03.2021 um 17:47
in
Nachricht :
> On Mi, 17.03.21 11:17, Alan Stern (st...@rowland.harvard.edu) wrote:
> 
>> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>> > Hi,
>> >
>> > On 3/16/21 6:04 PM, Alan Stern wrote:
>> > > I think it would be mildly better, but not a whole lot.  Since the
>> > > Kindle describes itself as having removable media, the kernel normally
>> > > probes it periodically to make sure the media remains present.  The
>> > > default probing interval is 2 seconds.  Reducing it to 0.9 seconds
>> > > doesn't represent an exorbitant additional load IMO ‑‑ especially
since
>> > > Kindles don't tend to spend huge amounts of time connected to
computers.
>> >
>> > Ah, I did not know that the default polling interval was that low(ish),
>> > given that the default indeed is already that low, then changing it to
>> > 0.8 seconds would not be a big change.  And we probably have a lot of
>> > lower hanging fruit for unnecessary wakeups then that.
>>
>> So we need to make a decision: Should the patch be merged, or should we
>> punt the issue to userspace tools?
>>
>> On the plus side, the patch is rather small and non‑invasive (although
>> it does allocate the last remaining bit in the 32‑bit fflags field).
>> There's also the advantage of sending the extra command only when it is
>> needed, as opposed to increasing the overall frequency of TUR polling.
>>
>> Any opinions?
> 
> I'd argue that this should be done in the kernel.
> 
> IIUC the issue can actually lead to data corruption, no? i.e. some
> program writes 25 different files to different places on such an fs,
> then calls fsync() on one of them but not the others. Then quite
> possibly the fsync() will trigger a device disconnect sooner or later
> at which point the one file surely hit the disk, but there's no
> guarantee for the other 24, they might remain cached in memory and are
> never written out.
> 
> I'd say quirks that are necessary to avoid data corruption should
> better be done in the kernel and udev's hwdb stuff is only for stuff
> that "fills in gaps", i.e. adds additional tweaks that make things
> prettier, cleaner, nicer, more efficient but not things that make the
> basic things work, and data integrity sounds pretty basic to me.

But seeing the list of bad, broken or ill-designed hardware grow year by year,
I wonder whether we really want all that bloat in the kernel.

> 
> Or to give a counter example: the device advertises it can do media
> change, but actually cannot, right, it's not a floppy drive or cdrom
> driver after all? maybe hwdb would thus actually be the place for the
> opposite of the suggested fix: turn off the media change polling to
> reduce needless wakeups.

I actually think it would be best if those work-arounds could be loadable as
module, and the vendors of broken hardware can provide the modules that
document their broken design as well.

> 
> I mean, I'd be more open to this if this was a frequent thing and the
> database for devices like this was just tooo large for the kernel to
> carry, but that's not the case here either: it's two devices afaik,
> and such an issue wasn't seen elswhere.

...two _more_ devices...

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: Odd effect when using systemd-analyze verify in RPM %check

2021-03-17 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.03.2021 um 17:04
in
Nachricht :
> On Mo, 15.03.21 16:54, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> While constructing a new RPM package I tried "systemd‑analyze verify" as 
> %check, resulting in:
>> ...
>> Failed to open /dev/tty0: Permission denied
>> ...
>>
>> However:
>> > ll /dev/tty /dev/tty0
>> crw‑rw‑rw‑ 1 root tty 5, 0 Mar 15 16:26 /dev/tty
>> crw‑‑w 1 root tty 4, 0 Mar 11 10:11 /dev/tty0
>>
>> What's the issue with running "systemd‑analyze verify" and non‑root?
> 
> This has been fixed a long time ago.
> 
> /dev/tty0 is the foreground console, so it changes identity whenever
> you switch VT.
> 
> "systemd‑analyze verify" ultimately just runs the service manager with
> different parameters, and there was a bug once upon a time, where the
> service manager would use /dev/tty0 as it does when running PID1, but
> of course it should not when running on a console.
> 
> Maybe update to something less ancient, or ask your distro to backport
> the fix.

Maybe if you could either provide the version when it was fixed or maybe even
the commit that fixed it, I'd be happy to report this bug to my distribution.

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



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


[systemd-devel] Odd effect when using systemd-analyze verify in RPM %check

2021-03-15 Thread Ulrich Windl
Hi!

While constructing a new RPM package I tried "systemd-analyze verify" as 
%check, resulting in:
...
Failed to open /dev/tty0: Permission denied
...

However:
> ll /dev/tty /dev/tty0
crw-rw-rw- 1 root tty 5, 0 Mar 15 16:26 /dev/tty
crw--w 1 root tty 4, 0 Mar 11 10:11 /dev/tty0

What's the issue with running "systemd-analyze verify" and non-root?
When I run the same command with "su -c", then it does not print that message.

My TTY is "pts/1" (says "w").

(systemd-228 of SLES12 SP5)

Despite of that: Did anyone succeed using "systemd-analyze verify" in an RPM 
%chehck without having to install half of the system into buildroot?

Regards,
Ulrich Windl



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


Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Q; syslog.socket dependency

2021-03-12 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 12.03.2021 um 11:27 in
Nachricht :
> On Fri, 12 Mar 2021, Ulrich Windl wrote:
> [...]
>> > Can you think of a better way of wording the documentation? 
>> 
>> It depends: Do you consider /dev/log to be a "syslog socket"?
>> (I'm not running rsyslog there)
> 
> I'm not quite sure what you mean. If where you're going is "well 
> *obviously* syslog.socket refers to /dev/log", then ... maybe that's true, 
> but that ship has sailed. It simply doesn't, it means what it currently 
> means: the socket by which journald sends messages to some other syslog 
> daemon (if any).

Then yes: Change the documentation.




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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Q; syslog.socket dependency

2021-03-12 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 12.03.2021 um 08:59 in
Nachricht <90c9a861-f8cd-88d7-647-c6cc2a8ad...@very.puzzling.org>:
> On Fri, 12 Mar 2021, Ulrich Windl wrote:
>> >>> Reindl Harald  schrieb am 11.03.2021 um 16:23
in
>> Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>:
>> 
>> > 
>> > Am 11.03.21 um 12:17 schrieb Ulrich Windl:
>> >> Hi!
>> >> 
>> >> I have a unit that uses logger, and I want to run it after syslog is 
>> > available. So I added syslog.socket as dependency, but it fails:
>> >> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service 
>> > syslog.service not loaded, refusing.
>> >> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.
>> >> 
>> >> Doesn't journald also "provide" syslog.socket?
>> >> 
>> >> Manual says:
>> >> syslog.socket
>> >> The socket unit syslog implementations should listen on.
All
>> >> userspace log messages will be made available on this
socket. 
>> > For
>> >> more information about syslog integration, please consult
the
>> >> Syslog Interface[2] document
>> > 
>> > you need no dependencies for logging ‑ journald is responsible for that 
>> > and even available in the initrd
>> 
>> So journald is not listening to the syslog socket? So how are messages sent

> to
>> the journal in a compatible way?
>> At least the manual page for syslog.socket is confusing then.
> 
> So you say "the" syslog socket, but when you're running both journald and 
> rsyslog, say, there are *two different syslog sockets*.
> 
> It looks something like this:
> 
>   app
>|
>V
> /dev/log (systemd-journald-dev-log.socket)
>|
>V
> journald
>|
>| if ForwardToSyslog=yes
>|
>V
> /run/systemd/journal/syslog
>| (syslog.socket)
>|
>V
> rsyslog  (syslog.service, symlinked to rsyslog.service)
> 
> In other words, applications that expect something at /dev/log will work 
> normally. Their messages sent to this socket will be sent to the journal. 
> If the journal is configured to "forward to syslog", the message will sent 
> to /run/systemd/journal/syslog ... and this will socket-activate some 
> syslog implementation, such as rsyslog.
> 
> I documentation for syslog.socket does essentially say this. The "syslog 
> implementations" it's talking about means "rsyslog etc.", and "userspace 
> log messages will be made available on this socket" means that the journal 
> will send those messages to that socket. The linked Syslog Interface 
> document also goes into more detail on it.
> 
> Can you think of a better way of wording the documentation? 

It depends: Do you consider /dev/log to be a "syslog socket"?
(I'm not running rsyslog there)

Regards,
Ulrich




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


[systemd-devel] Antw: [EXT] Re: Q; syslog.socket dependency

2021-03-11 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 11.03.2021 um 16:23 in
Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>:

> 
> Am 11.03.21 um 12:17 schrieb Ulrich Windl:
>> Hi!
>> 
>> I have a unit that uses logger, and I want to run it after syslog is 
> available. So I added syslog.socket as dependency, but it fails:
>> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service 
> syslog.service not loaded, refusing.
>> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.
>> 
>> Doesn't journald also "provide" syslog.socket?
>> 
>> Manual says:
>> syslog.socket
>> The socket unit syslog implementations should listen on. All
>> userspace log messages will be made available on this socket. 
> For
>> more information about syslog integration, please consult the
>> Syslog Interface[2] document
> 
> you need no dependencies for logging ‑ journald is responsible for that 
> and even available in the initrd

So journald is not listening to the syslog socket? So how are messages sent to
the journal in a compatible way?
At least the manual page for syslog.socket is confusing then.

Regards,
Ulrich

> 
> it's where early‑boot stuff comes from
> ___
> 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] Need help: Program not run when rebooting

2021-03-11 Thread Ulrich Windl
Hi!

I tried to write a simple test unit that logs a message when the system is
going down (for reboot or halt), but it does not work:
---
[Unit]
Description=Test Stop log entries
Documentation=man:logger(1)
DefaultDependencies=no
After=local-fs.target
Before=reboot.target halt.target shutdown.target poweroff.target kexec.target
Wants=local-fs.target
#ConditionPathExists=/usr/bin/logger

[Service]
Type=oneshot
TimeoutSec=5
RemainAfterExit=yes
ExecStop=/usr/bin/logger -p user.notice -t LCD Stopping...

[Install]
WantedBy=reboot.target halt.target shutdown.target poweroff.target
kexec.target
#WantedBy=multi-user.target
---
After a reboot I see:
---
jeos1:~ # systemctl status log-stop-test.service
● log-stop-test.service - Test Stop log entries
   Loaded: loaded (/etc/systemd/system/log-stop-test.service; enabled; vendor
p>
   Active: active (exited) since Thu 2021-03-11 15:38:42 CET; 9min ago
 Docs: man:logger(1)
Tasks: 0
   CGroup: /system.slice/log-stop-test.service

Mar 11 15:38:42 jeos1 systemd[1]: Started Test Stop log entries.
--
But no message was written when rebooting. That is, there is a message from
systemd, but no log:
Mar 11 15:17:33 jeos1 systemd[1]: Stopped target Local File Systems.
Mar 11 15:17:33 jeos1 systemd[1]: Started Test Stop log entries.
Mar 11 15:17:33 jeos1 systemd[1]: Unmounting /usr/local...

So I want to run my program much earlier; how to do that?

Regards,
Ulrich



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


[systemd-devel] Q; syslog.socket dependency

2021-03-11 Thread Ulrich Windl
Hi!

I have a unit that uses logger, and I want to run it after syslog is available. 
So I added syslog.socket as dependency, but it fails:
Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service syslog.service 
not loaded, refusing.
Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.

Doesn't journald also "provide" syslog.socket?

Manual says:
   syslog.socket
   The socket unit syslog implementations should listen on. All
   userspace log messages will be made available on this socket. For
   more information about syslog integration, please consult the
   Syslog Interface[2] document.

Regards,
Ulrich




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


[systemd-devel] Antw: Re: Antw: [EXT] D-bus connection Unknown error

2021-03-03 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 03.03.2021 um 12:39 in
Nachricht <35c55fcf-6f7c-0566-ef55-5d7b2fb50...@thelounge.net>:

> 
> Am 03.03.21 um 07:59 schrieb Ulrich Windl:
>>>>> Shiju Email <994...@gmail.com> schrieb am 02.03.2021 um 22:27 in
Nachricht
>> :
>>> Hi, I am getting an error when any systemctl commands are issued.
>>>
>>> Failed to get D‑bus connection: Unknown error ‑1
>> 
>> I have no idea, but I think "unknown error" is bad programming style; it's
>> like "something went wrong; go and figure..."
> 
> it's the "you should never reach that" codepath and is at least a better 
> programming style than crash when something you din't think of happens

So it's an "unexpected error condition", and probably details about the
condition are available.

> ___
> 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] D-bus connection Unknown error

2021-03-02 Thread Ulrich Windl
>>> Shiju Email <994...@gmail.com> schrieb am 02.03.2021 um 22:27 in Nachricht
:
> Hi, I am getting an error when any systemctl commands are issued.
> 
> Failed to get D-bus connection: Unknown error -1

I have no idea, but I think "unknown error" is bad programming style; it's
like "something went wrong; go and figure...".

> 
> OS Debian 8.8
> 
> I couldn’t find much traction on this in web. Appreciate your help.
> 
> Thanks
> Joe



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


[systemd-devel] Q: Roles for a one-shot service

2021-02-24 Thread Ulrich Windl
Hi!

I wonder: I'm thinking of a monitoring-type of one-shot service that should be 
run periodically to update some external status display with runtime data.
In addition to that periodic activations, I'd like to run the service also 
during boot and shutdown, possibly supplying a special parameter to indicate 
that a boot or shutdown is happening.
I'm unsure how to model that with systemd. Should I define one service or three 
services?
Any proposals?

Regards,
Ulrich Windl



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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-19 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 19.02.2021 um 09:13 in
Nachricht <068b561d-677f-1abf-ef9f-0f43571e1...@thelounge.net>:

> 
> Am 19.02.21 um 08:44 schrieb Ulrich Windl:
>>>>> Lennart Poettering  schrieb am 18.02.2021 um 19:30
>> in
>> Nachricht :
>> ...
>>> entry instead of asking for new memory again. This allocation cache is
>>> a bit quicker then going to malloc() all the time, but means if you
>>> just watch the heap you'll assume there's a leak even though there
>>> isn't really, the memory is not lost after all, and will be reused
>>> eventually if we need it.
>> 
>> That's an interesting point of view: If you save memory in case you might 
> need
>> it at some unspecified later time (which includes "never") it's 
> "practically"
>> (while not theoretically) a memory leak
> 
> following that logic every memory pool and mysql buffer would be a memleak

Database memory pools typically have a settable upper-bound.

> 
> a memleak is *unintended* and never freed memory allocation, practically 
> as well as theoretically

So for every memory leak the programmer just has to say "that's intentional" 
and it's no longer a memory leak ;-)

> 
> you can argue about the size of such cases but it don't make them a 
> memleak to begin with

With Lennart's explanation there are two unbounded dimensions: 1) the amount of 
"cache" 2) the time until actual re-use
(With 2) leading to 1) it seems)

Regards,
Ulrich





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


[systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-18 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 18.02.2021 um 19:30
in
Nachricht :
...
> entry instead of asking for new memory again. This allocation cache is
> a bit quicker then going to malloc() all the time, but means if you
> just watch the heap you'll assume there's a leak even though there
> isn't really, the memory is not lost after all, and will be reused
> eventually if we need it.

That's an interesting point of view: If you save memory in case you might need
it at some unspecified later time (which includes "never") it's "practically"
(while not theoretically) a memory leak.

> 
> You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off, but
> not sure v230 already knew that env var.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: Re: Antw: [EXT] Re: Q: Debugging missing requirements

2021-02-15 Thread Ulrich Windl
>>> Dave Howorth  schrieb am 12.02.2021 um 16:17 in
Nachricht <20210212151718.1ff9b...@acer-suse.lan>:
> On Fri, 12 Feb 2021 18:04:58 +0300
> Andrei Borzenkov  wrote:
>> 12.02.2021 10:04, Ulrich Windl пишет:
>> >>>> Andrei Borzenkov  schrieb am 11.02.2021 um
>> >>>> 15:20 in  
>> > Nachricht
>> > :  
>> >> On Thu, Feb 11, 2021 at 1:47 PM Ulrich Windl
>> >>  wrote:  
>> >>>
>> >>> Hi!
>> >>>
>> >>> Suspecting systemd added some requirement that isn't fulfilled
>> >>> after boot,   
>> >> preventing my units from starting I wonder:  
>> >>> How can I debug systemd's requirements checking for units that
>> >>> are enabled,   
>> >> but not started at boot (status "inactive (dead)"?
>> >>
>> >> Usual advice is - enable debug logging.  
>> > 
>> > Can I enable this for a specific unit, or just globally?
>> 
>> Not that I am aware of. It is all or nothing.
> 
> But you don't need to look at them all for other units. You can use
> --priority to view just the levels you wish to. So there'll be more
> information in the log files, but no need to look at it unless you wish
> to.

Still it would sound like a nice feature: Enabling and disabling unit
debugging at run-time.
Something like
systemctl loglevel=debug unit...

> 
>> >>  
>> >>> Or another way: Can I list the dependencies that systemd added   
>> >> automatically?  
>> >>>  
>> >>
>> >> If you mean implicit or default dependencies - no. They are listed
>> >> in man pages, although there is no guarantee that list is
>> >> complete. Your best bet is source code.  
>> > 
>> > 
>> > 
>> >   
>> 
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Antw: [EXT] Re: Q: Debugging missing requirements

2021-02-11 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 11.02.2021 um 15:20 in
Nachricht
:
> On Thu, Feb 11, 2021 at 1:47 PM Ulrich Windl
>  wrote:
>>
>> Hi!
>>
>> Suspecting systemd added some requirement that isn't fulfilled after boot, 
> preventing my units from starting I wonder:
>> How can I debug systemd's requirements checking for units that are enabled, 
> but not started at boot (status "inactive (dead)"?
> 
> Usual advice is - enable debug logging.

Can I enable this for a specific unit, or just globally?

> 
>> Or another way: Can I list the dependencies that systemd added 
> automatically?
>>
> 
> If you mean implicit or default dependencies - no. They are listed in
> man pages, although there is no guarantee that list is complete. Your
> best bet is source code.




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


[systemd-devel] Antw: Q: Debugging missing requirements

2021-02-11 Thread Ulrich Windl
>>> Ulrich Windl schrieb am 11.02.2021 um 11:46 in Nachricht <60250B22.85D : 
>>> 161 :
60728>:
> Hi!
> 
> Suspecting systemd added some requirement that isn't fulfilled after boot, 
> preventing my units from starting I wonder:
> How can I debug systemd's requirements checking for units that are enabled, 
> but not started at boot (status "inactive (dead)"?

I forgot:
The thing is: If I start them manually after boot, there is no problem at all.

> Or another way: Can I list the dependencies that systemd added 
> automatically?
> 
> (systemd-234-24.72.1.x86_64 of SLES15)
> 
> Regards,
> Ulrich
> 
> 
> 




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


[systemd-devel] Q: Debugging missing requirements

2021-02-11 Thread Ulrich Windl
Hi!

Suspecting systemd added some requirement that isn't fulfilled after boot, 
preventing my units from starting I wonder:
How can I debug systemd's requirements checking for units that are enabled, but 
not started at boot (status "inactive (dead)"?
Or another way: Can I list the dependencies that systemd added automatically?

(systemd-234-24.72.1.x86_64 of SLES15)

Regards,
Ulrich



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


[systemd-devel] Antw: Re: [EXT] Re: consider dropping defrag of journals on btrfs

2021-02-11 Thread Ulrich Windl
>>> Phillip Susi  schrieb am 10.02.2021 um 20:39 in 
>>> Nachricht
<878s7v6759@vps.thesusis.net>:

> Chris Murphy writes:
> 
>> It's not interleaving. It uses delayed allocation to make random
>> writes into sequential writes. It's tries harder to keep file blocks
> 
> Yes, and when you do that, you are inverleaving data from multiple files
> into a single stream, which you really shouldn't be doing.  IIRC, XFS
> has special io streaming modes specifically designed to *prevent* this
> from happening and record multiple video streams simultaniously to
> different parts of the disk to keep them from being fragmented to hell
> like that.

I wonder: Would this discussion benefit if some blocktrace graphics were shown 
to prove the claims?

(Several years ago I did that to examine our Database I/O. See example)

Regards,
Ulrich



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


[systemd-devel] Antw: [EXT] timesyncd log messages galore

2021-02-11 Thread Ulrich Windl
>>> Ede Wolf  schrieb am 10.02.2021 um 19:39 in
Nachricht
:
> Hi,
> 
> 
> My journal get spammed with messages from timesyncd, claiming a changed 
> network connection. However, I have not touched the network 
> configuration at all and the ntp even happens to be on the same subnet. 
> No DHCP either.
> 
> Here two examples, 200 messages in 20 minutes uptime, or 5800 of them in 
> 11 hours:
> 
> # journalctl ‑b0 | grep "Network configuration changed, trying to 
> establish connection." | wc ‑l
> 199

Literally, I think you'll have to read between those lines (in case there is
something relevant).
Otherwise I'd suggest to strace or ltrace the process.

> 
> # uptime
>   19:29:34 up 21 min,  3 users,  load average: 1,07, 1,04, 0,87
> 
> Another machine:
> 
> # journalctl ‑b0 | grep "Network configuration changed, trying to 
> establish connection." | wc ‑l
> 5755
> # uptime
>   19:32:20 up 10:28,  2 users,  load average: 1.21, 1.20, 1.20
> 
> Any idea how to stop this? This has been going on for quite a while now, 
> but seems to get worse.
> 
> systemd 247.3, kernel 5.4.80 and 5.10.14
> ___
> 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: Re: [EXT] Re: consider dropping defrag of journals on btrfs

2021-02-09 Thread Ulrich Windl
>>> Phillip Susi  schrieb am 09.02.2021 um 15:53 in 
>>> Nachricht
<87o8gtz3m1@vps.thesusis.net>:

> Chris Murphy writes:
> 
>> Basically correct. It will merge random writes such that they become
>> sequential writes. But it means inserts/appends/overwrites for a file
>> won't be located with the original extents.
> 
> Wait, I thoguht that was only true for metadata, not normal file data
> blocks?  Well, maybe it becomes true for normal data if you enable
> compression.  Or small files that get leaf packed into the metadata
> chunk.
> 
> If it's really combining streaming writes from two different files into
> a single interleaved write to the disk, that would be really silly.

Why? The idea of BtrFS was that any block written (or at least any block that 
is used "frequently enough") will be in RAM cache, so the actual location of a 
block does not matter. Perfomance-killing synchronous random writes would 
benefit instead. Like that (AFAIK).


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


[systemd-devel] Antw: Re: Antw: Antw: Re: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 09.02.2021 um 11:28 in
Nachricht <74f975f6-1ef2-ee64-bf95-415a5626...@very.puzzling.org>:
> On Tue, 9 Feb 2021, Ulrich Windl wrote:
> [...]
>> OK, I tried (staring libvirtd.service with ‑‑listen and without ‑‑timout):
>> Feb 09 10:59:23 h18 libvirtd[42540]: ‑‑listen parameter not permitted with
>> systemd activation sockets, see 'man libvirtd' for further guidance
>> Feb 09 10:59:23 h18 systemd[1]: libvirtd.service: Main process exited,
>> code=exited, status=6/NOTCONFIGURED
>> Feb 09 10:59:23 h18 systemd[1]: Failed to start Virtualization daemon.
> 
> That must be because you're still passing through sockets from systemd.
> 
> When `libvirtd.service` is started, any active socket units with 
> `Service=libvirtd.service` will be passed to the service. When libvirt is 
> started with `‑‑listen`, it checks that no sockets were passed to it.
> 
> If you don't want libvirt to be socket‑activated, you have to make sure 
> ALL of libvirt's sockets are stopped. Masking them is a good idea too, 
> but stopping them is what's important.

Actually I was 99% sure they all were stopped.


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


Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 09.02.2021 um 10:17 in
Nachricht :
> On Tue, 9 Feb 2021, Ulrich Windl wrote:
> [...]
>> At what timne exactly? When pacemaker starts, or when the systemd using is
>> about to be started?
> 
> Pacemaker adds the drop‑in just before it starts the resource, and it 
> removes the drop‑in just after it stops the resource. It's entire purpose 
> is to handle the case when Pacemaker and the service are *simultaneously* 
> stopped (i.e. by something external to Pacemaker).
> 
> Without the drop‑in, what can happen is that the service is stopped before 
> Pacemaker thinks it should be stopped... which makes Pacemaker attempt to 
> recover the resource... which makes every go wrong quickly.

Yeah two resource managers is one too many (much?).



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


[systemd-devel] Antw: Re: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 09.02.2021 um 10:14 in
Nachricht
:
> On Tue, Feb 9, 2021 at 11:54 AM Ulrich Windl
>  wrote:
>>
>> Thanks and "back to the mess": If I use libvirtd.service instead of
>> libvirtd-tls.socket, it does *not* open the TLS socket, even though the
>> configuration file contains "listen_tls=1"...
> 
> libvirtd --listen
> 
> Did you read the link I gave you on the pacemaker list?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1750340#c0 
> 
> quoting
> 
> --><--
> Thus if the mgmt app / admin wants to use TCP/TLS sockets they have two 
> choices
> 
>   - To continue the old approach (setting --listen in
> /etc/sysconfig/libvirtd), then they MUST use 'systemctl mask ...' for
> all the socket units listed above, before libvirtd.service is started.
> --><--
> 
> Does it not work?

The point is that masking is still required ("nail down system with silver 
nails once you killed it, just to make sure it doesn't resurrect") as 
"disabling" the sockets is not enough.
Now it works.

Regards,
Ulrich






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


[systemd-devel] Antw: Antw: Re: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> "Ulrich Windl"  schrieb am 09.02.2021
um
10:28 in Nachricht <602255b402a10003e...@gwsmtp.uni-regensburg.de>:
>>>> Andrei Borzenkov  schrieb am 09.02.2021 um 10:14 in
> Nachricht
> :
>> On Tue, Feb 9, 2021 at 11:54 AM Ulrich Windl
>>  wrote:
>>>
>>> Thanks and "back to the mess": If I use libvirtd.service instead of
>>> libvirtd‑tls.socket, it does *not* open the TLS socket, even though the
>>> configuration file contains "listen_tls=1"...
> 
> ...and if I use libvirtd‑tls.socket, it fails on restarting:
> Feb 09 10:20:17 h18 systemd[1]: libvirtd‑tls.socket: Socket service 
> libvirtd.service already active, refusing.
> Feb 09 10:20:17 h18 systemd[1]: Failed to listen on Libvirt TLS IP socket.
> Feb 09 10:20:19 h18 pacemaker‑controld[36557]:  notice: Result of start 
> operation for prm_libvirtd on h18: error
> 
>> 
>> libvirtd ‑‑listen
>> 
>> Did you read the link I gave you on the pacemaker list?
> 
> Not yet, but due to your hint I found:
> # If systemd socket activation is disabled, then the following
> # can be used to listen on TCP/TLS sockets
> #LIBVIRTD_ARGS="‑‑listen"
> 
> ("back to the mess")
> 
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1750340#c0 
>> 
>> quoting
>> 
>> ‑‑><‑‑
>> Thus if the mgmt app / admin wants to use TCP/TLS sockets they have two 
>> choices
>> 
>>   ‑ To continue the old approach (setting ‑‑listen in
>> /etc/sysconfig/libvirtd), then they MUST use 'systemctl mask ...' for
>> all the socket units listed above, before libvirtd.service is started.
>> ‑‑><‑‑
>> 
>> Does it not work?
> 
> I'll roll‑back and try ;‑)

OK, I tried (staring libvirtd.service with --listen and without --timout):
Feb 09 10:59:23 h18 libvirtd[42540]: --listen parameter not permitted with
systemd activation sockets, see 'man libvirtd' for further guidance
Feb 09 10:59:23 h18 systemd[1]: libvirtd.service: Main process exited,
code=exited, status=6/NOTCONFIGURED
Feb 09 10:59:23 h18 systemd[1]: Failed to start Virtualization daemon.

Is libvirtd.service (as opposed to libvirtd.socket) as "socket activation"? I
thought: "no".

> 
> Regards,
> Ulrich
> 
> 
> 
> ___
> 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: Re: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 09.02.2021 um 10:14 in
Nachricht
:
> On Tue, Feb 9, 2021 at 11:54 AM Ulrich Windl
>  wrote:
>>
>> Thanks and "back to the mess": If I use libvirtd.service instead of
>> libvirtd-tls.socket, it does *not* open the TLS socket, even though the
>> configuration file contains "listen_tls=1"...

...and if I use libvirtd-tls.socket, it fails on restarting:
Feb 09 10:20:17 h18 systemd[1]: libvirtd-tls.socket: Socket service 
libvirtd.service already active, refusing.
Feb 09 10:20:17 h18 systemd[1]: Failed to listen on Libvirt TLS IP socket.
Feb 09 10:20:19 h18 pacemaker-controld[36557]:  notice: Result of start 
operation for prm_libvirtd on h18: error

> 
> libvirtd --listen
> 
> Did you read the link I gave you on the pacemaker list?

Not yet, but due to your hint I found:
# If systemd socket activation is disabled, then the following
# can be used to listen on TCP/TLS sockets
#LIBVIRTD_ARGS="--listen"

("back to the mess")

> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1750340#c0 
> 
> quoting
> 
> --><--
> Thus if the mgmt app / admin wants to use TCP/TLS sockets they have two 
> choices
> 
>   - To continue the old approach (setting --listen in
> /etc/sysconfig/libvirtd), then they MUST use 'systemctl mask ...' for
> all the socket units listed above, before libvirtd.service is started.
> --><--
> 
> Does it not work?

I'll roll-back and try ;-)

Regards,
Ulrich



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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 09.02.2021 um 09:15 in
Nachricht <20675743-9521-cdca-1c58-d42de7117...@very.puzzling.org>:
> On Tue, 9 Feb 2021, Michael Chapman wrote:
> [...]
>> Note that when you're using Pacemaker to manage a systemd service, you 
>> should not enable the service in the normal way ‑‑ that is, the service 
>> should not be started simply by virtue of it being in the Wants= list of 
>> multi‑user.target. The service is intended to be started and stopped only 
>> by Pacemaker.
> 
> Ah, there's something else I forgot to mention.
> 
> Since Pacemaker is in charge of the service's lifecycle, you almost 
> certainly *do not* want it to be socket‑activated.

Hi Michael!

Thanks and "back to the mess": If I use libvirtd.service instead of
libvirtd-tls.socket, it does *not* open the TLS socket, even though the
configuration file contains "listen_tls=1"... Support was telling me I should
"probably" use libvirtd-tls.socket instead of libvirtd.service... "The wheel
has come full circle" said Shakespeare (AFAIR)

> 
> libvirt can be run without socket activation [2]. I strongly recommend you 
> configure it this way if you intend to manage libvirt in Pacemaker.

Yes, I'd like to! Any pointers?

> 
> (I think managing libvirt in Pacemaker is a mistake, mind you. Sure, 
> manage individual libvirt *guests* in Pacemaker. But managing libvirt as a 
> whole from Pacemaker seems to be the wrong approach.)

As libvirtd has a dependency on virtlockd, and when using indirect locks,
virtlockd has a dependency on a (thinking multi-node) cluster-wide filesystem
(like OCFS2), you *must* start virtlockd *after* the cluster filesystem had
been mountd. Naturally libvirtd cannot be started before virtlockd, so you'll
have what I'm trying to manage.

As indicated before, I had asked a similar question at "superuser", but nobody
had an answer so far...

> 
> [2] https://libvirt.org/daemons.html 

Regards,
Ulrich


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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Ulrich Windl
>>> Michael Chapman  schrieb am 09.02.2021 um 09:09 in
Nachricht :
> On Tue, 9 Feb 2021, Ulrich Windl wrote:
> [...]
>> As for the drop‑ins: I neither know what those are expected to do, not who
>> adds them at run time. See "documentation"...
> 
> The 50‑pacemaker.conf drop‑ins are, as their name suggests, created by 
> Pacemaker.

Hi Michael,

thanks for explaining!

> 
> Specifically, Pacemaker's systemd resource agent [1] creates a drop‑in on 
> each Pacemaker‑managed systemd service. Consider the situation where both 

At what timne exactly? When pacemaker starts, or when the systemd using is
about to be started?

> Pacemaker and the Pacemaker‑managed service are scheduled to be stopped 
> (e.g. you're rebooting the entire system). Either you want Pacemaker to 
> stop the service itself (and, perhaps, start the service on some other 
> node in your cluster), or ‑‑ if the pacemaker resource has management 
> disabled ‑‑ you want the service to be stopped *after* Pacemaker has been 
> stopped. Either way, the service needs to be ordered 
> Before=pacemaker.service. This is precisely what that drop‑in does.

But doesn't "Before=pacemaker.service" say the corresponding service is to be
*started* *before* pacemaker?
If that's the case any ordering attempts inside the pacemaker configuration do
not make any sense.
Likewise when shutting down: If a systemd service needs some other pacemaker
service it would be stopped *after* pacemaker.
Sorry I don't understand that.

> 
> Note that when you're using Pacemaker to manage a systemd service, you 
> should not enable the service in the normal way ‑‑ that is, the service 
> should not be started simply by virtue of it being in the Wants= list of 
> multi‑user.target. The service is intended to be started and stopped only 
> by Pacemaker.

Yes, that is what I wanted, and it seems it works after a reboot of the node,
but not when pacemaker had been running once.

> 
> For more help on this drop‑in in particular, I think you'd be better off 
> contacting the Pacemaker developers.
> 
> [1] 
> https://github.com/ClusterLabs/pacemaker/blob/master/lib/services/systemd.c


Actually I had been raising the issue there too (after haing googled the
topic). As it seems *nobody* managed to create the configuration I want. 
Probably I should dump all that libvirt stuff and ose the plain Xen RA until
people fixed the mess, making it ready for actual use.

Regards,
Ulrich




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


[systemd-devel] Antw: [EXT] Re: consider dropping defrag of journals on btrfs

2021-02-09 Thread Ulrich Windl
>>> Chris Murphy  schrieb am 09.02.2021 um 06:13 in
Nachricht
:
> On Mon, Feb 8, 2021 at 7:56 AM Phillip Susi  wrote:
>>
>>
>> Chris Murphy writes:
>>
>> >> It sounds like you are arguing that it is better to do the wrong thing
>> >> on all SSDs rather than do the right thing on ones that aren't broken.
>> >
>> > No I'm suggesting there isn't currently a way to isolate
>> > defragmentation to just HDDs.
>>
>> Yes, but it sounded like you were suggesting that we shouldn't even try,
>> not just that it isn't 100% accurate.  Sure, some SSDs will be stupid
>> and report that they are rotational, but most aren't stupid, so it's a
>> good idea to disable the defragmentation on drives that report that they
>> are non rotational.
> 
> So far I've seen, all USB devices report rotational. All USB flash
> drives, and any SSD in an enclosure.
> 
> Maybe some way of estimating rotational based on latency standard
> deviation, and stick that in sysfs, instead of trusting device
> reporting. But in the meantime, the imperfect rule could be do not
> defragment unless it's SCSI/SATA/SAS and it reports it's rotational.

OTOH we had set the rotational attribute to zero for years with out negative
effects.
We did that for SAN storage that actually has spinning discs, but what sense
does the rotational attribute make if the logical disk is distributed over 40
physical disks, managed by a smart controller that does I/O scheduling across
multiple hosts and logical disks?

> 
> ‑‑ 
> Chris Murphy
> ___
> 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


Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-08 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 08.02.2021 um 19:43 in
Nachricht <63608ba2-0510-0e03-eb20-c92d86521...@gmail.com>:
> 08.02.2021 12:10, Ulrich Windl пишет:
>> It seems systemd messes with that in a bad way.
>> 
> 
> Streetlight effect ...
> 
> For the last time - systemd does exactly what unit definitions tell it
> to do. Unit definitions belong to your application. If unit definitions
> that come with application are not suitable for your purpose, it is
> between you and your application.
> 
>> I suspect "Drop_ins"
> 
> As if systemd installs these dropins on its own.

Andrei,

I know you don't share my opinion on systemd, but anyway: Systemd is highly
complex, and maybe people (not talking about me; talking about distribution
makers) did not fully understand that complexity, shipping (well let's call
them) "non-perfect units" combined with the "trend of time", namely poor or no
documentation. The end user has to do a lot of guessing work, what the Units
are expected to do, what they really do, and which units are expected to be
enabled in what cases, what the dependencies are and what the correct order of
starting (in the manual case) is.
Maybe in an ideal world every thing would just happen "automagically" ("do the
right thing"), but we are far from that.
And understanding the complexity of systemd is much harder than understanding
classic init.
As for the drop-ins: I neither know what those are expected to do, not who
adds them at run time. See "documentation"...

Regards,
Ulrich




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


[systemd-devel] Antw: [EXT] Re: sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-08 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 08.02.2021 um 19:01 in
Nachricht :

> 
> Am 08.02.21 um 18:27 schrieb Lennart Poettering:
>> On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:
>> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1909805 
>> 
>> In response to your actual issue, ignoring all the nasty wording:
>> 
>> Masking is a last resort thing, you really want to use that only after
>> having investigated everything. You use it here anyway to mask out a
>> really low‑level system thing, hence you might get warnings about
>> this.
>> 
>> You can of course mask sys‑fs‑fuse‑connections.mount too
> who needs anything related to fuse at every boot?
> fuse is nothing in common used
> fuse is not used unconditional
> 
> directly after boot on a server‑vm with no fuse business
> 
> [root@testserver:~]$ lsmod | grep fuse
> fuse  163840  1

First it seems you fuse module is used by another module, and then in SLES15
SP2 with libvirt and two running Xen PVMs, I see no fuse being used or even
loaded. So maybe find out who requests fuse...

> 
> my only usecase on 50 machines is every few weeks fuse.sshfs abd what 
> makes people nasty is that for months nobody responds to systemd related 
> issues in the Fedora bugracker
> 
> if something is usiong fuse it happily loads the kernel module on‑demand 
> for years
> 
> 
> 
> 
> ___
> 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


Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-08 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 06.02.2021 um 09:14 in
Nachricht <09aa6a69-ee37-ffea-c4fd-e4c5d3327...@gmail.com>:
> 04.02.2021 10:47, Ulrich Windl пишет:
...
>> I had provided the full units yesterday. Basically I don't know what to do:

> I
>> just want to start the service and its sockets at a specific point in time

> and
>> also want to stop those at another time.
>> 
> 
> We are going in circles. socket unit is optimization that allows you to
> start service unit on demand instead of starting it unconditionally. If
> you want to start service unit in controlled way (and not when someone
> decides to connect to socket) you should not use socket unit. Period.

All I want is that the sockets that need to listen actually do listen when the
service start.
It seems systemd messes with that in a bad way.

...
>> Pacemaker cluster provides a shared filesystem, so the units should not be
>> started before that filesystem is mounted.
> 
> So what's wrong with starting them before pacemaker? virtlockd even
> supports restarting without losing state.

When the state is left in the (correct) filesystem. Obviously when I mount a
filesystem over the mount point, the locks created before won't be visible any
more.

> 
> But that really goes beyond the scope of this list.

Staring systemd units under pacemaker control only is beyopnd the scope of
this list? Then please drop systemd units from pacemaker.

> 
>> Sounds simple, but systemd seems to make this hard to impossible.
>> 
> 
> If those units are started before pacemaker, they are certainly
> available before any pacemaker resource is activated. What exactly "is
> impossible" here?

pacemaker-controlled systemd units. Specifically virtlockd and libvirtd using
TLS.

> 
> If you insist on putting those applications under pacemaker control then
> you are shooting the messenger. Default units included with libvirt are
> not suitable for use in HA cluster. So do not use them. Create your own

That's complete nonsense: Just dump systemd and you can control your processes
again using pacemaker.

> pacemaker resource agent or create your own unit definition if it must
> be systemd resource. But that again is beyond the scope of this list.
> This should be discussed with libvirt people.

As it seems right now is that units start correctly after a node had been
fenced, but not if pacemaker is restarted on the node. The systemd starts the
units itself. I don't know why, but I suspect "Drop_ins":

h16:~ # ls /run/systemd/system/*irt*
/run/systemd/system/libvirtd.service.service.d:
50-pacemaker.conf

/run/systemd/system/virtlockd.service.d:
50-pacemaker.conf
h16:~ # cat /run/systemd/system/*irt*/50*
[Unit]
Description=Cluster Controlled libvirtd.service
Before=pacemaker.service pacemaker_remote.service

[Service]
Restart=no

[Unit]
Description=Cluster Controlled virtlockd
Before=pacemaker.service pacemaker_remote.service

[Service]
Restart=no

Regards,
Ulrich




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


[systemd-devel] Antw: [EXT] Re: consider dropping defrag of journals on btrfs

2021-02-08 Thread Ulrich Windl
>>> Phillip Susi  schrieb am 05.02.2021 um 16:02 in
Nachricht
<87a6si5yjq@vps.thesusis.net>:

> Chris Murphy writes:
> 
>> But it gets worse. The way systemd‑journald is submitting the journals
>> for defragmentation is making them more fragmented than just leaving
>> them alone.
> 
> Wait, doesn't it just create a new file, fallocate the whole thing, copy
> the contents, and delete the original?  How can that possibly make
> fragmentation *worse*?
> 
>> All of those archived files have more fragments (post defrag) than
>> they had when they were active. And here is the FIEMAP for the 96MB
>> file which has 92 fragments.
> 
> How the heck did you end up with nearly 1 frag per mb?

I didn't follow the thread tightly, but there was a happy mix of IOps,
fragments (and no bandwidth),
but I wonder here: Isn't it concept of BtrFS that writes are fragmented if
there is no contiguous free space?
The idea was *not* to spend time trying to find a goot spoace to write to, but
use the next available one.

> 
>> If you want an optimization that's actually useful on Btrfs,
>> /var/log/journal/ could be a nested subvolume. That would prevent any

Actually I stil ldidn't get the benefit of a BtrFS subvolume, but that 's a
different topic:
Don't all wrtites end up in a single storage pool?

>> snapshots above from turning the nodatacow journals into datacow
>> journals, which does significantly increase fragmentation (it would in
>> the exact same case if it were a reflink copy on XFS for that matter).
> 
> Wouldn't that mean that when you take snapshots, they don't include the
> logs?  That seems like an anti feature that violates the principal of
> least surprise.  If I make a snapshot of my root, I *expect* it to
> contain my logs.
> 
>> I don't get the iops thing at all. What we care about in this case is
>> latency. A least noticeable latency of around 150ms seems reasonable
>> as a starting point, that's where users realize a delay between a key
>> press and a character appearing. However, if I check for 10ms latency
>> (using bcc‑tools fileslower) when reading all of the above journals at
>> once:
>>
>> $ sudo journalctl ‑D
>> /mnt/varlog33/journal/b51b4a725db84fd286dcf4a790a50a1d/ ‑‑no‑pager
>>
>> Not a single report. None. Nothing took even 10ms. And those journals
>> are more fragmented than your 20 in a 100MB file.
>>
>> I don't have any hard drives to test this on. This is what, 10% of the
>> market at this point? The best you can do there is the same as on SSD.
> 
> The above sounded like great data, but not if it was done on SSD.  Of
> course it doesn't cause latency on an SSD.  I don't know about market
> trends, but I stopped trusting my data to SSDs a few years ago when my
> ext4 fs kept being corrupted and it appeared that the FTL of the drive
> was randomly swapping the contents of different sectors around when I
> found things like the contents of a text file in a block of the inode
> table or a directory.
> 
>> You can't depend on sysfs to conditionally do defragmentation on only
>> rotational media, too many fragile media claim to be rotating.

Probably to keep software from breaking... ;-)

> 
> It sounds like you are arguing that it is better to do the wrong thing
> on all SSDs rather than do the right thing on ones that aren't broken.
> 
>> Looking at the two original commits, I think they were always in
>> conflict with each other, happening within months of each other. They
>> are independent ways of dealing with the same problem, where only one
>> of them is needed. And the best of the two is fallocate+nodatacow
>> which makes the journals behave the same as on ext4 where you also
>> don't do defragmentation.
> 
> This makes sense.
> ___
> 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: Still confused with socket activation

2021-02-04 Thread Ulrich Windl
>>> Ulrich Windl schrieb am 03.02.2021 um 10:34 in Nachricht <601A6E3D.E40 :
161 :
60728>:
>>>> Lennart Poettering  schrieb am 02.02.2021 um
15:59 in
> Nachricht <20210202145954.GB36677@gardel-login>:
> > On Di, 02.02.21 10:43, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) 
> wrote:
> > 
> >> Hi!
> >>
> >> Having:
> >> ‑‑‑
> >> # /usr/lib/systemd/system/virtlockd.service
> >> [Unit]
> >> Description=Virtual machine lock manager
> >> Requires=virtlockd.socket
> >> Requires=virtlockd‑admin.socket
> >> Before=libvirtd.service
> >> ...
> >> ‑‑‑
> >>
> >> How would I start both sockets successfully unter program control?
> >> If I start one socket, I cannot start the other without an error (as 
> > libvirtd.service is running already, see my earlier message from last
week).
> >> If I mask the socket units, I cannot start the libvirtd.service.
> >> So would I disable the socket units and start libvirtd.service?
> >> Unfortunately if someone (update when vendor‑preset is enabled)
re‑enables 
> the 
> > socket units, it would break things, so I tried to mask them, but that 
> > failed, too.
> >> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is

> > masked.
> > 
> > I don't grok what you are trying to say, the excerpt of the unit file
> > is too short. Please provide the relevant parts of the other unit
> > files too.
> 
> So you get it:
> 
> 
> # systemctl cat virtlockd.service
> # /usr/lib/systemd/system/virtlockd.service
> [Unit]
> Description=Virtual machine lock manager
> Requires=virtlockd.socket
> Requires=virtlockd-admin.socket
> Before=libvirtd.service
> Documentation=man:virtlockd(8)
> Documentation=https://libvirt.org 
> 
> [Service]
> EnvironmentFile=-/etc/sysconfig/virtlockd
> ExecStart=/usr/sbin/virtlockd $VIRTLOCKD_ARGS
> ExecReload=/bin/kill -USR1 $MAINPID
> # Loosing the locks is a really bad thing that will
> # cause the machine to be fenced (rebooted), so make
> # sure we discourage OOM killer
> OOMScoreAdjust=-900
> # Needs to allow for max guests * average disks per guest
> # libvirtd.service written to expect 4096 guests, so if we
> # allow for 10 disks per guest, we get:
> LimitNOFILE=40960
> 
> [Install]
> Also=virtlockd.socket
> 
> # /run/systemd/system/virtlockd.service.d/50-pacemaker.conf
> [Unit]
> Description=Cluster Controlled virtlockd
> Before=pacemaker.service pacemaker_remote.service
> 
> [Service]
> Restart=no
> 
> # systemctl cat virtlockd.socket
> # /usr/lib/systemd/system/virtlockd.socket
> [Unit]
> Description=Virtual machine lock manager socket
> Before=libvirtd.service
> 
> [Socket]
> ListenStream=/run/libvirt/virtlockd-sock
> SocketMode=0600
> 
> [Install]
> WantedBy=sockets.target
> 
> # /usr/lib/systemd/system/virtlockd-admin.socket
> [Unit]
> Description=Virtual machine lock manager admin socket
> Before=libvirtd.service
> BindsTo=virtlockd.socket
> After=virtlockd.socket
> 
> [Socket]
> ListenStream=/run/libvirt/virtlockd-admin-sock
> Service=virtlockd.service
> SocketMode=0600
> 
> [Install]
> WantedBy=sockets.target
> 
> To make things worse: libvirtd also requires virtlockd:
> 
> # systemctl cat libvirtd.service
> # /usr/lib/systemd/system/libvirtd.service
> [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 
> 
> [Service]
> Type=notify
> EnvironmentFile=-/etc/sysconfig/libvirtd
> ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS
> ExecReload=/bin/kill -HUP $MAINPID
> KillMode=process
> Restart=on-failure
> # At least 1 FD per guest, often 2 (eg qemu monitor + qemu agent).
> # eg if we want to support 4096 guests, we'll typically need 8192 FDs
> # If changing this, also consider virtlogd.service & virtlockd.service
> # limits which are also related to number of guests
> LimitNOFILE=8192
>

[systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-03 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 03.02.2021 um 19:13 in
Nachricht :
> 02.02.2021 12:43, Ulrich Windl пишет:
>> Hi!
>> 
>> Having:
>> ---
>> # /usr/lib/systemd/system/virtlockd.service
>> [Unit]
>> Description=Virtual machine lock manager
>> Requires=virtlockd.socket
>> Requires=virtlockd-admin.socket
> 
> That's always wrong with After for the same units unless you can prove
> that both socket units are always ordered Before service unit due to
> dependency chain, at least if intention is to ensure socket units are
> active *before* service unit. In real life nobody notices it because
> both sockets are started much earlier which papers over race condition.
> 
> And if after 10 years of software existence everyone still gets it wrong
> I strongly suspect something is not right with software, not with everyone.
> 
>> Before=libvirtd.service
>> ...
>> ---
>> 
>> How would I start both sockets successfully unter program control?
> 
> I do not understand what you want to say here, sorry. What "program
> control" means? What exactly are you trying to do?

"program control" means "start"/"stop" vs. automatic control via
"enable"/"disable".

> 
>> If I start one socket, I cannot start the other without an error (as 
> libvirtd.service is running already, see my earlier message from last
week).
> 
> I do not see how starting socket unit is related to starting service
> unit. Unless there was incoming traffic on socket. Also I do not
> understand why you need to start socket units if you *already* started
> service unit. Again, you do not really provide much coherent information
> to do any suggestion.

I had provided the full units yesterday. Basically I don't know what to do: I
just want to start the service and its sockets at a specific point in time and
also want to stop those at another time.

> 
> And I do not really understand the reason to use two different socket
> units that apparently are always started together and activate the same
> service. Just create single socket unit that listens on both sockets.

It seems the service has a config file that specified which sockets to use,
and some magic has to activate/deactivate the corresponding socket units.
(BTW: You can find a corresponding question at serverfault since yesterday)

> 
>> If I mask the socket units, I cannot start the libvirtd.service.
>> So would I disable the socket units and start libvirtd.service?
> 
> You misunderstand what "disable" means in systemd (see remark above).
> You cannot disable (in common sense) starting of socket units together
> with virtlockd.service because starting of virtlockd.service will always
> attempt to start both socket units (that is exactly what Requires/Wants
> are about).

That would be OK, but I don't want that the socket units get activated by some
otherm echanism I still haven't identified.

> 
> Actually if they are "enabled" (in systemd sense) then they are started
> very early during boot, long before service unit. What exact problem you
> have in this case?

Pacemaker cluster provides a shared filesystem, so the units should not be
started before that filesystem is mounted.
Sounds simple, but systemd seems to make this hard to impossible.

Regards,
Ulrich

> 
>> Unfortunately if someone (update when vendor-preset is enabled) re-enables

> the socket units, it would break things, so I tried to mask them, but that 
> failed, too.
>> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.
>> 
>> Regards,
>> Ulrich
>> 
>> 
>> 
>> 
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Antw: [EXT] Limitation on maximum number of systemd timers that can be active

2021-02-03 Thread Ulrich Windl
>>> "P.R.Dinesh"  schrieb am 03.02.2021 um 07:46 in 
>>> Nachricht
:
> Do we have any limitation on the maximum number of systemd timers / units
> that can be active in the system?
> Will it consume high cpu/memory if we configure 1000s of systemd timers?

What about trying? Probably depends on your machine.

> 
> -- 
> With Kind Regards,
> P R Dinesh




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


[systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-03 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 02.02.2021 um 15:59
in
Nachricht <20210202145954.GB36677@gardel-login>:
> On Di, 02.02.21 10:43, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Having:
>> ‑‑‑
>> # /usr/lib/systemd/system/virtlockd.service
>> [Unit]
>> Description=Virtual machine lock manager
>> Requires=virtlockd.socket
>> Requires=virtlockd‑admin.socket
>> Before=libvirtd.service
>> ...
>> ‑‑‑
>>
>> How would I start both sockets successfully unter program control?
>> If I start one socket, I cannot start the other without an error (as 
> libvirtd.service is running already, see my earlier message from last
week).
>> If I mask the socket units, I cannot start the libvirtd.service.
>> So would I disable the socket units and start libvirtd.service?
>> Unfortunately if someone (update when vendor‑preset is enabled) re‑enables
the 
> socket units, it would break things, so I tried to mask them, but that 
> failed, too.
>> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.
> 
> I don't grok what you are trying to say, the excerpt of the unit file
> is too short. Please provide the relevant parts of the other unit
> files too.

So you get it:


# systemctl cat virtlockd.service
# /usr/lib/systemd/system/virtlockd.service
[Unit]
Description=Virtual machine lock manager
Requires=virtlockd.socket
Requires=virtlockd-admin.socket
Before=libvirtd.service
Documentation=man:virtlockd(8)
Documentation=https://libvirt.org 

[Service]
EnvironmentFile=-/etc/sysconfig/virtlockd
ExecStart=/usr/sbin/virtlockd $VIRTLOCKD_ARGS
ExecReload=/bin/kill -USR1 $MAINPID
# Loosing the locks is a really bad thing that will
# cause the machine to be fenced (rebooted), so make
# sure we discourage OOM killer
OOMScoreAdjust=-900
# Needs to allow for max guests * average disks per guest
# libvirtd.service written to expect 4096 guests, so if we
# allow for 10 disks per guest, we get:
LimitNOFILE=40960

[Install]
Also=virtlockd.socket

# /run/systemd/system/virtlockd.service.d/50-pacemaker.conf
[Unit]
Description=Cluster Controlled virtlockd
Before=pacemaker.service pacemaker_remote.service

[Service]
Restart=no

# systemctl cat virtlockd.socket
# /usr/lib/systemd/system/virtlockd.socket
[Unit]
Description=Virtual machine lock manager socket
Before=libvirtd.service

[Socket]
ListenStream=/run/libvirt/virtlockd-sock
SocketMode=0600

[Install]
WantedBy=sockets.target

# /usr/lib/systemd/system/virtlockd-admin.socket
[Unit]
Description=Virtual machine lock manager admin socket
Before=libvirtd.service
BindsTo=virtlockd.socket
After=virtlockd.socket

[Socket]
ListenStream=/run/libvirt/virtlockd-admin-sock
Service=virtlockd.service
SocketMode=0600

[Install]
WantedBy=sockets.target

To make things worse: libvirtd also requires virtlockd:

# systemctl cat libvirtd.service
# /usr/lib/systemd/system/libvirtd.service
[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 

[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/libvirtd
ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
# At least 1 FD per guest, often 2 (eg qemu monitor + qemu agent).
# eg if we want to support 4096 guests, we'll typically need 8192 FDs
# If changing this, also consider virtlogd.service & virtlockd.service
# limits which are also related to number of guests
LimitNOFILE=8192
# The cgroups pids controller can limit the number of tasks started by
# the daemon, which can limit the number of domains for some hypervisors.
# A conservative default of 8 tasks per guest results in a TasksMax of
# 32k to support 4096 guests.
TasksMax=32768

[Install]
WantedBy=multi-user.target
Also=virtlockd.socket
Also=virtlogd.socket
Also=libvirtd.socket
Also=libvirtd-ro.socket

# systemctl cat libvirtd.socket
# /usr/lib/systemd/system/libvirtd.socket
[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

[Install]
WantedBy=sockets.target

# systemctl cat libvirtd-admin.socket
#

[systemd-devel] Still confused with socket activation

2021-02-02 Thread Ulrich Windl
Hi!

Having:
---
# /usr/lib/systemd/system/virtlockd.service
[Unit]
Description=Virtual machine lock manager
Requires=virtlockd.socket
Requires=virtlockd-admin.socket
Before=libvirtd.service
...
---

How would I start both sockets successfully unter program control?
If I start one socket, I cannot start the other without an error (as 
libvirtd.service is running already, see my earlier message from last week).
If I mask the socket units, I cannot start the libvirtd.service.
So would I disable the socket units and start libvirtd.service?
Unfortunately if someone (update when vendor-preset is enabled) re-enables the 
socket units, it would break things, so I tried to mask them, but that failed, 
too.
error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is masked.

Regards,
Ulrich




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


[systemd-devel] Is it intentional that "systemctl cat" outputs "# /dev/null" for a masked unit?

2021-02-02 Thread Ulrich Windl
Well,

the subject says it all: I had masked a socket unit and the related 
non-socket-unit failed to start.
Trying to see the definition of the unit with "systemctl cat" I only saw "# 
/dev/null".
Is that intended? "systemctl show" still shows a lot of data...

My idea was when "unmask" knows how to get the unit, why shouldn't "cat" be 
able to, too?

(systemd-234-24.64.1.x86_64 of SLES15 SP2)

Regards,
Ulrich


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


[systemd-devel] Antw: [EXT] Re: Starting a socket unit that finds an active service fails

2021-01-31 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 29.01.2021 um 16:38
in
Nachricht <20210129153859.GA31189@gardel-login>:
> On Fr, 29.01.21 12:30, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> Hi!
>>
>> I wonder whether this is a bug:
>> When starting a socket unit that finds ist service active already, I get an

> error
>> systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already 
> active, refusing.
>> systemd[1]: Failed to listen on Libvirt TLS IP socket.
>>
>> When using systemd units in a pacemaker cluster this is fatal:
>> pacemaker-controld[7467]:  notice: Transition 316 action 81 
> (prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error'
>>
>> Maybe the special problem is that two socket units (libvirtd-ro.socket, 
> libvirtd-tls.socket) exist to start the same service (libvirtd.service).
>>
>> I'm clueless how to handle that. Ideas?
> 
> The socket activation logic works so that the activation sockets are
> passed to the service being activated during execve(). Thus, if a
> service is already running we can't pass in more sockets: you have to
> restart the service so that there's another execve() we can pass the
> newly started sockets over.
> 
> My guess is that your service — if it finds that it didn't get a
> socket passed in that it needs — just creates the socket itself as a
> fallback...
> 
> It's generally a good idea for services to have Requires= + After= on
> the sockets that actviate it, to make sure that the sockets are always
> started before the service itself, and the situation you are seeing
> cannot happen.

I think before running things from pacemaker,I started them in this order
libvirtd
libvirtd-ro
libvirtd-tls

And there was no problem (or I missed something).
Now with pacemaker I assumed that either libvirtd-ro or libvirtd-tls would
start libvirtd as needed with no explicit start of libvirtd.

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] Starting a socket unit that finds an active service fails

2021-01-29 Thread Ulrich Windl
Hi!

I wonder whether this is a bug:
When starting a socket unit that finds ist service active already, I get an 
error
systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already 
active, refusing.
systemd[1]: Failed to listen on Libvirt TLS IP socket.

When using systemd units in a pacemaker cluster this is fatal:
pacemaker-controld[7467]:  notice: Transition 316 action 81 
(prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error'

Maybe the special problem is that two socket units (libvirtd-ro.socket, 
libvirtd-tls.socket) exist to start the same service (libvirtd.service).

I'm clueless how to handle that. Ideas?

Regards,
Ulrich



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


[systemd-devel] Antw: [EXT] Re: successful mount starts a service - how?

2021-01-18 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 19.01.2021 um 06:30 in
Nachricht <3a365c71-004e-031e-4153-80c376d80...@gmail.com>:
> 19.01.2021 04:00, lejeczek пишет:
>> hi guys.
>> 
>> I'm fiddling with it but have run out of options/ideas.
>> What I would like to have is systemd starts a service when a device, in
>> my case a crypt-luks device, gets mounted which mount would happen by
>> manual 'cryptsetup open'
> 
> I am not aware that "cryptsetup open" mounts anything. I do not even see
> any option to specify mount point in its invocation. Please show exact
> command you are using that "mounts" encrypted container.

But it will make some device (/dev/mapper) to appear.

> 
>> I see when that manual action takes place then systemd changes status of
>> a home.mount (which is in fstab) to "active" - and it's here where I
>> hope systemd would auto-start a service.
>> Is such a "simple" thing possible?
>> many thanks, L
>> ___
>> 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 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-07 Thread Ulrich Windl
>>> Chris Murphy  schrieb am 06.01.2021 um 03:02 in
Nachricht
:
> On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi  wrote:
>>
>>
>> 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.
> 
> Hi,
> 
> This is too long for a desktop or laptop use case. It should be around
> 15‑20 seconds. It's completely reasonable for users to reach for the
> power button and force it off by 30 seconds.

Have you ever tried shutting down multiple virtual machines having disks on a
slow medium?

> 
> Fedora Workstation Working Group is tracking an issue expressly to get
> to around 20 seconds (or better).
> https://pagure.io/fedora‑workstation/issue/163 
> 
> It is a given there will be some kind of state or data loss by just
> forcing a shutdown. I think what we need is the console, revealed by
> ESC, needs to contain sufficient information on what and why the
> reboot/shutdown is being held back. So that we can figure out why
> those processes aren't terminating fast enough and get them fixed.

There may be bugs, and there may be processes that simply take time.

> 
> A journaled file system should just do log replay at the next mount
> and the file system itself will be fine. Fine means consistent. But

That's nonsense: I'd prefer to wait and NOT lose data.

> for overwriting file systems, files could be left in an in‑between
> state. It just depends on what's being written to and when and how. A
> COW file system can better survive an abrupt poweroff since nothing is
> being overwritten. But I'm skeptical just virtually pulling the power
> cord is such a great idea to depend on. And for offline updates, we'd
> want to inhibit the aggressive reboot/shutdown, to ensure updating is
> complete and all writes are on stable media.

I wonder how robust an LVM thin pool is when you shut off the power while
multiple LVs allocate blocks from it (just for an example).

> 
> But for the aggressive shutdown case, some way of forcing remount ro?
> Or possibly FIFREEZE/FITHAW?
> 
> Some boot/bootloader folks have asked fs devs for an atomic
> freeze+thaw ioctl, i.e. one that is guaranteed to return to thaw. But
> this has been rebuffed so far. While thaw seems superfluous for the
> use case under discussion, it's possible poweroff command will be
> blocked by the freeze. And the thaw itself can be blocked by the
> freeze, when sysroot is the file system being frozen.

Where would freeze actually help?

> 
> 
> ‑‑ 
> Chris Murphy
> ___
> 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: 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


[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] Q: (simple) socket activation

2020-12-17 Thread Ulrich Windl
Hi!

I have a simple question: For a socket-unit I have:
LISTENUNITACTIVATES
[::]: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.

Regards,
Ulrich



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


Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

2020-12-16 Thread Ulrich Windl
>>> Jarkko Sakkinen  schrieb am 15.12.2020 um 05:19 in
Nachricht
<20201215041903.ga21...@kernel.org>:
> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
>> >>> Topi Miettinen  schrieb am 11.12.2020 um 12:46 in
>> Nachricht
>> <27796c04-249e-6cf0-c3e1-0fd657a82...@gmail.com>:
>> > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>> >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>> >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>> >>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>> >>>>>>>> As  a further argument, I just did this on a Fedora system:
>> >>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
>> >>>>>>>> No results.  So making /dev noexec doesn't seem to have any
benefit.
>> >>>>>>>
>> >>>>>>> It's no surprise that there aren't any executables in /dev since
>> >>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that
>> >>>>>>> /dev is a writable directory (for UID=0 but no capabilities are
>> >>>>>>> needed) and thus a potential location for constructing unapproved
>> >>>>>>> executables if it is also mounted exec (W^X).
>> >>>>>>
>> >>>>>> UID 0 can just change mount options, though, unless SELinux or
similar
>> is 
>> > used. And SELinux can protect /dev just fine without noexec.
>> >>>>>
>> >>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
>> SELinux
>> >>>>> is not universal and the policies might not contain all users or
>> services.
>> >>>>>
>> >>>>> ‑Topi
>> >>>>
>> >>>> What's the data that supports having noexec /dev anyway? With root
>> >>>> access I can then just use something else like /dev/shm mount.
>> >>>>
>> >>>> Has there been out in the wild real world cases that noexec mount
>> >>>> of would have prevented?
>> >>>>
>> >>>> For me this sounds a lot just something that "feels more secure"
>> >>>> without any measurable benefit. Can you prove me wrong?
>> >>>
>> >>> I don't think security works that way. An attacker has various methods
to
>> >>> choose from, some are more interesting than others. The case where
>> rw,exec
>> >>> /dev would be interesting would imply that easier or more common
avenues
>> >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>> >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
>> approach
>> >>> with no need for any file system access is getting more common. It
does
>> not
>> >>> mean that it would not be prudent to block the relatively easy
approaches
>> >>> too, including /dev.
>> >> 
>> >> What if we add a new mount option "chrexec", which allows exec
>> >> for character devices (S_IFCHR).
>> > 
>> > I think devices are a bad match for SGX because devices haven't been 
>> > executable and SGX is actually an operation for memory. So something 
>> > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX) 
>> > would be much more natural. Even better would be something that 
>> > conceptully also works for AMD version (either with the same flags or 
>> > MFD_SGX / MFD_whatever_the_AMD_version_is).
>> 
>> +1
> 
> SGX reserved memory from kernel's point of view is IO memory.
> 
> Mapping SGX to memfd would not be a great idea, as it does not map
> into concept of anonymous file backed by regular memory.
> 
> A device file is very natural match actually. We have ioctl API for
> uploading enclave pages during the build procedure to the enclave and
> custom #PF handler. Conceptually it's a lot like video memory or such
> special device specific memory area.
> 
> There's no AMD equivalent of this technology.

Hi!

Back to "noexec": AFAIR the execute bit does not make sense for device files,
and the purpose probably was to avoid execution of non-device files (e.g.
regular executables) from inside /dev (where they should not be). So in this
view "noexec" makes sense.
There were similar arguments for not allowing device files in user
directories.

Regards,
Ulrich

> 
> /Jarkko



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


[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

2020-12-13 Thread Ulrich Windl
>>> Juan Guerrero  schrieb am 11.12.2020 um 13:31 
>>> in
Nachricht
:
> Good morning;
> 
> A question can someone help me with this issue: the file */proc/kcore* has
> a size of 140G. How can I fix it, I must restart the server or is there
> another way to solve it?
> kernel-uek-2.6.39-400.211.1.el6uek
> 
> evidence sections:
> 
> 1.- the size of the kcore file
> 
> 140737486266368 /proc/kcore

Here too, but what is the problem (1G RAM):
 # ll /proc/kcore
-r 1 root root 140737477885952 Dec 14 08:26 /proc/kcore



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


[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

2020-12-13 Thread Ulrich Windl
>>> Topi Miettinen  schrieb am 11.12.2020 um 12:46 in
Nachricht
<27796c04-249e-6cf0-c3e1-0fd657a82...@gmail.com>:
> On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
 On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
 As  a further argument, I just did this on a Fedora system:
 $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
 No results.  So making /dev noexec doesn't seem to have any benefit.
>>>
>>> It's no surprise that there aren't any executables in /dev since
>>> removing MAKEDEV ages ago. That's not the issue, which is that
>>> /dev is a writable directory (for UID=0 but no capabilities are
>>> needed) and thus a potential location for constructing unapproved
>>> executables if it is also mounted exec (W^X).
>>
>> UID 0 can just change mount options, though, unless SELinux or similar
is 
> used. And SELinux can protect /dev just fine without noexec.
>
> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
SELinux
> is not universal and the policies might not contain all users or
services.
>
> ‑Topi

 What's the data that supports having noexec /dev anyway? With root
 access I can then just use something else like /dev/shm mount.

 Has there been out in the wild real world cases that noexec mount
 of would have prevented?

 For me this sounds a lot just something that "feels more secure"
 without any measurable benefit. Can you prove me wrong?
>>>
>>> I don't think security works that way. An attacker has various methods to
>>> choose from, some are more interesting than others. The case where
rw,exec
>>> /dev would be interesting would imply that easier or more common avenues
>>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
approach
>>> with no need for any file system access is getting more common. It does
not
>>> mean that it would not be prudent to block the relatively easy approaches
>>> too, including /dev.
>> 
>> What if we add a new mount option "chrexec", which allows exec
>> for character devices (S_IFCHR).
> 
> I think devices are a bad match for SGX because devices haven't been 
> executable and SGX is actually an operation for memory. So something 
> like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX) 
> would be much more natural. Even better would be something that 
> conceptully also works for AMD version (either with the same flags or 
> MFD_SGX / MFD_whatever_the_AMD_version_is).

+1


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


[systemd-devel] Antw: [EXT] RFC: Moving fully to OpenSSL (aka. stopping support for gnutls/gcrypt)?

2020-12-09 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 09.12.2020 um 10:50
in
Nachricht <20201209095057.GA30977@gardel-login>:
> Heya!
> 
> Currently, some parts of the systemd tree link against OpenSSL, others
> link against gnutls and libgcrypt, and even others support either,
> controlled by a compile time switch.
> 
> This is of course less than ideal, since it means we need to maintain
> needlessly complex, redundant code to support this, it's not complete
> (as not all combinations are supported), and footprint for general
> purpose distros is effectively doubled.
> 
> I think we should go OpenSSL all the way, and replace/drop support for
> gnutls and libgcrypt, unifying on a single crypto library. This was
> previously problematic since on Debian linking LGPL code against
> OpenSSL was considered legally "unclean". This has recently changed
> though:

What about this:
Have a mechanism to select either gnutls or openssl for everything.
Then see how many people will use gnutls and how many will use openssl.
Then decide what to do.

> 
> https://github.com/systemd/systemd/pull/14743#issuecomment‑739001595 
> 
> Hence, given that the legal issues around going OpenSSL exclusively
> all the way are gone, I think it's time to do the full switch. Hence
> I'd like to propose that we start transitioning with depending only on
> OpenSSL sooner or later. This means:
> 
> 1. Porting the currently remaining GnuTLS/gcrypt‑only code over to openssl
> 
> 2. Dropping redundant implementations for gnutls/gcrypt where we
>already have openssl support
> 
> 3. Require for new code to be openssl‑only.
> 
> Ultimately this should provide us with a smaller codebase, smaller OS
> footprint and easier maintainance.
> 
> Before we make this decision and switch over I'd like to hear opinions
> on this, though. Maybe I am missing something, and there are other
> reasons why people want to keep gnutls/gcrypt support around?
> 
> Why unify on OpenSSL instead of doing it the other way and unify on
> gnutls + gcrypt, btw? We don't really have any horse in that race. All
> crypto libraries have well documented issues, like any code. It
> appears to me though that OpenSSL has the more active and larger
> community and wider industry support. It appears to me that dropping
> gntuls/gcrypt frrom the basic OS package set is easier to reach then
> dropping OpenSSL. In the interest of making the minimal set of OS
> packages required to boot a system smaller I think OpenSSL is the
> better choice.
> 
> The fabled future OpenSSL 3 release is supposed to come with a changed
> license, which will attack the Debian license incompatibility from
> another angle btw. It was supposed to be released many months ago
> already, afaiu, but that unfortunately never happened. So far we were
> counting on this to resolve the licensing situation around crypto
> libraries. Due to the Debian change I figure we can speed up things
> now, though.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: Creating executable device nodes in /dev?

2020-12-08 Thread Ulrich Windl
>>> Jarkko Sakkinen  schrieb am 09.12.2020 um 01:15 in 
>>> Nachricht
<20201209001521.ga64...@kernel.org>:

...
> 
> What's the data that supports having noexec /dev anyway? With root
> access I can then just use something else like /dev/shm mount.
> 
> Has there been out in the wild real world cases that noexec mount
> of would have prevented?
> 
> For me this sounds a lot just something that "feels more secure"
> without any measurable benefit. Can you prove me wrong?

I think the better question is: Why not allow it? I.e.: Why do you want to 
forbid it?

Event though I wouldn't like it myself, I could even think of noexec /tmp.

Regards,
Ulrich


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


[systemd-devel] Antw: [EXT] Timestamps in journal during suspend/resume

2020-12-01 Thread Ulrich Windl
Hi!

Seeing this before, my guess was that at some point the kernel message buffer
is frozen (not read). Then after resume the messages are read from the kernel
buffer and logged.

Ulrich

>>> Paul Menzel  schrieb am 01.12.2020
um
12:45 in Nachricht <45fb49dd-d57b-d6f9-a82a-fa4837527...@molgen.mpg.de>:
> Dear systemd folks,
> 
> 
> Using Debian sid/unstable with systemd 246.5, suspend and resuming a 
> Dell Precision 3540 the timestamps below can be seen.
> 
> ```
> Nov 28 19:58:47.516555 morley systemd[1]: Reached target Sleep.
> Nov 28 19:58:47.517585 morley systemd[1]: Starting Suspend...
> Nov 28 19:58:47.525240 morley systemd[1]: Stopping Atop advanced 
> performance monitor...
> Nov 28 19:58:47.603491 morley wpa_supplicant[690]: nl80211: deinit 
> ifname=p2p-dev-wlo1 disabled_11b_rates=0
> Nov 28 19:58:47.759586 morley systemd[1]: atop.service: Succeeded.
> Nov 28 19:58:47.759790 morley systemd[1]: Stopped Atop advanced 
> performance monitor.
> Nov 28 19:58:47.761552 morley systemd-sleep[15059]: Suspending system...
> Nov 28 19:58:47.762380 morley kernel: PM: suspend entry (s2idle)
> Nov 28 19:58:47.766488 morley wpa_supplicant[690]: nl80211: deinit 
> ifname=wlo1 disabled_11b_rates=0
> Nov 28 22:44:50.643707 morley kernel: Filesystems sync: 0.005 seconds
> Nov 28 22:44:50.646269 morley kernel: (NULL device *): firmware: 
> direct-loading firmware i915/kbl_dmc_ver1_04.bin
> Nov 28 22:44:50.646329 morley kernel: (NULL device *): firmware: 
> direct-loading firmware regulatory.db
> Nov 28 22:44:50.646359 morley kernel: (NULL device *): firmware: 
> direct-loading firmware regulatory.db.p7s
> Nov 28 22:44:50.646384 morley kernel: (NULL device *): firmware: 
> direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-46.ucode
> Nov 28 22:44:50.646417 morley kernel: Freezing user space processes ...
> Nov 28 22:44:50.646451 morley kernel: [drm] PCIE GART of 256M enabled 
> (table at 0x00F4).
> Nov 28 22:44:50.646479 morley kernel: [drm] UVD and UVD ENC initialized 
> successfully.
> Nov 28 22:44:50.646511 morley kernel: [drm] VCE initialized successfully.
> Nov 28 22:44:50.646543 morley kernel: (elapsed 0.494 seconds) done.
> Nov 28 22:44:50.646580 morley kernel: OOM killer disabled.
> Nov 28 22:44:50.646613 morley kernel: Freezing remaining freezable tasks 
> ... (elapsed 0.001 seconds) done.
> Nov 28 22:44:50.646646 morley kernel: printk: Suspending console(s) (use 
> no_console_suspend to debug)
> Nov 28 22:44:50.646667 morley kernel: e1000e: EEE TX LPI TIMER: 0011
> Nov 28 22:44:50.646688 morley kernel: ACPI: EC: interrupt blocked
> Nov 28 22:44:50.646710 morley kernel: ACPI: EC: interrupt unblocked
> Nov 28 22:44:50.646730 morley kernel: [drm] PCIE GART of 256M enabled 
> (table at 0x00F4).
> Nov 28 22:44:50.646747 morley kernel: [drm] UVD and UVD ENC initialized 
> successfully.
> Nov 28 22:44:50.646764 morley kernel: [drm] VCE initialized successfully.
> Nov 28 22:44:50.646781 morley kernel: OOM killer enabled.
> Nov 28 22:44:50.646799 morley kernel: Restarting tasks ... done.
> Nov 28 22:44:50.643826 morley rtkit-daemon[954]: The canary thread is 
> apparently starving. Taking action.
> Nov 28 22:44:50.646521 morley systemd-logind[688]: Lid opened.
> Nov 28 22:44:50.643833 morley rtkit-daemon[954]: Demoting known 
> real-time threads.
> ```
> 
> At least to me, some of the entries with timestamps from resuming should 
> have timestamps from suspending. Is the reason, that “suspend message“ 
> was only written to the journal after resume?
> 
> Is there a way to access the Linux kernel timestamp from within the
journal?
> 
> 
> Kind regards,
> 
> Paul
> ___
> 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] journalctl -f after restart of journald

2020-11-30 Thread Ulrich Windl
Hi!

I forgot: What I'd expect at least to see in the "old" journalctl -f is this
log message:
-- Logs begin at Wed 2020-11-25 11:27:53 CET. --
Nov 30 12:03:27 h19 systemd-journald[957]: Received SIGTERM from PID 1
(systemd).

Regards,
Ulrich

>>> "Ulrich Windl"  schrieb am 30.11.2020
um
12:08 in Nachricht <5fc4d2b902a10003d...@gwsmtp.uni-regensburg.de>:
> 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?
> 
> (systemd‑234‑24.64 of SLES15 SP2)
> 
> Regards,
> Ulrich
> 
> 
> 
> ___
> 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] journalctl -f after restart of journald

2020-11-30 Thread Ulrich Windl
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?

(systemd-234-24.64 of SLES15 SP2)

Regards,
Ulrich



___
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?

2020-11-23 Thread Ulrich Windl
>>> Vito Caputo  schrieb am 20.11.2020 um 20:09 in
Nachricht
<20201120190913.4t4dupzxrshon...@shells.gnugeneration.com>:
> On Fri, Nov 20, 2020 at 10:39:14AM +0100, Ulrich Windl 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. 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):
>> 
>> ### done after being called before, so the file contents should be cached 
> anyway.
>> # time journalctl ‑b |wc ‑l
>> 2018589
>> 
>> real0m21.890s
>> user0m19.053s
>> sys 0m3.292s
>> 
>> Reading all files to compare:
>>  # time cat /run/log/journal/e766c8d06f144b1588487221640f55b5/* |wc ‑l
>> 3203984
>> 
>> real0m0.729s
>> user0m0.135s
>> sys 0m0.962s
>> 
>>  # df /run
>> Filesystem 1K‑blocksUsed Available Use% Mounted on
>> tmpfs  131889480 1664768 130224712   2% /run
>> 
>> systemd‑234‑24.61.1.x86_64 from SLES15 SP2.
>> 
> 
> How big are the journal files and how many are there?

While trying to determine the sizes I made a very interesting observation:
While "wc -l" is fast (less than 1 second), "wc" (without "-l") takes more
than a minute!

 # time wc -l /run/log/journal/e766c8d06f144b1588487221640f55b5/*
126016 /run/log/journal/e766c8d06f144b1588487221640f55b5/system.journal
237547
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0001-0005b3f9b726314e.journal

289220
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0002626b-0005b3fdddc1ac31.journal

289962
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0004d777-0005b4052d952b37.journal

267185
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00074d19-0005b40c7f1e2c5b.journal

333123
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0009c2ad-0005b413d068abd6.journal

266936
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-000c37d4-0005b41b203c33eb.journal

237000
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-000ead24-0005b42270cb3177.journal

236427
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00112238-0005b429c0dd2e09.journal

236646
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-001396ea-0005b4310efb31c0.journal

231837
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00160b9a-0005b4385a2b3033.journal

226417
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00187e2a-0005b43e6ae73265.journal

226363
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-001af146-0005b443b238b0e1.journal

   3204679 total

real0m0.314s
user0m0.100s
sys 0m0.215s

# time wc /run/log/journal/e766c8d06f144b1588487221640f55b5/*
126016 831206   92274688
/run/log/journal/e766c8d06f144b1588487221640f55b5/system.journal
2375471275825  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0001-0005b3f9b726314e.journal

2892201335438  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0002626b-0005b3fdddc1ac31.journal

2899621411322  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0004d777-0005b4052d952b37.journal

2671851348136  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00074d19-0005b40c7f1e2c5b.journal

3331231602322  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-0009c2ad-0005b413d068abd6.journal

2669361463014  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-000c37d4-0005b41b203c33eb.journal

2370001226780  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-000ead24-0005b42270cb3177.journal

2364271196644  134217728
/run/log/journal/e766c8d06f144b1588487221640f55b5/system@43da9abd7ab542c1b67267b7b7bddd63-00112238-0005b429c0dd2e09.journal

2366461252991  134217728

[systemd-devel] Why is journalctl -b so slow?

2020-11-20 Thread Ulrich Windl
Hi!

journactl -b is quite fast to display the first lines, but when I want to see 
the last lines, it's quite slow. 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):

### done after being called before, so the file contents should be cached 
anyway.
# time journalctl -b |wc -l
2018589

real0m21.890s
user0m19.053s
sys 0m3.292s

Reading all files to compare:
 # time cat /run/log/journal/e766c8d06f144b1588487221640f55b5/* |wc -l
3203984

real0m0.729s
user0m0.135s
sys 0m0.962s

 # df /run
Filesystem 1K-blocksUsed Available Use% Mounted on
tmpfs  131889480 1664768 130224712   2% /run

systemd-234-24.61.1.x86_64 from SLES15 SP2.

Regards,
Ulrich


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


[systemd-devel] Antw: Antw: [EXT] Re: Journald retaining logs for only 10 days

2020-11-16 Thread Ulrich Windl
>>> "Ulrich Windl"  schrieb am 16.11.2020
um
08:18 in Nachricht <5fb227c402a10003c...@gwsmtp.uni-regensburg.de>:
>>>> Vito Caputo  schrieb am 14.11.2020 um 21:29 in
> Nachricht
> <20201114202930.x7wbx4p37bkkw...@shells.gnugeneration.com>:
>> On Sat, Nov 14, 2020 at 09:31:23AM +, Nikolaus Rath wrote:
>>> Hello,
>>> 
>>> I just discovered that on one of my systems journald only retains log
>>> entries for about 10 days:
>>> 
>>> # journalctl | head ‑1
>>> ‑‑ Logs begin at Wed 2020‑11‑04 15:57:13 UTC, end at Sat 2020‑11‑14
> 09:28:19 UTC. ‑‑
>>> 
>>> I do not understand what could cause this, because I have no retention
>>> limit configured, and the logs take up way less space than I have
>>> reserved:
>>> 
>>> # journalctl ‑‑disk‑usage
>>> Archived and active journals take up 320.0M in the file system.
>>> 
>>> # journalctl > alllogs
>>> # ls ‑lh alllogs 
>>> ‑rw‑r‑‑r‑‑ 1 root root 27M Nov 14 09:24 alllogs
>>> 
>>> 
>>> Can someone help me understand where the log entries have gone?
>>> 
>>> # journalctl ‑‑version
>>> systemd 241 (241)
>>> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP

>> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD ‑IDN2 +IDN
> ‑PCRE2 
>> default‑hierarchy=hybrid
>>> 
>>> # grep ‑vE '^#' /etc/systemd/journald.conf 
>>> 
>>> [Journal]
>>> SystemMaxUse=300M
>>> 
>>> 
>> 
>> One thing to consider is journald allocates space per‑file in 8MiB
>> increments.
> 
> Why that? Because disk space is cheap? 8MB of text log files is a really 
> huge
> amount of lines.
> For example here I have about 9500 lines in 860MB; that would be about
92500

Oops: 850kB, of course!

> lines for 8MB.
> 
>> 
>> On my laptop for example, there are 27 user journals, 8MiB each, where
>> the last object offset is around 2MiB.  This alone burns ~162MiB in
>> allocated but unused space.
>> 
>> We should probably have some lower level tooling for scrutinizing the
>> journal files and reporting how much of the space is actually used vs.
>> fallocated.
>> 
>> Regards,
>> Vito Caputo
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Antw: [EXT] Re: Journald retaining logs for only 10 days

2020-11-15 Thread Ulrich Windl
>>> Vito Caputo  schrieb am 14.11.2020 um 21:29 in
Nachricht
<20201114202930.x7wbx4p37bkkw...@shells.gnugeneration.com>:
> On Sat, Nov 14, 2020 at 09:31:23AM +, Nikolaus Rath wrote:
>> Hello,
>> 
>> I just discovered that on one of my systems journald only retains log
>> entries for about 10 days:
>> 
>> # journalctl | head ‑1
>> ‑‑ Logs begin at Wed 2020‑11‑04 15:57:13 UTC, end at Sat 2020‑11‑14
09:28:19 UTC. ‑‑
>> 
>> I do not understand what could cause this, because I have no retention
>> limit configured, and the logs take up way less space than I have
>> reserved:
>> 
>> # journalctl ‑‑disk‑usage
>> Archived and active journals take up 320.0M in the file system.
>> 
>> # journalctl > alllogs
>> # ls ‑lh alllogs 
>> ‑rw‑r‑‑r‑‑ 1 root root 27M Nov 14 09:24 alllogs
>> 
>> 
>> Can someone help me understand where the log entries have gone?
>> 
>> # journalctl ‑‑version
>> systemd 241 (241)
>> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD ‑IDN2 +IDN
‑PCRE2 
> default‑hierarchy=hybrid
>> 
>> # grep ‑vE '^#' /etc/systemd/journald.conf 
>> 
>> [Journal]
>> SystemMaxUse=300M
>> 
>> 
> 
> One thing to consider is journald allocates space per‑file in 8MiB
> increments.

Why that? Because disk space is cheap? 8MB of text log files is a really huge
amount of lines.
For example here I have about 9500 lines in 860MB; that would be about 92500
lines for 8MB.

> 
> On my laptop for example, there are 27 user journals, 8MiB each, where
> the last object offset is around 2MiB.  This alone burns ~162MiB in
> allocated but unused space.
> 
> We should probably have some lower level tooling for scrutinizing the
> journal files and reporting how much of the space is actually used vs.
> fallocated.
> 
> Regards,
> Vito Caputo
> ___
> 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] [SPECIFICATION RFC] The firmware and bootloader log specification

2020-11-15 Thread Ulrich Windl
>>> Daniel Kiper  schrieb am 14.11.2020 um 00:52 in
Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>:
...
> The members of struct bf_log_msg:
>   ‑ size: total size of bf_log_msg struct,
>   ‑ ts_nsec: timestamp expressed in nanoseconds starting from 0,

Who or what defines t == 0?
...

Regards,
Ulrich Windl

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


[systemd-devel] Antw: [EXT] Re: date/time set to epoch when using readonly rootfs

2020-10-26 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 23.10.2020 um 13:00
in
Nachricht <20201023110051.GA326204@gardel-login>:
> On Fr, 23.10.20 10:37, Belisko Marek (marek.beli...@gmail.com) wrote:
> 
>> > > Sorry I mixed up things. Can you pls guide where can I find code which
>> > > set date/time from timestamp? Thanks
>> >
>> > This is the stuff PID 1 calls during earliest boot:
>> >
>> >
https://github.com/systemd/systemd/blob/master/src/shared/clock‑util.c#L147

>> Thanks a lot. I found an issue. The build system set config flag
>> ‑time‑epoch=0 (reason was to avoid performing fsck on every boot when
>> inavlid date/time is detected for boards which don't have rtc [0])
>> and this resulted in date 1.1.1970.
> 
> All RH‑based distro have patched the time check out of e2fsck since a
> long time. In particular in RTC‑less systems it sounds like a very
> poor idea to leave that in. The right fix is certainly to remove this
> behaviour from fsck, and not to force an unnecessarily wrong time.

Hi!

I don't know, but: Can't the time-based check be disabled by tuning the fs
("-i0"), or is there a special condition for "time zero"?
Also: Doesn't mean "fsck" a "journal replay" (read: very fast) these days?

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: Suppressing spam error messages in the system journal

2020-10-22 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 22.10.2020 um 18:49 in
Nachricht <9af67357-feaa-e1c7-291e-afe5f48e8...@thelounge.net>:

> 
> Am 22.10.20 um 16:55 schrieb Dave Howorth:
>> On Thu, 22 Oct 2020 15:27:58 +0200
>> Reindl Harald  wrote:
>>> Am 22.10.20 um 12:59 schrieb Lennart Poettering:
 On Do, 22.10.20 11:11, David C. Partridge
 (david.partri...@perdrix.co.uk) wrote:
>>> 1) Is there any way in journald.conf to perform a
>>> message
> suppression
>>> similar to the one I used for syslog? If not should there be
>>> one?
>   
>> No.
>
> Does that mean no there isn't and also that there should not be,
> or are you open to considering allowing a suppression mechanism
> similar to that available in rsyslogd?

 Not a fan of such hacks. Fix the programs or filter during display,
 don't suppress at time of collection.
>>>
>>> it's not a matter of fan or not
>>>
>>> it just makes sense to filter out things one *never* want to see at
>>> all instead store it
>> 
>> I think Lennart's point is that whatever happened to cause something in
>> the system to make a log entry happened, and that should be recorded.
>> Even though you may never want to see such evidence somebody, somewhere
>> might want it as part of an investigation, so it's better that it's
>> captured and preserved. The space will eventually be reclaimed so
>> there's no harm done.
>> 
>> And as he suggests, if you never want to see it, then filter it out on
>> display.
> 
> different mindshapes which shouldn't even need a long discussion, there 
> are people with different preferences and it's not too hard to implement 
> a filter
> 
> nobody needs to use it
> it's not in use as default
> 
> i personally hate it that i have to apply filters at display time again 
> and again for stuff i don't care about
> 
> a lot fo software logs informational stuff nobody cares most of the time 
> and all that noise burries rellay relevant stuff ‑ in the best case i 
> don't see anything at all in logs which don't need attention

It seems to be the trend of time to store everything you get, just in case one
could need it at a later time...

> 
> again: if there is a config everyone is happy
> 
> ___
> 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: btrfs raid not ready but systemd tries to mount it anyway

2020-10-19 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 16.10.2020 um 17:51
in
Nachricht <20201016155115.GB319022@gardel-login>:
> On Fr, 16.10.20 17:45, Lennart Poettering (lenn...@poettering.net) wrote:
> 
>> > 2. Debugging with "rd.udev.debug systemd.log_level=debug":
>> > The same 10 HDD BTRFS volume with 4 drives connected to the motherboard
>> > and 6 drives connected to the HBA *fails* to mount automatically at boot
>> > time. The log for this with "rd.udev.debug systemd.log_level=debug" set
>> > in grub is here:
>> >
>> > 
>
https://drive.google.com/file/d/1jVHjAQ8CY9vABtM2giPTB6XeZCclm7R-/view?usp=sh

> aring
>>
>> Ths btrfs udev rule file appears to be missing in the initrd. The
>> block devices with the btrfs file systems on them will thus be marked
>> ready in systemd instantly instead of being delayed until all other
>> devices of the same btrfs fs have shown up in udev too.
>>
>> Fix your initrd.
> 
> So my educated guess is that this is a dracut bug: it excludes the
> btrfs udev rule file from the initrd unless the root fs is btrfs.

...which should be OK IMHO: Once root is mounted you should have anything you
need

> 
> But this doesn't work, because the absence of that file means that all
> btrfs file systems will be marked as ready instantly as they appear,
> which then blows up later if during later boot btrfs file systems that
> are backed by multiple devices shall be mounted.

IMHO that's a bug in systemd.

> 
> It's basically a race: if yor block devices appear in the initrd
> already, then you lost, because all such devices will be instantly be
> marked "ready to be mounted" because the udev rule file is missing
> there. However, if the block devices take longer to appear, and are
> thus first seen after the initrd→host transition, then all will be
> good, as the udev rules file for it exists there, and the devices are
> not marked ready until all necessary devices have shown up in udev.
> 
> Fix is: dracut should just include the file unconditionally. It's
> tiny.
> 
> If it really really insist to not include it on systems where btrfs isn't
> used, then it should scan the host for any btrfs use at all. it's not
> sufficient to determine whether the rootfs is btrfs or not.
> 
> Anyway, please report to dracut.
> 
> 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] Re: "Eye Of Cylon" animation no longer garbles Ctrl-Alt-F9 emergency shell ?

2020-10-16 Thread Ulrich Windl
>>> fox  schrieb am 15.10.2020 um 23:36 in Nachricht
:
>> > It is refreshing to see that the Cylon eye is appearantly no longer
>>> making the Ctrl-Alt-F9 emergency shell unusable.
> 
> while I noted that a modified systemd is quick to install, I also should 
> point out that a compile + install from systemd sourcecode may leave old 
> version parts on harddisk.

I guess this is where package managers come in... ;-)

> On Arch / Manjaro, journald gave me errormessages from leftover 
> generators.
> 
> fix: delete all files in  /usr/lib/systemd/system-generators/
> then reinstall systemd via your distro’s package manager.
> 
> This reduced error messages in journald quite a bit here. several 
> outdated generators  could not call their libs and what not.
> On some distros other than Fedora you still might want to patch out that 
> gimmicky "Eye Of Cylon" notifier to keep the Ctrl-Alt-F9 "emergency 
> shell" clean.
> ___
> 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] Re: Q: shutdown messages and the lack of such

2020-10-09 Thread Ulrich Windl
>>> Dave Howorth  schrieb am 08.10.2020 um 17:44 in
Nachricht <20201008164428.55bcf...@acer-suse.lan>:
> On Thu, 08 Oct 2020 14:29:24 +
> fox  wrote:
>> > I wonder: Shouldn't here be an infiormational message at least when
>> > the shutdown command is entered, and at least a notice message when
>> > the actual shutdown time has arrived?

As the above may be confusing: I'm talking about syslog, not wall there.

>> > If you review syslog laternot at all obvious what had happened.  
>> 
>> 
>> shutdown [OPTIONS...] [TIME] [WALL...]
>> 
>> Note that to specify a wall message you must specify a time argument, 
>> too.
>> ‑‑no‑wall #  Do not send wall message before halt, power‑off, reboot.
>> 
>> so, "shutdown now" # has an implicit   ‑‑no‑wall
>> 
>> seems it acts according to specs.
> 
> I think Ulrich's point was that the docs for previous versions of
> shutdown were consistent with its behaviour, which was to send a wall
> message and you could customise the message by supplying a command line
> argument.
> 
> It appears that the systemctl implementation has changed the behaviour,
> and the documentation. Whether there is a spec anywhere (POSIX or
> whatever) I do not know ‑ but certainly a man page is not a spec. Nor
> do I know whether this was a deliberate and publically agreed change
> in behaviour or something else.
> ___
> 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] Q: shutdown messages and the lack of such

2020-10-09 Thread Ulrich Windl
>>> fox  schrieb am 08.10.2020 um 16:29 in Nachricht
<78d3cbcf17099224becfcd371ebb0...@firemail.cc>:

>> I wonder: Shouldn't here be an infiormational message at least when
>> the shutdown command is entered, and at least a notice message when
>> the actual shutdown time has arrived?
>> If you review syslog laternot at all obvious what had happened.
> 
> 
> shutdown [OPTIONS...] [TIME] [WALL...]
> 
> Note that to specify a wall message you must specify a time argument, 
> too.
> ‑‑no‑wall #  Do not send wall message before halt, power‑off, reboot.
> 
> so, "shutdown now" # has an implicit   ‑‑no‑wall
> 
> seems it acts according to specs.

What "specs", "systemd specs"?

Besides that there wer two complaints: 1: No wall message, 2:nosyslog message

> ___
> 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] Q: shutdown messages and the lack of such

2020-10-08 Thread Ulrich Windl
Hi!

I hadn't used shutdown without "now" for a long time, but to day I did:
I was surprised about the messages: In traditional UNIX shutdown would announce 
the shutdown using wall messages. With systemd (in SLES12 SP5 this time) there 
was no message sent to the users and even in the journal the first message 
simply was:
systemd-logind[16681]: Creating /run/nologin, blocking further logins...
The processes magically stopped and the session was closed.

I wonder: Shouldn't here be an infiormational message at least when the 
shutdown command is entered, and at least a notice message when the actual 
shutdown time has arrived?
If you review syslog laternot at all obvious what had happened.

Regards,
Ulrich


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


[systemd-devel] Antw: Antw: [EXT] Re: Q on serial-getty

2020-10-08 Thread Ulrich Windl
>>> "Ulrich Windl"  schrieb am 08.10.2020
um
08:07 in Nachricht <5f7eac8b02a10003b...@gwsmtp.uni-regensburg.de>:
>>>> Silvio Knizek  schrieb am 07.10.2020 um 21:17 in
> Nachricht :
>> Am Mittwoch, den 07.10.2020, 08:49 +0200 schrieb Ulrich Windl:
>>> Hi!
>>>
>>> I'm thinking of configuring a serial getty in SLES15 (systemd‑234). First
I
> 
>> found that there is no manual page describing the service, and second if I

>> use "systemctl show serial‑getty" ("systemctl show serial‑getty@" does not

>> work), I get some "funny" numbers:
>>>
>>> ...
>>> UID=4294967295
>>> GID=4294967295
>>> ...
>>> MemoryCurrent=18446744073709551615
>>> CPUUsageNSec=18446744073709551615
>>> TasksCurrent=18446744073709551615
>>> IPIngressBytes=18446744073709551615
>>> IPIngressPackets=18446744073709551615
>>> IPEgressBytes=18446744073709551615
>>> IPEgressPackets=18446744073709551615
>>> ...
>>> CPUWeight=18446744073709551615
>>> StartupCPUWeight=18446744073709551615
>>> CPUShares=18446744073709551615
>>> StartupCPUShares=18446744073709551615
>>> ...
>>>
>>> Obviously that number is the unsigned 64‑bit representation of ‑1, but 
>> considering that no such service is running, the output looks quite odd.
>>> If ‑1 means "unknown", why not use that string, or if it means
"unlimited",
> 
>> why not use that string?
>>>
>>> Regards,
>>> Ulrich
>> 
>> Hi Ulrich,
>> 
>> have you already tried `systemctl help serial‑getty@foo.service` (yes,
>> instanciatable units need a instance token, even if useless)? This
>> should open some documentation.
> 
> Hi!
> 
> (You never stop learning)
> I didn't know about that. Amazingly "systemctl help serial-getty@*" just
did
> not output anything (bit it set the exit code to 1), but "systemctl help

s/bit/but/

> serial-getty@x" did.
> 
> (My expecation would be that any program that is not a test program should
> output something to stderr when exiting with non-zero)
> 
>> Also, for the serial getty actually a generator is used to
>> automatically start it, if already requested by the boot loader and
>> kernel command line. See man:systemd‑getty‑generator(8) and
>> http://0pointer.de/blog/projects/serial‑console.html for more
>> information.
> 
> Thanks a lot for all that!
> 
> Regards,
> Ulrich
> 
>> 
>> BR
>> Silvio
>> 
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Antw: [EXT] Re: Q on serial-getty

2020-10-08 Thread Ulrich Windl
>>> Silvio Knizek  schrieb am 07.10.2020 um 21:17 in
Nachricht :
> Am Mittwoch, den 07.10.2020, 08:49 +0200 schrieb Ulrich Windl:
>> Hi!
>>
>> I'm thinking of configuring a serial getty in SLES15 (systemd‑234). First I

> found that there is no manual page describing the service, and second if I 
> use "systemctl show serial‑getty" ("systemctl show serial‑getty@" does not 
> work), I get some "funny" numbers:
>>
>> ...
>> UID=4294967295
>> GID=4294967295
>> ...
>> MemoryCurrent=18446744073709551615
>> CPUUsageNSec=18446744073709551615
>> TasksCurrent=18446744073709551615
>> IPIngressBytes=18446744073709551615
>> IPIngressPackets=18446744073709551615
>> IPEgressBytes=18446744073709551615
>> IPEgressPackets=18446744073709551615
>> ...
>> CPUWeight=18446744073709551615
>> StartupCPUWeight=18446744073709551615
>> CPUShares=18446744073709551615
>> StartupCPUShares=18446744073709551615
>> ...
>>
>> Obviously that number is the unsigned 64‑bit representation of ‑1, but 
> considering that no such service is running, the output looks quite odd.
>> If ‑1 means "unknown", why not use that string, or if it means "unlimited",

> why not use that string?
>>
>> Regards,
>> Ulrich
> 
> Hi Ulrich,
> 
> have you already tried `systemctl help serial‑getty@foo.service` (yes,
> instanciatable units need a instance token, even if useless)? This
> should open some documentation.

Hi!

(You never stop learning)
I didn't know about that. Amazingly "systemctl help serial-getty@*" just did
not output anything (bit it set the exit code to 1), but "systemctl help
serial-getty@x" did.

(My expecation would be that any program that is not a test program should
output something to stderr when exiting with non-zero)

> Also, for the serial getty actually a generator is used to
> automatically start it, if already requested by the boot loader and
> kernel command line. See man:systemd‑getty‑generator(8) and
> http://0pointer.de/blog/projects/serial‑console.html for more
> information.

Thanks a lot for all that!

Regards,
Ulrich

> 
> BR
> Silvio
> 
> ___
> 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 on serial-getty

2020-10-07 Thread Ulrich Windl
>>> Mantas Mikulenas  schrieb am 07.10.2020 um 08:56 in
Nachricht
:
> On Wed, Oct 7, 2020 at 9:49 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>> Hi!
>>
>> I'm thinking of configuring a serial getty in SLES15 (systemd-234). First
>> I found that there is no manual page describing the service, and second if
>> I use "systemctl show serial-getty" ("systemctl show serial-getty@" does
>> not work), I get some "funny" numbers:
>>
>> ...
>> UID=4294967295
>> GID=4294967295
>> ...
>> MemoryCurrent=18446744073709551615
>> CPUUsageNSec=18446744073709551615
>> TasksCurrent=18446744073709551615
>> IPIngressBytes=18446744073709551615
>> IPIngressPackets=18446744073709551615
>> IPEgressBytes=18446744073709551615
>> IPEgressPackets=18446744073709551615
>> ...
>> CPUWeight=18446744073709551615
>> StartupCPUWeight=18446744073709551615
>> CPUShares=18446744073709551615
>> StartupCPUShares=18446744073709551615
>> ...
>>
>> Obviously that number is the unsigned 64-bit representation of -1, but
>> considering that no such service is running, the output looks quite odd.
>> If -1 means "unknown", why not use that string, or if it means
>> "unlimited", why not use that string?
>>
> 
> This was fixed in systemd-235 several years ago.
> https://github.com/systemd/systemd/commit/21771f338d268e06dc9a10b9b08b14ff82

> 17d4be
> 

Thanks, good to know.

> -- 
> Mantas Mikulėnas



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


[systemd-devel] Q on serial-getty

2020-10-07 Thread Ulrich Windl
Hi!

I'm thinking of configuring a serial getty in SLES15 (systemd-234). First I 
found that there is no manual page describing the service, and second if I use 
"systemctl show serial-getty" ("systemctl show serial-getty@" does not work), I 
get some "funny" numbers:

...
UID=4294967295
GID=4294967295
...
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
TasksCurrent=18446744073709551615
IPIngressBytes=18446744073709551615
IPIngressPackets=18446744073709551615
IPEgressBytes=18446744073709551615
IPEgressPackets=18446744073709551615
...
CPUWeight=18446744073709551615
StartupCPUWeight=18446744073709551615
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
...

Obviously that number is the unsigned 64-bit representation of -1, but 
considering that no such service is running, the output looks quite odd.
If -1 means "unknown", why not use that string, or if it means "unlimited", why 
not use that string?

Regards,
Ulrich




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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Q: logrotate and "systemctl kill -s HUP ..."

2020-10-06 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 01.10.2020 um 09:22
in
Nachricht <20201001072237.GB301913@gardel-login>:
> On Mi, 30.09.20 12:52, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Thanks for the suggestions. Before I work them out, I have a simple
question
>> (systemd‑228 of SLES12):
>> Systemd loggs quite a lot; does it log a message when it sends a signal to
a
>> process (or fails to do so)? If so it would help to isolate the problem. I
>> could not see any message, so my guess is that the test for the PID file 
> does
>> not work as intended.
> 
> We do not log about killed processes like that no. It was supposed to
> be a work‑alike to the venerable unix kill comand which doesn't log
> about this either.
> 
> That said, it might make sense to change that, at least log at debug
> level. Please file an RFE issue on github asking for this to be added,
> and we'll add it when we find the time to.

#17254

> 
> "systemctl status" should tell you what systemd considers to be the
> main pid of a service however, verify that it points to the right
> process. The "systemctl kill" line you are using really just then
> sends a signal to that one process.
> 
> 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: Q: logrotate and "systemctl kill -s HUP ..."

2020-09-30 Thread Ulrich Windl
>>> Mantas Mikulenas  schrieb am 30.09.2020 um 12:26 in
Nachricht
:
> On Wed, Sep 30, 2020 at 11:24 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>> Hi!
>>
>> I have a problem with logrotate: My postrotate command does not seem to
>> send a HUP signal. However the files are rotated.
>> I'm using this (not preferred way, I know):
>>
>> ...
>> postrotate
>> test -s '/var/run/iotwatch-LOC1/iotwatch-LOC1.pid' &&
>> systemctl kill -s HUP --kill-who=main iotwatch@LOC1.service 
>> endscript
>> ...
>>
>> I've verified that the PID file exists (just rebooted the server a few
>> minutes ago):
>> # ll /var/run/iotwatch-LOC1/iotwatch-LOC1.pid
>> -rw-r--r-- 1 root root 5 Sep 30 10:07
>> /var/run/iotwatch-LOC1/iotwatch-LOC1.pid
>>
> 
> Do you need to check for it in the first place?
> 
> Does the same command work from interactive CLI?
> 
> 
>>
>> My service would log the arrival of any HUP signal, but it didn't. Also in
>> syslog I could not find any error message related to "systemctl kill".
>> What might be wrong?
>>
>> My service is using ExecStartPre, ExecStartPost, and ExecStart. Could
>> systemd be confused about "--kill-who=main" then?
> 
> 
> --kill-who=main means the signal will be sent to the "main" process that
> was started from ExecStart (shown as "Main PID:" in systemctl status).
> 
> The more preferred way of doing this is to have "ExecReload=/bin/kill -HUP
> $MAINPID" and then `systemctl reload foo.service`.
> 
> Sending HUP to ExecStartPre and ExecStartPost doesn't make sense, since
> those are supposed to be short-running commands – they are not allowed to
> actually *have* daemons.

Hi!

Thanks for the suggestions. Before I work them out, I have a simple question
(systemd-228 of SLES12):
Systemd loggs quite a lot; does it log a message when it sends a signal to a
process (or fails to do so)? If so it would help to isolate the problem. I
could not see any message, so my guess is that the test for the PID file does
not work as intended.

However the dosc says:
  The lines between postrotate and endscript (both of  which 
must
  appear  on  lines  by  themselves)  are executed (using
/bin/sh)
  after the log file is rotated.

So the "&&" should work, but maybe a backslash is needed at the end of the
line (it is not when entering the command interactively).

Regards,
Ulrich


> 
> -- 
> Mantas Mikulėnas



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


[systemd-devel] Antw: Re: Antw: Re: Antw: [EXT] Re: Memory in systemctl status

2020-09-30 Thread Ulrich Windl
>>> Benjamin Berg  schrieb am 30.09.2020 um 12:08 in
Nachricht <2f6a1d5b102e5dade4f578d6d704b07508d03d50.ca...@sipsolutions.net>:
> On Wed, 2020-09-30 at 11:04 +0200, Ulrich Windl wrote:
>> > > > Reindl Harald  schrieb am 30.09.2020 um 10:56 
>> > > > in
>> Nachricht :
>> 
>> > Am 30.09.20 um 09:06 schrieb Ulrich Windl:
>> > > > my webserver is killed because it served at monday, tuesday, thursday
>> > > > and friday 4 different files with 2 GB?
>> > > 
>> > > cgroups is for limiting resources, not for killing processes AFAIK
>> > 
>> > [Service]
>> > MemoryMax=4G
>> > 
>> > would call OOM killer
>> 
>> Are you sure? I thought OOM is called when the _system_ memory is exhausted.
>> IMHO any memory allocation request to the process will be denied, but the
>> process wouldn't be killed. But agreed, I didn't track the cgroups changes 
> in
>> the last few years.
> 
> I think you can assume that the OOM killer will kick in rather than the
> allocation request being denied.
> 
> This option does cap the amount system memory that is used for the
> cgroup. So if memory cannot be reclaimed (e.g. swapped out, file
> backed) then the OOM killer will run within the cgroup.

OK, didn't know the OOM killer is cgroup-specific

> 
> As I understand it, what Reindl is looking for is seeing and limiting
> the amount of resident anonymous pages that the cgroup has rather than
> its real memory use.
> 
> Benjamin




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


[systemd-devel] Antw: Re: Antw: [EXT] Re: Memory in systemctl status

2020-09-30 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 30.09.2020 um 10:56 in
Nachricht :

> 
> Am 30.09.20 um 09:06 schrieb Ulrich Windl:
>>> my webserver is killed because it served at monday, tuesday, thursday
>>> and friday 4 different files with 2 GB?
>> 
>> cgroups is for limiting resources, not for killing processes AFAIK
> 
> [Service]
> MemoryMax=4G
> 
> would call OOM killer

Are you sure? I thought OOM is called when the _system_ memory is exhausted.
IMHO any memory allocation request to the process will be denied, but the
process wouldn't be killed. But agreed, I didn't track the cgroups changes in
the last few years.

> ___
> 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] Q: logrotate and "systemctl kill -s HUP ..."

2020-09-30 Thread Ulrich Windl
Hi!

I have a problem with logrotate: My postrotate command does not seem to send a 
HUP signal. However the files are rotated.
I'm using this (not preferred way, I know):

...
postrotate
test -s '/var/run/iotwatch-LOC1/iotwatch-LOC1.pid' &&
systemctl kill -s HUP --kill-who=main iotwatch@LOC1.service 
endscript
...

I've verified that the PID file exists (just rebooted the server a few minutes 
ago):
# ll /var/run/iotwatch-LOC1/iotwatch-LOC1.pid
-rw-r--r-- 1 root root 5 Sep 30 10:07 /var/run/iotwatch-LOC1/iotwatch-LOC1.pid

My service would log the arrival of any HUP signal, but it didn't. Also in 
syslog I could not find any error message related to "systemctl kill".
What might be wrong?

My service is using ExecStartPre, ExecStartPost, and ExecStart. Could systemd 
be confused about "--kill-who=main" then?

Regards,
Ulrich



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


[systemd-devel] How to reply to the list

2020-09-30 Thread Ulrich Windl
>>> Dave Howorth  schrieb am 28.09.2020 um 16:34 in
Nachricht <20200928153422.6bf6e...@acer-suse.lan>:
> On Mon, 28 Sep 2020 14:10:38 +0200
> Reindl Harald  wrote:
>> can you stop "reply‑all" and breaking threads when respond to lists?
> 
> I can't answer for the reply‑all, that would annoy me as well.
> But the thread isn't broken, my MUA is showing it nicely.

Also: Some MUAs only have "reply" and "Reply to all"; the first one would only
reply to the sender, and the last one would reply to list and sender.
Interestingly for some lists a plain "Reply" works just right, but not for this
list. Please do not assume everybody is using the same MUA than you do...

> ___
> 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: Memory in systemctl status

2020-09-30 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 28.09.2020 um 11:37 in
Nachricht <0e47024a-faeb-bb78-9b08-fdfad2a23...@thelounge.net>:

> 
> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
>>> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
>>> caches are accounted in that context
>> 
>> No, the kernel kicks in and reclaims memory at that point. Which can
>> mean either swapping or just dropping caches.
> 
> caches have *nothing* to do with the service itself
> 
>> It really sounds to me like ulimit fits better what you are trying to
>> do. That is available through Limit*=, see systemd.exec.
> 
> hell first i want a output in "systemctl status whatever" which is true
> and don't contain a ISO image downloaded by someone two days ago
> 
> not more and not less
> 
> httpd don't use 8.7 GB RAM - period

Are you really sure about that? I haven't checked apache recently, but years
ago, static content was memory-mapped for performance reasons.

> 
> the only interesting memory is RES of all the processes
> 
> my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that
> and even if the latest download of a 10 GB file is somewhere in the OS
> caches in case it's opened later - it's *free* memory
> 
>  Main PID: 713 (httpd)
> Tasks: 16 (limit: 1024)
>Memory: 8.7G
>   CPU: 2h 24min 14.348s
>CGroup: /system.slice/httpd.service
>├─713 /usr/sbin/httpd -D FOREGROUND
>├─2435242 /usr/sbin/httpd -D FOREGROUND
>├─2435243 /usr/sbin/httpd -D FOREGROUND
>├─2435931 /usr/sbin/httpd -D FOREGROUND
>├─2435942 /usr/sbin/httpd -D FOREGROUND
>├─2435944 /usr/sbin/httpd -D FOREGROUND
>├─2435947 /usr/sbin/httpd -D FOREGROUND
>├─2435948 /usr/sbin/httpd -D FOREGROUND
>├─2435952 /usr/sbin/httpd -D FOREGROUND
>├─2435954 /usr/sbin/httpd -D FOREGROUND
>├─2435960 /usr/sbin/httpd -D FOREGROUND
>├─2435966 /usr/sbin/httpd -D FOREGROUND
>├─2435968 /usr/sbin/httpd -D FOREGROUND
>├─2435969 /usr/sbin/httpd -D FOREGROUND
>├─2435970 /usr/sbin/httpd -D FOREGROUND
>└─2435972 /usr/sbin/httpd -D FOREGROUND
> ___
> 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] Re: Memory in systemctl status

2020-09-30 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 28.09.2020 um 10:08 in
Nachricht <5b087cb0-9588-56db-1955-522ac9a6b...@thelounge.net>:

> 
> Am 27.09.20 um 23:39 schrieb Benjamin Berg:
> however, that value makes little to no sense and if that's the same
> value as accounted for "MemoryMax" it's plain wrong
>> But it does make sense. File caches are part of the working set of
>> memory that a process needs. Setting MemoryMax=/MemoryMin=
>> limits/guarantees the size of this working set. These kinds of limits
>> or protections would be a lot less meaningful if caches were not
>> accounted for.
> 
> sorry but that is complete nosense
> 
> caches are freed as soon whatever process asks for RAM and so they are
> *not* part of the working set
> 
> that kind of limits are completly useless when i would limit a service
> to 4 GB but because it served a few million different files within the
> last weeks which are accounted to it's cache and working set it's now
> killed?

Actually there are valid reasons to limit the amount of cache a process may
allocate. For example when a process creates a lot of dirty buffers quickly
(e.g. writing to a slow disk), it may cause a read-stall for the whole system.

> 
> my webserver is killed because it served at monday, tuesday, thursday
> and friday 4 different files with 2 GB?

cgroups is for limiting resources, not for killing processes AFAIK.

> 
> frankly my webserver can't even do anything against caching of teh VFS
> layer and is not responsible at all nor do other services
> 
> BTW: stop "reply‑all" to mailing‑lists
> ___
> 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: Start a unit n minutes after a successful boot

2020-09-09 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 08.09.2020 um 16:19
in
Nachricht <20200908141953.GB272516@gardel-login>:
> On Di, 08.09.20 09:21, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Configuring a new system with non‑redundant system disk I'm
>> wondering: How could I start an automatic backup job that is
>> triggered n minutes after the system started successfully (to avoid
>> backing up broken configurations)?
> 
> What does "started successfully" mean to you?

Definitely not "rescue shell" or "emergency mode" and most likely no failed
services for some time. Something like that.

> 
> 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: Alias use in socket file

2020-09-09 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 08.09.2020 um 16:04
in
Nachricht <20200908140433.GC272410@gardel-login>:
> On Di, 08.09.20 08:45, Belisko Marek (marek.beli...@gmail.com) wrote:
> 
>> Hi,
>>
>> I'm using yocto build systemd and I'm using openssh server which
>> create sshd.socket + sshd@.service files. With socket I can control if
>> ssh is enabled / disabled. I have an application which expects to
>> check statu of ssh.service. I tried to add Alias=ssh.service to
>> sshd.socket file and tried systemd enable sshd.socket but systemd
>> cannot see ssh.service. Is there some other way to create a link to an
>> existing socket file? Thanks
> 
> No, systemd refuses to recognize unit symlinks that change unit type
> (i.e. the unit suffix after the dot) as aliases. It also doesn't
> accept symlinks that change if a unit is templated or not. Objects
> can't magically change their type, and they cannot suddenly
> become/stop being templated or not.

Never tried such, but I hope there is a good error message when such links are
being ignored or denied ;-)

> 
> Sorry,
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> 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: Re: [EXT] Re: Using timedatectl on a readonly rootfile system using mender

2020-09-09 Thread Ulrich Windl
>>> Shravan Singh  schrieb am 08.09.2020 um 15:31 in
Nachricht
:
> No one is answering a simple question. Why we have to guard timezone so
> much?.
> Why can't I change it? What happens if I change it on a read-only rootfs? I
> am breaking the whole systemd by doing this?
> 
> In fact most of the people in this group are suggesting a work-around to me
> 
> "I wonder: If you have a working pull request, why don't you use that code
> and be happy with it? That's how free software works.
> Still everybody interested can apply you patch."
> 
> Yes, it works. My question is why is not getting included so that everyone
> can benefit from it. That is how a free software community should work.

I think the poroble is: You think your patch is great and everybody wants that. 
However you are not everybody, and so you have to let others decide whether 
they like the feature or not. Many times dome developers thing a feature is 
great, but it actually fails. Just think of the user interface of Windows 8...

> 
> In this day and age of mobile computing it is really shocking to see. That
> timezone is not regarded as something that can be dynamically changed.

You are mixing things: With your android phone you can change timezones, but 
you have created a special setup where anothe rspecial patch is needed. A bit 
like first shooting your own foot and then calling for a doctor, wondering why 
not everybody is needing a doctor...

This is just my opinion, not everybodys. ;-)

Regards,
Ulrich

> 
> Anyway this issue is going no-further if people are adamant in not changing
> it.
> And I don't see any reason in going back and forth with everyone.
> 
> 
> Regards,
> Shravan Singh
> (239) 243-0838
> 
> Blue Sparq, Inc.
> 928 NE 24th Lane unit 4 and 5.
> Cape Coral, FL 33993
> 
> IMPORTANT: The contents of this email and any attachments are confidential.
> They are intended for the named recipient(s) only. If you have received
> this email by mistake, please notify the sender immediately and do not
> disclose the contents to anyone or make copies thereof.
> 
> 
> On Mon, Sep 7, 2020 at 4:49 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>> >>> Shravan Singh  schrieb am 05.09.2020 um 00:26
>> in
>> Nachricht
>> :
>> > And this is a major problem for any one running raspberry pi, NXP or any
>> > other embedded processor that uses mender and embedded linux.
>>
>> Maybe an embedded OS really should use UTC as timezone.
>>
>> > A machine with embedded linux running on it goes to San Francisco and
>> then
>> > transported to Chicago.
>> > And you are saying that we shouldn't be allowed to change the timezone?
>>
>> The question is : Who will "see" the timezone? Does every process run with
>> the same timezone?
>>
>> > Just because you are not "convinced"
>> > Does this group have a poll system? Let's put this to poll and see?
>>
>> I wonder: If you have a working pull request, why don't you use that code
>> and be happy with it? That's how free software works.
>> Still everybody interested can apply you patch.
>> >
>> > I have tried having a rational explanation with you but your attitude is
>> > just appalling
>> >
>> > I have tried this solution and it works
>> > https://github.com/systemd/systemd/pull/8277.
>> > I just don't understand why you are not willing to accept this. And
>> provide
>> > a solution to all the people using raspberry pi and or embedded
>> processors?
>> >
>> >
>> >
>> >
>> > Regards,
>> > Shravan Singh
>> > (239) 243-0838
>> >
>> > Blue Sparq, Inc.
>> > 928 NE 24th Lane unit 4 and 5.
>> > Cape Coral, FL 33993
>> >
>> > IMPORTANT: The contents of this email and any attachments are
>> confidential.
>> > They are intended for the named recipient(s) only. If you have received
>> > this email by mistake, please notify the sender immediately and do not
>> > disclose the contents to anyone or make copies thereof.
>> >
>> >
>> > On Fri, Sep 4, 2020 at 6:16 PM Shravan Singh 
>> wrote:
>> >
>> >> What constitutes a configuration?
>> >> And please read my email subject. I can't have writable /etc, mender
>> >> dosen't allow that.
>> >>
>> >> In today's mobile computing age you really think users shouldn't change
>> >> timezone?
>> >> You keep saying " I for one am certainly not convinced that the
>> timezones&

[systemd-devel] Antw: [EXT] Initialization of "vbuf" in function "token_match_attr"

2020-09-08 Thread Ulrich Windl
Hi!

vbuf is initialized: It has some address on the stack, so "if (value != vbuf)" 
is comparing adresses, if I got it right...

>>> Amit anand  schrieb am 08.09.2020 um 13:56 in 
>>> Nachricht
:
> Hi systemd-devel team,
> 
> I am trying to understand where "vbuf" is initialized in function
> "token_match_attr()" in file udev-rules.c
> 
> Below code snippet :
> static bool* token_match_attr*(UdevRuleToken *token, sd_device *dev,
> UdevEvent *event) {
>  *char* nbuf[UTIL_NAME_SIZE], *vbuf*[UTIL_NAME_SIZE]; // Here, vbuf is
> defined, however not initialized.
> *const char* *name, **value;*// Here, value is declared to be of
> type const char *, however, not initialized.
> ...
> ... // some code
> ...
> switch (token->attr_subst_type) {   // *Event 1* : This evaluates to
> SUBST_TYPE_PLAIN
> ...
> case *SUBST_TYPE_PLAIN*:   if (sd_device_get_sysattr_value(dev, name,
> ) < 0)   // *Event 2* :The if condition evaluates to false.
>  return false;
>  break;
> ...// some code
> ...
> }
> 
> if (token->attr_match_remove_trailing_whitespace) {  // *Event
> 4*: If condition evaluates to true
> if (value != vbuf) {  //  *Event 5* : vbuf and value
> are both declared but not initialized. Comparison is done without
> initializing "vbuf" and "value".
> strscpy(vbuf, sizeof(vbuf), value);
> value = vbuf;
> } // End of if.
> 
> delete_trailing_chars(vbuf, NULL); // *Event 6*:
> trying to delete trailing chars from "vbuf" which is not initialzed. ??
> } // End of outer if.
> ... // some code
> } /End of function : *token_match_attr()*
> 
> Below are my queries :
> 1. *Event 5 *above, we are comparing two resources ("value" and "vbuf")
> even before initializing them.
> Are we doing this comparision to do decision making based on whether
> the pointer type variable "value" is pointing to "vbuf" or not.
> *Query*: Kindly confirm whether my understanding is correct.
> 
> 2. *Event 6* above, delete_trailing_chars(vbuf, NULL) is called outside  *if
> (value != vbuf).*
> This implies there may occur a situation where:
>   step 1 ) *if (value != vbuf) *condition fails  --> step 2 )
> *vbuf* is not initialzed inside the *if(value != vbuf)  *--> step 3 )
> delete_trailing_chars(*vbuf*, NULL).
> Here, delete_trailing_chars() called for "*vbuf*" which is not necessarily
> initiazlied.
> *Query*: Kindly let me know if my understanding is correct or I am missing
> something.
> 
> Thanks,
> Amit




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


[systemd-devel] Antw: [EXT] Re: Q: Start a unit n minutes after a successful boot

2020-09-08 Thread Ulrich Windl
>>> Tomasz Torcz  schrieb am 08.09.2020 um 09:58 in
Nachricht
<20200908075833.ga46...@mother.pipebreaker.pl>:
> On Tue, Sep 08, 2020 at 09:21:02AM +0200, Ulrich Windl wrote:
>> Hi!
>> 
>> Configuring a new system with non‑redundant system disk I'm wondering:
>> How could I start an automatic backup job that is triggered n minutes
>> after the system started successfully (to avoid backing up broken
>> configurations)?
> 
>   Timer with "OnBootSec=n minutes" is exactly what you want, right? 

Hi!

Is every boot a successful boot? Will (e.g.) default.target be reached even if
some service failed? If not, that is what I had in mind:
Start a unit n minutes after default.target was reached "sucessfully".

> 
> For judging if boot was successfull there are different approaches.
> On my Fedora I see user unit with timer activating after 2 minutes. 
> If user session lasted for that long, then
> ExecStart=/usr/sbin/grub2‑set‑bootflag boot_success
> is invoked. There were some discussion on this mailinglist how to
> improve detection and marking of good boot..

Assuming a good boot is a boot that lasts at least 2 minutes is silently
assuming that some human will reboot before if the boot was not sucessful?

Regards,
Ulrich

> 
> ‑‑ 
> Tomasz TorczOnce you've read the dictionary,
> to...@pipebreaker.plevery other book is just a remix.
> ___
> 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


  1   2   3   4   >