Re: [systemd-devel] Configurability for systemd logging API

[SF Markus Elfring]

>> Such messages correspond to specific data structures.
>> * The log origin and log level are repeated there while the recorded
>>   information might occasionally not be detailed enough.
>>   I find that such details can be better handled by the software build 
>> system.
…
> I appreciate you wanting to help, but this is not helpful.

Thanks for your feedback.


> Please post patches if you have suggestions for improvements.

I find that the change acceptance is unclear for fine-tuning of this software
also around message log programming interfaces.
Which design approaches do you find acceptable for further considerations?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] behavior of stop in case of multiple processes

[Andrei Borzenkov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

В Wed, 29 Jul 2015 21:17:18 +0200
Michał Zegan  пишет:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello.
> 
> I am trying to use systemd to run wildfly application server. It is
> being run by a shell script that runs a java vm in a separate process.
> So, killing the script does not kill the other process.
> The service is a simple type service, and I am wondering what happens
> there on stop. when the server receives signal sigint or sigterm
> directly it logs some messages about it being stopped. However, when I
> start it and then stop, this does not happen, i get no message as if
> it was killed by sigkill.
> What may happen? the documentation says that the systemd sends sigterm
> to all processes by default (if KillMode=control-group and this is
> probably default), and then sigkill if processes do not respond for a
> configured amount of time.
> In this case sigterm sent to the shell script (the main process)
> causes it to exit, but then appserver is probably sigkilled.
> I know that setting sendSIGKILL to no makes it shudown normally. What
> is going on?

Could you post your unit file and which version of systemd?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlW5m74ACgkQR6LMutpd94xHcgCgquo2XGHk348JRxeXcUHJR/yu
fjcAoJrusCMl/PHMI69cmx2A0p4gkPfV
=qtmw
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for experiences formalizing an API for journal messages

[Daurnimator]

On 23 July 2015 at 23:17, Anne Mulhern  wrote:
> Hi!
>
> We all know that using the journald native API it is possible to enrich the 
> log
> entry data w/ key/value pairs, although this facility is Linux only.
> The set of key/value pairs which a message may log to the journal can
> constitute an API with which a logging entity can communicate alerts to 
> consumers
> of this information. Clearly this requires an agreement on an API between the 
> logging
> entity and the consumer of the journal entries.
>
> Are there existing projects that have used this facility in a principled,
> coordinated way with some success or have there been any interesting failures
> along those same lines?
>
> Thanks for your help,
>
> - mulhern

The newer syslog standard (RFC 5424) defines a key/value area.
See https://tools.ietf.org/html/rfc5424#section-6.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for experiences formalizing an API for journal messages

[Dimitri John Ledkov]

On 29 July 2015 at 20:02, Anne Mulhern  wrote:
>
>
>
>
> - Original Message -
>> From: "Lennart Poettering" 
>> To: "Anne Mulhern" 
>> Cc: systemd-devel@lists.freedesktop.org
>> Sent: Thursday, July 23, 2015 9:21:44 AM
>> Subject: Re: [systemd-devel] Looking for experiences formalizing an API for 
>> journal messages
>>
>> On Thu, 23.07.15 09:17, Anne Mulhern (amulh...@redhat.com) wrote:
>>
>> > Hi!
>> >
>> > We all know that using the journald native API it is possible to enrich the
>> > log
>> > entry data w/ key/value pairs, although this facility is Linux only.
>> > The set of key/value pairs which a message may log to the journal can
>> > constitute an API with which a logging entity can communicate alerts to
>> > consumers
>> > of this information. Clearly this requires an agreement on an API between
>> > the logging
>> > entity and the consumer of the journal entries.
>> >
>> > Are there existing projects that have used this facility in a principled,
>> > coordinated way with some success or have there been any interesting
>> > failures
>> > along those same lines?
>>
>> systemd of courses uses its on its own, and we tried to document
>> the fields we use in systemd.journal-fields(7), though it might be
>> slightly incomplete.
>>
>> But yes, this is indeed API, and deserves complete documentation, like
>> any C API, any D-Bus API or a any REST API would need too.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>>
>
> What I'm wondering about is the existence of some processes (not systemd), 
> that have an
> agreement on a set of key-value pairs that they communicate with through the 
> journal.
>
> It seems like, even though there is a mechanism for adding additional 
> key/value pairs,
> regular expression matching is still kind of the norm.
>
> I was hoping for an inspiring counter example that uses mostly or exclusively 
> key/value
> pairs instead of expression matching, and maybe some hints as to best 
> practices.

I've heard of https://github.com/rsyslog/liblogging/tree/master/stdlog
but didn't look to deep into it. It supposed to do generic structured
logging for multiple destinations, one of them being journal. Maybe
it's of any help. I don't think that project is stable, nor widely
used at the moment.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Configurability for systemd logging API

[Tom Gundersen]

Hi Markus,

On Wed, Jul 29, 2015 at 8:54 PM, SF Markus Elfring
 wrote:
> Programs from the systemd software library output also some log messages
> as it is usual for such server applications.
>
> Such messages correspond to specific data structures.
> * The log origin and log level are repeated there while the recorded
>   information might occasionally not be detailed enough.
>   I find that such details can be better handled by the software build system.
>
> * The involved text repetition results in improvement possibilities
>   depending on preferred design directions.
>   Some substrings could be eventually shared between message variants
>   if this aspect can be selected as an optimisation goal
>   for the corresponding generation of executable software.
>   https://en.wikipedia.org/wiki/Longest_common_subsequence_problem

I appreciate you wanting to help, but this is not helpful. Please post
patches if you have suggestions for improvements.

Cheers,

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

[systemd-devel] behavior of stop in case of multiple processes

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I am trying to use systemd to run wildfly application server. It is
being run by a shell script that runs a java vm in a separate process.
So, killing the script does not kill the other process.
The service is a simple type service, and I am wondering what happens
there on stop. when the server receives signal sigint or sigterm
directly it logs some messages about it being stopped. However, when I
start it and then stop, this does not happen, i get no message as if
it was killed by sigkill.
What may happen? the documentation says that the systemd sends sigterm
to all processes by default (if KillMode=control-group and this is
probably default), and then sigkill if processes do not respond for a
configured amount of time.
In this case sigterm sent to the shell script (the main process)
causes it to exit, but then appserver is probably sigkilled.
I know that setting sendSIGKILL to no makes it shudown normally. What
is going on?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVuSa9AAoJEHb1CzgxXKwYUk8P/2mH7I9bRMGZaIKCBl2Kwgc3
SvzrmZBTzvMiCAQ8vEvOndMBieW1vecw6eXjp6bDJ44QIs0fmOFOxU0J3TJImu/i
Kq3QWB4yP+TacjHuo7rqfenNUOfLkSR+zaErLVfTLN5lOG/EbCN98awtCaSHygsX
jmd9yeWpSYp5Znhj4Fwb6cnQDzNKEMORbyllbFBIFwfC9HSPKiE97tfeDDqlEhZN
5wkIiLGc2BjXWzoYsrsdwPSvStEuXATqfN8/v3Bd+sMWHd1xVeLJS6kwlSdSkNOf
elfM+wp96UXYc6IzjgSWzwfRC7OcCgLiT+hARCSdD2AWpnDix/VVkFGTzYIinTVx
c/Oj0s4+fy7kImfqFb1QnCdD7MWTdIsIQqzYy2Kv9NUYo9amkhp0yzjFc/py9Te3
MEAmi8+vde0UV9plJZyXm/7QAIA627QE0V1++WI2HFF+dq4JUmgGCFEJfEq1dBUl
OjSStVm67mpMNCr1/4mJrjgsmxIdarZpa0J0/jVjJej+qrO5vvhDrpX4XDn4KUZ+
OKj0l/4L2mf3G6wrWV/+pBBp1Twav5gDBQg7LZR5Q8FyOTTWErVGP7yF0V/E5HON
RFjnnEyo5ew+mUCSl9MS1SdgZZRhNsKTAvZTVgXThdyxCusMXMGbG62+xJhRsEw3
yN7w3k1o8F18XDifyab/
=BoaG
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for experiences formalizing an API for journal messages

[Anne Mulhern]

- Original Message -
> From: "Lennart Poettering" 
> To: "Anne Mulhern" 
> Cc: systemd-devel@lists.freedesktop.org
> Sent: Thursday, July 23, 2015 9:21:44 AM
> Subject: Re: [systemd-devel] Looking for experiences formalizing an API for 
> journal messages
> 
> On Thu, 23.07.15 09:17, Anne Mulhern (amulh...@redhat.com) wrote:
> 
> > Hi!
> > 
> > We all know that using the journald native API it is possible to enrich the
> > log
> > entry data w/ key/value pairs, although this facility is Linux only.
> > The set of key/value pairs which a message may log to the journal can
> > constitute an API with which a logging entity can communicate alerts to
> > consumers
> > of this information. Clearly this requires an agreement on an API between
> > the logging
> > entity and the consumer of the journal entries.
> > 
> > Are there existing projects that have used this facility in a principled,
> > coordinated way with some success or have there been any interesting
> > failures
> > along those same lines?
> 
> systemd of courses uses its on its own, and we tried to document
> the fields we use in systemd.journal-fields(7), though it might be
> slightly incomplete.
> 
> But yes, this is indeed API, and deserves complete documentation, like
> any C API, any D-Bus API or a any REST API would need too.
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat
> 

What I'm wondering about is the existence of some processes (not systemd), that 
have an
agreement on a set of key-value pairs that they communicate with through the 
journal.

It seems like, even though there is a mechanism for adding additional key/value 
pairs,
regular expression matching is still kind of the norm.

I was hoping for an inspiring counter example that uses mostly or exclusively 
key/value
pairs instead of expression matching, and maybe some hints as to best practices.

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

[systemd-devel] Configurability for systemd logging API

[SF Markus Elfring]

Hello,

Programs from the systemd software library output also some log messages
as it is usual for such server applications.

Such messages correspond to specific data structures.
* The log origin and log level are repeated there while the recorded
  information might occasionally not be detailed enough.
  I find that such details can be better handled by the software build system.

* The involved text repetition results in improvement possibilities
  depending on preferred design directions.
  Some substrings could be eventually shared between message variants
  if this aspect can be selected as an optimisation goal
  for the corresponding generation of executable software.
  https://en.wikipedia.org/wiki/Longest_common_subsequence_problem

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kdbus, udev and systemd in the initramfs

[Tom Gundersen]

On Wed, Jul 29, 2015 at 2:23 PM, Michael Biebl  wrote:
> 2015-07-29 5:40 GMT+02:00 Tom Gundersen :
>> On Wed, Jul 29, 2015 at 1:21 AM, Michael Biebl  wrote:
>>> something I was wondering regarding kdbus and udev.
>>> If udev wants to drop the netlink transport and instead rely on kdbus,
>>> would this mean, systemd becomes mandatory in the initramfs to setup
>>> kdbus before udev is run?
>>
>> _If_ udev drops netlink entirely, then yes someone would need to set
>> up kdbus. How this will all look has not been finally decided yet
>> though.
>
> Is this documented somewhere, what kind of setup needs to be done for
> kdbus?

Well, kdbus itself is extensively documented in the kernel man pages
[0], but I'm not aware of any step-by-step documentation for how to
make an alternative kdbus userspace implementation. Probably your best
bet is to look at the systemd code.

> How complicated is it, to get kdbus up and running with a
> minimal environment like the initramfs?

In principle, not hugely complicated. However, probably not worth the
effort unless you have a good reason to. Wouldn't it be simpler to
just use systemd (even if just as a wrapper around your current
scripts)?

Either way, I probably wouldn't put any serious amount of work into
this just for the sake of udev quite yet. We still don't know
precisely how it will shake out. In general though, I would expect
that one day you'll want kdbus in the initramfs for one reason or
another.

Cheers,

Tom

[0]: 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd.conf 2015 Announcement and CfP

[Lennart Poettering]

Heya!

The first systemd conference, systemd.conf, will take place on
November 5th-7th, 2015 at betahaus in Berlin-Kreuzberg, Germany. The
systemd project is one of the core components of most of today’s Linux
distributions. At systemd.conf 2015 we will discuss the state and
future of the Linux core platform and plumbing. The intended audience
of the conference are developers, distribution packagers as well as
devops professionals. The conference will consist of presentations as
well as an extended hackfest.  

→ https://systemd.events/

Please Register for the Conference!

Only a limited number of tickets are available. If you plan on
attending the conference, please sign up soon. If you sign up
before August 16th, 2015, there’s an early-bird discount. A ticket
is required to attend the conference. Tickets are on sale at:

→ https://systemd.events/systemdconf-2015/registration

Call for Presentations

 We’d like to invite presentation proposals for systemd.conf
 2015. We are looking for talks including, but not limited to the
 following topics:

 - Use Cases: systemd in today’s and tomorrow’s devices and applications,
 - systemd and containers, in the cloud and on servers,
 - systemd in distributions,
 - Embedded systemd,
 - systemd on the desktop,
 - Networking with systemd,
 - D-Bus and kdbus IPC systems,
 - … and everything else related to systemd.

 Please submit your session proposals by August 31st, 2015 at:

 → https://systemd.events/systemdconf-2015/add/session

 We will notify submitters about proposal acceptance by
 September 15th, 2015.

 We will only accept presentations in English.

 More information about the CfP you may find on:
 
 → https://systemd.events/systemdconf-2015/call-presentations

Contact Us

 If you wish to receive more information as it becomes available,
 follow us at +systemd on Google+. If you have any questions
 please send us an email to info@systemd.events.

 For more information about systemd, please consult:

 → https://wiki.freedesktop.org/www/Software/systemd/

 For more information about systemd.conf 2015, please consult:

 → https://systemd.events/

Partners and Sponsoring

 systemd.conf 2015 is a cooperation of the systemd community and
 LinuxTag e. V. as organizing host.

 We are seeking corporate partners to help us create the best
 conference possible. Please visit
 https://systemd.events/systemdconf-2015/become-sponsor for more
 information on sponsoring systemd.conf 2015.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [ANNOUNCE] systemd v223

[David Herrmann]

Hi

Here's the next version of systemd, v223:

https://github.com/systemd/systemd/archive/v223.tar.gz

Many bug-fixes, code cleanups and some new additions to networkd and
resolved. As announced with the previous release, systemd-python has
been removed from upstream and now resides in its own repository:

https://github.com/systemd/python-systemd

CHANGES WITH 223:

* The python-systemd code has been removed from the systemd repository.
  A new repository has been created which accommodates the code from
  now on, and we kindly ask distributions to create a separate package
  for this: https://github.com/systemd/python-systemd

* The systemd daemon will now reload its main configuration
  (/etc/systemd/system.conf) on daemon-reload.

* sd-dhcp now exposes vendor specific extensions via
  sd_dhcp_lease_get_vendor_specific().

* systemd-networkd gained a number of new configuration options.

  - A new boolean configuration option for TAP devices called
'VNetHeader='. If set, the IFF_VNET_HDR flag is set for the
device, thus allowing to send and receive GSO packets.

  - A new tunnel configuration option called 'CopyDSCP='.
If enabled, the DSCP field of ip6 tunnels is copied into the
decapsulated packet.

  - A set of boolean bridge configuration options were added.
'UseBPDU=', 'HairPin=', 'FastLeave=', 'AllowPortToBeRoot=',
and 'UnicastFlood=' are now parsed by networkd and applied to the
respective bridge link device via the respective IFLA_BRPORT_*
netlink attribute.

  - A new string configuration option to override the hostname sent
to a DHCP server, called 'Hostname='. If set and 'SendHostname='
is true, networkd will use the configured hostname instead of the
system hostname when sending DHCP requests.

  - A new tunnel configuration option called 'IPv6FlowLabel='. If set,
networkd will configure the IPv6 flow-label of the tunnel device
according to RFC2460.

  - The 'macvtap' virtual network devices are now supported, similar to
the already supported 'macvlan' devices.

* systemd-resolved now implements RFC5452 to improve resilience against
  cache poisoning. Additionally, source port randomization is enabled
  by default to further protect against DNS spoofing attacks.

* nss-mymachines now supports translating UIDs and GIDs of running
  containers with user-namespaces enabled. If a container 'foo'
  translates a host uid 'UID' to the container uid 'TUID', then
  nss-mymachines will also map uid 'UID' to/from username 'vu-foo-TUID'
  (with 'foo' and 'TUID' replaced accordingly). Similarly, groups are
  mapped as 'vg-foo-TGID'.

Contributions from: Beniamino Galvani, cee1, Christian Hesse, Daniel
Buch, Daniel Mack, daurnimator, David Herrmann, Dimitri John Ledkov,
HATAYAMA Daisuke, Ivan Shapovalov, Jan Alexander Steffens (heftig),
Johan Ouwerkerk, Jose Carlos Venegas Munoz, Karel Zak, Kay Sievers,
Lennart Poettering, Lidong Zhong, Martin Pitt, Michael Biebl, Michael
Olbrich, Michal Schmidt, Michal Sekletar, Mike Gilbert, Namhyung Kim,
Nick Owens, Peter Hutterer, Richard Maw, Steven Allen, Sungbae Yoo,
Susant Sahani, Thomas Blume, Thomas Hindoe Paaboel Andersen, Tom
Gundersen, Torstein Husebø, Umut Tezduyar Lindskog, Vito Caputo,
Vivenzio Pagliari, Zbigniew Jędrzejewski-Szmek

-- Berlin, 2015-07-29
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Reverend Homer]

29.07.2015 14:40, SF Markus Elfring пишет:

This is *very* strange. The 'format' parameter should not contain that
"%s:%s:%d" prefix at all, as this cannot work of course because the
argument list doesn't match.

I guess that I wonder also about one of my own programming mistakes here.



Which version of systemd are you based on?

last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37



Do you have *any* local modifications in your tree?

Yes. - It seems that I was bitten by a format string mismatch during
an attempt to display a few more implementation details for my needs.


diff --git a/src/libsystemd/sd-device/device-private.c 
b/src/libsystemd/sd-device/device-private.c
index 2e60433..b5a31ec 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
  goto fail;
  }
  
-log_debug("created %s file '%s' for '%s'", has_info ? "db" : "empty",

+log_debug("%s:%s:%d: created %s file '%s' for '%s'", has_info ? "db" : 
"empty", __FUNCTION__, __FILE__, __LINE__,

I think that you mean

+log_debug("%s:%s:%d: created %s file '%s' for '%s'", __FUNCTION__, 
__FILE__, __LINE__,
has_info ? "db" : "empty",


path, device->devpath);
  
  return 0;




Should my compiler "gcc 5.2.0" be able to detect and warn about misplaced
parameters in such an use case?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
Regards,
R.H.

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

Re: [systemd-devel] kdbus, udev and systemd in the initramfs

[Michael Biebl]

2015-07-29 5:40 GMT+02:00 Tom Gundersen :
> On Wed, Jul 29, 2015 at 1:21 AM, Michael Biebl  wrote:
>> something I was wondering regarding kdbus and udev.
>> If udev wants to drop the netlink transport and instead rely on kdbus,
>> would this mean, systemd becomes mandatory in the initramfs to setup
>> kdbus before udev is run?
>
> _If_ udev drops netlink entirely, then yes someone would need to set
> up kdbus. How this will all look has not been finally decided yet
> though.

Is this documented somewhere, what kind of setup needs to be done for
kdbus? How complicated is it, to get kdbus up and running with a
minimal environment like the initramfs?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Daniel Mack]

On 07/29/2015 01:40 PM, SF Markus Elfring wrote:
>> Do you have *any* local modifications in your tree?
> 
> Yes. - It seems that I was bitten by a format string mismatch during
> an attempt to display a few more implementation details for my needs.
> 
> 
> diff --git a/src/libsystemd/sd-device/device-private.c 
> b/src/libsystemd/sd-device/device-private.c
> index 2e60433..b5a31ec 100644
> --- a/src/libsystemd/sd-device/device-private.c
> +++ b/src/libsystemd/sd-device/device-private.c
> @@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
>  goto fail;
>  }
>  
> -log_debug("created %s file '%s' for '%s'", has_info ? "db" : "empty",
> +log_debug("%s:%s:%d: created %s file '%s' for '%s'", has_info ? "db" 
> : "empty", __FUNCTION__, __FILE__, __LINE__,
>path, device->devpath);

Which is completely wrong, obviously.

> Should my compiler "gcc 5.2.0" be able to detect and warn about misplaced
> parameters in such an use case?

I'm sure you got a warning on this.

Such reports really waste our time, which is annoying.


Daniel

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

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[SF Markus Elfring]

> This is *very* strange. The 'format' parameter should not contain that
> "%s:%s:%d" prefix at all, as this cannot work of course because the
> argument list doesn't match.

I guess that I wonder also about one of my own programming mistakes here.


> Which version of systemd are you based on?

last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37


> Do you have *any* local modifications in your tree?

Yes. - It seems that I was bitten by a format string mismatch during
an attempt to display a few more implementation details for my needs.


diff --git a/src/libsystemd/sd-device/device-private.c 
b/src/libsystemd/sd-device/device-private.c
index 2e60433..b5a31ec 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
 goto fail;
 }
 
-log_debug("created %s file '%s' for '%s'", has_info ? "db" : "empty",
+log_debug("%s:%s:%d: created %s file '%s' for '%s'", has_info ? "db" : 
"empty", __FUNCTION__, __FILE__, __LINE__,
   path, device->devpath);
 
 return 0;



Should my compiler "gcc 5.2.0" be able to detect and warn about misplaced
parameters in such an use case?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Daniel Mack]

On 07/29/2015 10:06 AM, SF Markus Elfring wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x76fefc78 in vfprintf () from /lib64/libc.so.6
> (gdb) bt full
> #0  0x76fefc78 in vfprintf () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x77016f39 in vsnprintf () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x5559ac64 in log_internalv (level=7, error=0, 
> file=0x556118a0 
> "/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c",
>  
> line=1080, func=0x556124c0 <__func__.9471> "device_update_db",
> format=0x55611f40 "%s:%s:%d: created %s file '%s' for '%s'",
ap=0x7fffd760)
 ^

This is *very* strange. The 'format' parameter should not contain that
"%s:%s:%d" prefix at all, as this cannot work of course because the
argument list doesn't match. The source file and line are only added to
the journal entries via log_dispatch().

Also, "%s:%s:%d" does not appear anywhere in the source tree, and it
never did. ("git log -p | grep "%s:%s:%d" | wc -l").

Which version of systemd are you based on? Do you have *any* local
modifications in your tree?

*confused*


Daniel

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

[systemd-devel] How service can block login on tty

[Michal Sekletar]

Hi,

Fedora and RHEL both ship initial-setup services. If initial-setup is 
enabled then it must start *before* login is allowed.


Consider system which has multiple serial consoles attached then to 
achieve above initial-setup-text.service must have 
Before=serial-getty@ttyS0.service serial-getty@ttyS1.service explicitly 
specified in service file. Having to enumerate all possible instance 
names for serial-getty@.service is not practically possible. Thus, the 
question is $subject, but in generic way.


I think that introducing new target, e.g. getty-pre.target might be 
solution to this really generic problem. Now both getty@.service and 
serial-getty@.service have Before=getty.target. We would add 
After=getty-pre.target to those service files. Then getty-pre.target 
will have no explicit dependencies defined and will be pulled in to the 
transaction by service which wants to block login on tty, e.g. thus 
initial-setup-text.service will add Wants=getty-pre.target 
Before=getty-pre.target.


Does scheme described in last paragraph makes sense?

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

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[SF Markus Elfring]

> This should usually generate a coredump.

I have regenerated the current software on my test system.
last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37


Sonne:/home/elfring/Projekte/Bau/systemd # systemctl stop systemd-udevd.service 
systemd-udevd-kernel.socket systemd-udevd-control.socket && gdb ./systemd-udevd
GNU gdb (GDB; openSUSE Factory) 7.9
…
(gdb) set follow-fork-mode child
(gdb) set detach-on-fork off
(gdb) run --debug
Starting program: /home/elfring/Projekte/Bau/systemd/systemd-udevd --debug
…
restoring old watch on '/dev/dm-12'
adding watch on '/dev/dm-12'
seq 2638 queued, 'add' 'usb'
…
(gdb) set print inferior-events on
(gdb) info inferiors  
  Num  Description   Executable
* 3/usr/lib/udev/mtp-probe 
  2process 5759  /home/elfring/Projekte/Bau/systemd/systemd-udevd 
  1process 5751  /home/elfring/Projekte/Bau/systemd/systemd-udevd 
(gdb) inferior 2
(gdb) continue
Continuing.
'/usr/lib/udev/mtp-probe /sys/devices/pci:00/:00:02.0/usb3/3-2 3 
3'(out) '0'
Process '/usr/lib/udev/mtp-probe /sys/devices/pci:00/:00:02.0/usb3/3-2 
3 3' succeeded.
2638:udev_event_execute_rules:/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:896:
 add for 3-2
2638:udev_event_execute_rules:/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:905:
 owner set
2638:udev_node_add:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:342:
 handling device node '/dev/bus/usb/003/003', devnum=c189:258, mode=0664, 
uid=0, gid=7
2638:node_permissions_apply:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:281:
 set permissions /dev/bus/usb/003/003, 020664, uid=0, gid=7
2638:node_symlink:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:84: 
creating symlink '/dev/char/189:258' to '../bus/usb/003/003'

Program received signal SIGSEGV, Segmentation fault.
0x76fefc78 in vfprintf () from /lib64/libc.so.6
(gdb) bt full
#0  0x76fefc78 in vfprintf () from /lib64/libc.so.6
No symbol table info available.
#1  0x77016f39 in vsnprintf () from /lib64/libc.so.6
No symbol table info available.
#2  0x5559ac64 in log_internalv (level=7, error=0, file=0x556118a0 
"/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c",
 
line=1080, func=0x556124c0 <__func__.9471> "device_update_db", 
format=0x55611f40 "%s:%s:%d: created %s file '%s' for '%s'", 
ap=0x7fffd760)
at /home/elfring/Projekte/systemd/lokal/src/basic/log.c:662
_saved_errno_ = 0
buffer = "db:device_update_db:1432426656: created ", '\000' , 
"\221\367\275K2\375\244\300\317\377\377\377\177\000\000\241\252YUUU\000\000\000\000\000\000\000\000\000\000êYUUU\000\000\300\341_UUU\000\000\000\000\000\000\000\000\000\000\300\341_UUU\000\000\000\000\000\000\211\003\000\000
 \332_UUU\000\000\000\000\000\000"...
#3  0x5559ad9b in log_internal (level=7, error=0, file=0x556118a0 
"/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c",
 line=1080, 
func=0x556124c0 <__func__.9471> "device_update_db", 
format=0x55611f40 "%s:%s:%d: created %s file '%s' for '%s'")
at /home/elfring/Projekte/systemd/lokal/src/basic/log.c:679
ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 
0x7fffd860, reg_save_area = 0x7fffd780}}
r = 21845
#4  0x555f522c in device_update_db (device=0x5567bb20) at 
/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c:1079
_level = 7
_e = 0
id = 0x5567a740 "c189:258"
path = 0x7fffd870 "/run/udev/data/c189:258"
f = 0x556526a0
path_tmp = 0x5566e770 "/run/udev/data/.#c189:258gYzL5N"
has_info = true
r = 0
__PRETTY_FUNCTION__ = "device_update_db"
__func__ = "device_update_db"
__FUNCTION__ = "device_update_db"
#5  0x555cb3cf in udev_device_update_db (udev_device=0x55638560) at 
/home/elfring/Projekte/systemd/lokal/src/libudev/libudev-device-private.c:48
r = 21845
__PRETTY_FUNCTION__ = "udev_device_update_db"
#6  0x5556c924 in udev_event_execute_rules (event=0x55638df0, 
timeout_usec=18000, timeout_warn_usec=6000, 
properties_list=0x556380c0, 
rules=0x55638500) at 
/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:939
dev = 0x55638560
__func__ = "udev_event_execute_rules"
__FUNCTION__ = "udev_event_execute_rules"
#7  0x55563264 in worker_spawn (manager=0x55638080, 
event=0x5566ea30) at 
/home/elfring/Projekte/systemd/lokal/src/udev/udevd.c:450
udev_event = 0x55638df0
fd_lock = -1
dev = 0x55638560
rtnl = 0x0
fd_signal = 4
ep_monitor = {events = 1, data = {ptr = 0xb, fd = 11, u32 = 11, u64 = 
11}}
mask = {__val = {18446744067267100671, 18446744073709551615 }}
fd_monitor = 11
fd_ep =