Re: [systemd-devel] how to debug failures when trying to lock down services

2017-11-29 Thread Mantas Mikulėnas
On Thu, Nov 30, 2017 at 5:27 AM, Michael Biebl  wrote:

> Hi,
>
> today I tried to lock down the rsyslog.service that I have on my system.
>
> For that I first created an override.conf that contained
>
> [Service]
> ProtectHome=yes
> PrivateTmp=yes
> PrivateDevices=yes
>
> ProtectSystem=strict
> ReadWritePaths=/var/log
> ReadWritePaths=/var/spool/rsyslog
> ReadWritePaths=/proc/kmsg
>

Are you using imklog or imkmsg? The latter would require the new /dev/kmsg
interface (which probably conflicts with PrivateDevices= above).


> Unfortunately, rsyslog.service failed to start:
> ● rsyslog.service - System Logging Service
>Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
> vendor preset: enabled)
>   Drop-In: /etc/systemd/system/rsyslog.service.d
>└─override.conf
>Active: failed (Result: exit-code) since Thu 2017-11-30 04:25:03 CET;
> 2s ago
>  Docs: man:rsyslogd(8)
>http://www.rsyslog.com/doc/
>   Process: 2734 ExecStart=/usr/sbin/rsyslogd -n (code=exited,
> status=1/FAILURE)
>  Main PID: 2734 (code=exited, status=1/FAILURE)
>

Well, it does say that the failure comes from rsyslogd itself, not from the
namespace setup...


> The journal doesn't contain anything useful.
>

I'm guessing rsyslog will log its own errors to /var/log/syslog rather than
stderr.


> Any hints how I can further debug this why rsyslog fails to start?
>

rsyslogd -d -d -d

strace

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


Re: [systemd-devel] [QUESTION] AIX 7.1 nodes area not reporting

2017-11-29 Thread Mantas Mikulėnas
On Thu, Nov 30, 2017 at 7:19 AM, Vengatesh R 
wrote:

> Hi Team,
>
>
>
> AIX 7.1 nodes area not reporting to puppet master. Please find the below
> details.
>
>
>
> Puppet master : Red hat Linux 7.3 x86_64
>

Hi,

this is not the Puppet mailing list, not the AIX mailing list, and not the
Red Hat support mailing list.

(And there were no details to be found, either.)

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-29 Thread Bao Nguyen
Hi all,

Thank you very much for your support.

I will try to fix the cycle.

Brs,

On Mon, Nov 27, 2017 at 4:11 PM, Reindl Harald 
wrote:

>
>
> Am 27.11.2017 um 05:23 schrieb Bao Nguyen:
>
>> Thanks all for your comments. I will try to use option FreeBind. However
>> could anyone explain for me that I did not use FreeBind option in
>> systems-210 but all my services start well? I am still inclined to the
>> different of systemd-228 and systemd-210 causes the current issue.
>>
>
> beause your configuration was undefined behavior and never made any sense
> when there are dependency loops and similar problems - systemd does and did
> the best not throw you to the mergency console and boot the system somehow,
> pointed out errors and now it's time to fi them
>
> IMHO it would be justified not to boot at all if there is as example a
> unit which has itself in After/Before/Requires as example when someone
> don't read his systemlogs after change units and "systemctl daemon-reload"
> :-)
>
>
> On Sun, Nov 26, 2017 at 4:53 PM, Reindl Harald > > wrote:
>>
>>
>>
>> Am 26.11.2017 um 10:47 schrieb Bao Nguyen:
>>
>> Regard to your question, "asi-My-5101.socket" depends on
>> "My-sshd.target", I think that in my case it is expected as my
>> socket listens on a specific address IP:port so it should start
>> after a network service to configure and assign IP address
>> before my socket runs
>>
>>
>> nonsense - the whole point of socket activation is to have sockets
>> listening before other stuff is up and running
>>
>> https://www.freedesktop.org/software/systemd/man/systemd.socket.html
>> > >
>> If an IP address is used here, it is often desirable to listen on it
>> before the interface it is configured on is up and running, and even
>> regardless of whether it will be up and running at any point. To
>> deal with this, it is recommended to set the FreeBind= option
>> described below
>>
>> FreeBind=
>> Takes a boolean value. Controls whether the socket can be bound to
>> non-local IP addresses. This is useful to configure sockets
>> listening on specific IP addresses before those IP addresses are
>> successfully configured on a network interface. This sets the
>> IP_FREEBIND socket option. For robustness reasons it is recommended
>> to use this option whenever you bind a socket to a specific IP
>> address. Defaults to false.
>>
> ___
> 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] [QUESTION] AIX 7.1 nodes area not reporting

2017-11-29 Thread Vengatesh R
Hi Team,

AIX 7.1 nodes area not reporting to puppet master. Please find the below 
details.

Puppet master : Red hat Linux 7.3 x86_64

The information in this e-mail and any attachments is confidential and may be 
legally privileged. It is intended solely for the addressee or addressees. Any 
use or disclosure of the contents of this e-mail/attachments by a not intended 
recipient is unauthorized and may be unlawful. If you have received this e-mail 
in error please notify the sender. Please note that any views or opinions 
presented in this e-mail are solely those of the author and do not necessarily 
represent those of TEMENOS. We recommend that you check this e-mail and any 
attachments against viruses. TEMENOS accepts no liability for any damage caused 
by any malicious code or virus transmitted by this e-mail.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] how to debug failures when trying to lock down services

2017-11-29 Thread Michael Biebl
Hi,

today I tried to lock down the rsyslog.service that I have on my system.

For that I first created an override.conf that contained

[Service]
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes

ProtectSystem=strict
ReadWritePaths=/var/log
ReadWritePaths=/var/spool/rsyslog
ReadWritePaths=/proc/kmsg

CapabilityBoundingSet=CAP_SYSLOG
CapabilityBoundingSet=CAP_NET_BIND_SERVICE


Unfortunately, rsyslog.service failed to start:
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
vendor preset: enabled)
  Drop-In: /etc/systemd/system/rsyslog.service.d
   └─override.conf
   Active: failed (Result: exit-code) since Thu 2017-11-30 04:25:03 CET; 2s ago
 Docs: man:rsyslogd(8)
   http://www.rsyslog.com/doc/
  Process: 2734 ExecStart=/usr/sbin/rsyslogd -n (code=exited, status=1/FAILURE)
 Main PID: 2734 (code=exited, status=1/FAILURE)

Nov 30 04:25:03 pluto systemd[1]: rsyslog.service: Service hold-off
time over, scheduling restart.
Nov 30 04:25:03 pluto systemd[1]: rsyslog.service: Scheduled restart
job, restart counter is at 5.
Nov 30 04:25:03 pluto systemd[1]: Stopped System Logging Service.
Nov 30 04:25:03 pluto systemd[1]: rsyslog.service: Start request
repeated too quickly.
Nov 30 04:25:03 pluto systemd[1]: rsyslog.service: Failed with result
'exit-code'.
Nov 30 04:25:03 pluto systemd[1]: Failed to start System Logging Service.


The journal doesn't contain anything useful.
Any hints how I can further debug this why rsyslog fails to start?

-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread Lennart Poettering
On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:

> +
> +[Unit]
> +Description=Weston, a Wayland compositor, as a system service
> +Documentation=man:weston(1) man:weston.ini(5)
> +Documentation=http://wayland.freedesktop.org/
> +
> +# Make sure we are started after logins are permitted.
> +After=systemd-user-sessions.service
> +
> +# If Plymouth is used, we want to start when it is on its way out.
> +After=plymouth-quit-wait.service
> +
> +# D-Bus is necessary for contacting logind. Logind is required.
> +Wants=dbus.socket
> +After=dbus.socket
> +
> +# This scope is created by pam_systemd when logging in as the user.
> +# This directive is a workaround to a systemd bug, where the setup of the
> +# user session by PAM has some race condition, possibly leading to a failure.
> +# See README for more details.
> +After=session-c1.scope

Hmm, what is this about?

This is racy, as the session ID is not really reliably predictable,
and is synthesized in different contexts in different ways, for
example depnding on whether audit is enabled in the kernel it might be
session-1.scope rather than session-c1.scope.

> +# Set up a full user session for the user, required by Weston.
> +PAMName=login

Piggy-backing on "login" is a bad idea. "login" is a text tool, and
thus the PAM rules for it usually pull in some TTY specific PAM
modules. YOu shoudl really use your own PAM fragment here, and
configure only the bits you need.

Lennart

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


Re: [systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Lennart Poettering
On Mi, 29.11.17 16:38, Olaf Hering (o...@aepfle.de) wrote:

> The detection of ConditionVirtualisation= relies on the presence of
> /proc/xen/capabilities. If the file exists and contains the string
> "control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
> be set. In case /proc/xen exists, or some sysfs files indicate "xen",
> VIRTUALIZATION_XEN should be set to indicate the system is a domU.
> 
> With an (old) xenlinux based kernel, /proc/xen/capabilities is always
> available and the detection described above works always. But with a
> pvops based kernel, xenfs must be mounted on /proc/xen to get
> "capabilities". Up to now this was done by a proc-xen.mount unit, which
> is part of xen.git. Since the mounting happens "late", other units may
> be scheduled before "proc-xen.mount". If these other units make use of
> "ConditionVirtualisation=", the virtualization detection returns
> incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
> is found in sysfs. This value will be cached. Once xenfs is mounted,
> the next process that runs detect_vm() will get VIRTUALIZATION_NONE.
> 
> This misdetection can be fixed by turning xenfs into an "API
> filesystem", which is done by adding it to mount_table[]. That way xenfs
> will be mounted early, and detect_vm() returns correct results.
> 
> But since the "proc-xen.mount" unit still exists, the startup of that
> unit fails because it is rejected due to a conflict with an "API
> filesystem" mount. This is done in mount_verify(). The unit gets into
> state FAILED. Other Xen toolstack related .service files rely on the
> existance of the proc-xen.mount unit. If proc-xen.mount fails, the
> toolstack fails too.
> 
> To stay compatible with existing and upcoming releases of Xen, add
> "/proc/xen" to the list of ignored paths and adjust the check for API
> mounts.
> 
> Now "proc-xen.mount" is silently accepted, it gets into state "start
> condition failed" because "ConditionPathExists=!/proc/xen/capabilities
> was not met". But all units depending on "proc-xen.mount" start anyway.
> 
> Signed-off-by: Olaf Hering 

Could you please submit this through github? we much prefer doing
reviews through github these days.

Also S-o-b is a kernel thing, we don't do that on systemd.

> ---
> 
> I'm not 100% sure if the logic change in mount_verify() has undesired effects.
> 
>  src/core/mount-setup.c | 3 +++
>  src/core/mount.c   | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
> index d5c0fcddc..df23e71b5 100644
> --- a/src/core/mount-setup.c
> +++ b/src/core/mount-setup.c
> @@ -114,6 +114,8 @@ static const MountPoint mount_table[] = {
>cg_is_legacy_wanted, MNT_FATAL|MNT_IN_CONTAINER },
>  { "pstore",  "/sys/fs/pstore","pstore", NULL,
>   MS_NOSUID|MS_NOEXEC|MS_NODEV,
>NULL,  MNT_NONE   },
> +{ "xenfs",   "/proc/xen", "xenfs",  NULL,
>   MS_NOSUID|MS_NOEXEC,
> +  NULL,  MNT_NONE   },
>  #if ENABLE_EFI
>  { "efivarfs","/sys/firmware/efi/efivars", "efivarfs",   NULL,
>   MS_NOSUID|MS_NOEXEC|MS_NODEV,
>is_efi_boot,   MNT_NONE   },
> @@ -126,6 +128,7 @@ static const MountPoint mount_table[] = {
>  static const char ignore_paths[] =
>  /* SELinux file systems */
>  "/sys/fs/selinux\0"
> +"/proc/xen\0"
>  /* Container bind mounts */
>  "/proc/sys\0"
>  "/dev/console\0"
> diff --git a/src/core/mount.c b/src/core/mount.c
> index b25bb9cb4..5afe7fcd7 100644
> --- a/src/core/mount.c
> +++ b/src/core/mount.c
> @@ -526,7 +526,7 @@ static int mount_verify(Mount *m) {
>  return -EINVAL;
>  }
>  
> -if (mount_point_is_api(m->where) || mount_point_ignore(m->where)) {
> +if (mount_point_is_api(m->where) && !mount_point_ignore(m->where)) {
>  log_unit_error(UNIT(m), "Cannot create mount unit for API 
> file system %s. Refusing.", m->where);
>  return -EINVAL;
>  }
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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


Re: [systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread systemd github import bot
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] blk_update_request

2017-11-29 Thread Mantas Mikulėnas
On Wed, Nov 29, 2017 at 6:28 PM, Dorian ROSSE 
wrote:

> Dear IT worker,
>
> I have some red errors on the log:
>
> sd 2:0:0:0 [sdb] No Caching mode page found
> sd 2:0:0:0 [sdb] Assumons drive cache: write through
> ...
> blk_update_request : I/O error, dev fd0, sectorielle 0
> ...
> ...
> ...
> Failed to mount /media/cle.
> ...
> ...
> ...
> iSCSI de mon with pid=1162 started !
>
>
> Have you some repairs for my problems ?
>

No, you're asking in the wrong place.

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


[systemd-devel] blk_update_request

2017-11-29 Thread Dorian ROSSE
Dear IT worker,

I have some red errors on the log:

sd 2:0:0:0 [sdb] No Caching mode page found
sd 2:0:0:0 [sdb] Assumons drive cache: write through
...
blk_update_request : I/O error, dev fd0, sectorielle 0
...
...
...
Failed to mount /media/cle.
...
...
...
iSCSI de mon with pid=1162 started !


Have you some repairs for my problems ?

Regards.


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


Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Olaf Hering
On Wed, Nov 29, Jan Beulich wrote:

> But in the description you talk about detect_vm() - by its name that
> doesn't look to care about Dom0, but whether running on top of
> _some_ hypervisor.

dom0 has to be handled as "no virtualization" because it has access to
all hardware, all services depending on "native" have to run in dom0.

Actually, it is spelled with 'z': ConditionVirtualization=
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html

Olaf


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


Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Jan Beulich
>>> On 29.11.17 at 17:07,  wrote:
> On Wed, Nov 29, Jan Beulich wrote:
> 
>> But in the description you talk about detect_vm() - by its name that
>> doesn't look to care about Dom0, but whether running on top of
>> _some_ hypervisor.
> 
> dom0 has to be handled as "no virtualization" because it has access to
> all hardware, all services depending on "native" have to run in dom0.

Ah, I see. But then still I don't see why at least on half way
recent Xen /sys/hypervisor/properties/features wouldn't have
the information you're after (and even more precise, because
down the road control domain and hardware domain may be
separate entities).

Jan

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


[systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Jan Beulich
>>> On 29.11.17 at 16:38,  wrote:
> The detection of ConditionVirtualisation= relies on the presence of
> /proc/xen/capabilities. If the file exists and contains the string
> "control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
> be set. In case /proc/xen exists, or some sysfs files indicate "xen",
> VIRTUALIZATION_XEN should be set to indicate the system is a domU.
> 
> With an (old) xenlinux based kernel, /proc/xen/capabilities is always
> available and the detection described above works always. But with a
> pvops based kernel, xenfs must be mounted on /proc/xen to get
> "capabilities". Up to now this was done by a proc-xen.mount unit, which
> is part of xen.git. Since the mounting happens "late", other units may
> be scheduled before "proc-xen.mount". If these other units make use of
> "ConditionVirtualisation=", the virtualization detection returns
> incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
> is found in sysfs. This value will be cached. Once xenfs is mounted,
> the next process that runs detect_vm() will get VIRTUALIZATION_NONE.

With all of the above, was it considered to check /sys/hypervisor
alongside with or perhaps even in preference to /proc/xen?

Jan

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


[systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Olaf Hering
The detection of ConditionVirtualisation= relies on the presence of
/proc/xen/capabilities. If the file exists and contains the string
"control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
be set. In case /proc/xen exists, or some sysfs files indicate "xen",
VIRTUALIZATION_XEN should be set to indicate the system is a domU.

With an (old) xenlinux based kernel, /proc/xen/capabilities is always
available and the detection described above works always. But with a
pvops based kernel, xenfs must be mounted on /proc/xen to get
"capabilities". Up to now this was done by a proc-xen.mount unit, which
is part of xen.git. Since the mounting happens "late", other units may
be scheduled before "proc-xen.mount". If these other units make use of
"ConditionVirtualisation=", the virtualization detection returns
incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
is found in sysfs. This value will be cached. Once xenfs is mounted,
the next process that runs detect_vm() will get VIRTUALIZATION_NONE.

This misdetection can be fixed by turning xenfs into an "API
filesystem", which is done by adding it to mount_table[]. That way xenfs
will be mounted early, and detect_vm() returns correct results.

But since the "proc-xen.mount" unit still exists, the startup of that
unit fails because it is rejected due to a conflict with an "API
filesystem" mount. This is done in mount_verify(). The unit gets into
state FAILED. Other Xen toolstack related .service files rely on the
existance of the proc-xen.mount unit. If proc-xen.mount fails, the
toolstack fails too.

To stay compatible with existing and upcoming releases of Xen, add
"/proc/xen" to the list of ignored paths and adjust the check for API
mounts.

Now "proc-xen.mount" is silently accepted, it gets into state "start
condition failed" because "ConditionPathExists=!/proc/xen/capabilities
was not met". But all units depending on "proc-xen.mount" start anyway.

Signed-off-by: Olaf Hering 
---

I'm not 100% sure if the logic change in mount_verify() has undesired effects.

 src/core/mount-setup.c | 3 +++
 src/core/mount.c   | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index d5c0fcddc..df23e71b5 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -114,6 +114,8 @@ static const MountPoint mount_table[] = {
   cg_is_legacy_wanted, MNT_FATAL|MNT_IN_CONTAINER },
 { "pstore",  "/sys/fs/pstore","pstore", NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_NONE   },
+{ "xenfs",   "/proc/xen", "xenfs",  NULL,  
MS_NOSUID|MS_NOEXEC,
+  NULL,  MNT_NONE   },
 #if ENABLE_EFI
 { "efivarfs","/sys/firmware/efi/efivars", "efivarfs",   NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   is_efi_boot,   MNT_NONE   },
@@ -126,6 +128,7 @@ static const MountPoint mount_table[] = {
 static const char ignore_paths[] =
 /* SELinux file systems */
 "/sys/fs/selinux\0"
+"/proc/xen\0"
 /* Container bind mounts */
 "/proc/sys\0"
 "/dev/console\0"
diff --git a/src/core/mount.c b/src/core/mount.c
index b25bb9cb4..5afe7fcd7 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -526,7 +526,7 @@ static int mount_verify(Mount *m) {
 return -EINVAL;
 }
 
-if (mount_point_is_api(m->where) || mount_point_ignore(m->where)) {
+if (mount_point_is_api(m->where) && !mount_point_ignore(m->where)) {
 log_unit_error(UNIT(m), "Cannot create mount unit for API file 
system %s. Refusing.", m->where);
 return -EINVAL;
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Olaf Hering
On Wed, Nov 29, Jan Beulich wrote:

> With all of the above, was it considered to check /sys/hypervisor
> alongside with or perhaps even in preference to /proc/xen?

Yes.
/proc/xen/capabilities is the one and only place that indicates a dom0.

Olaf


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


Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-11-29 Thread Jan Beulich
>>> On 29.11.17 at 16:54,  wrote:
> On Wed, Nov 29, Jan Beulich wrote:
> 
>> With all of the above, was it considered to check /sys/hypervisor
>> alongside with or perhaps even in preference to /proc/xen?
> 
> Yes.
> /proc/xen/capabilities is the one and only place that indicates a dom0.

But in the description you talk about detect_vm() - by its name that
doesn't look to care about Dom0, but whether running on top of
_some_ hypervisor.

Jan

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


Re: [systemd-devel] Spec for journalctl log entry data structure

2017-11-29 Thread Tomasz Torcz
November 29, 2017 1:27 PM, "Thomas Güttler"  
wrote:
> is there a spec or docs about the datastructure of a log entry in journalctl?
> 
> Which fields does a log record have?

There's a handy man page:
https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html

If you look for low-level journal file format, go to 
https://www.freedesktop.org/wiki/Software/systemd/journal-files
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Spec for journalctl log entry data structure

2017-11-29 Thread Mantas Mikulėnas
On Wed, Nov 29, 2017 at 2:18 PM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:

> Hi,
>
>
> is there a spec or docs about the datastructure of a log entry in
> journalctl?
>

The binary on-disk format is documented here:

https://www.freedesktop.org/wiki/Software/systemd/journal-files/

journalctl can also export to text format:

https://www.freedesktop.org/wiki/Software/systemd/export/
https://www.freedesktop.org/wiki/Software/systemd/json/


>
> Which fields does a log record have?
>
There's no fixed schema, although a base list can be found in `man
systemd.journal-fields
`
[1], and you can generally expect journald to always add the same
"_trusted" fields.

Out of the "application" fields, you can only assume that MESSAGE= will be
present, but everything else is up to the application. IMHO, it is useful
to supply fields which are useful

a) for filtering, e.g. systemd uses MESSAGE_ID, NetworkManager sets
NM_DEVICE, recent GLib sets GLIB_DOMAIN;

or b) for substitution in "catalog" explanations/translations (see e.g.
`journalctl -x -u systemd-journald`).

Take a look at `journalctl --fields | sort` or `journalctl -o verbose`, and
you'll see what is being used on your system.

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


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread Pekka Paalanen
On Wed, 29 Nov 2017 14:06:25 +0200
Mantas Mikulėnas  wrote:

> On Wed, Nov 29, 2017 at 10:32 AM, Jérémy Rosen 
> wrote:
> 
> > I had a quick glance but didn't actually test...
> >
> > 1) please open a pull request on github, you will have more feedback that
> > way
> >  
> 
> I think it's supposed to be a patch for Weston on fd.o and only cc'd here
> to systemd-devel...
> 

Hi,

yes, it's a Weston patch, not a systemd patch. Sorry for the confusion,
I was just looking for feedback.


Thanks,
pq


pgpb2i0B3eMl_.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread Pekka Paalanen
On Wed, 29 Nov 2017 09:32:02 +0100
Jérémy Rosen  wrote:

> I had a quick glance but didn't actually test...

> 2) you probably want to add Alias=display-manager.service, so it can 
> pull it other graphical services

Hi,

that sounds like a good idea.


Thanks,
pq

(adding back all the CCs)

> On 28/11/2017 11:14, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> >
> > There are many bad and even worse attempts to make Weston run as a
> > systemd service, and very few good ones. Let's add a good one as an
> > example in upstream: does not use weston-launch, does not run weston as
> > root, does not need wrapper scripts, and relies on logind and PAM.
> >
> > This example has been composed from a couple of real-world Weston unit
> > files used in production. It has not been used verbatim, but it has been
> > briefly tested on one Yocto-based system.
> >
> > The service file is not installed by the build. It would likely need
> > small adjustments for each distribution or system to be deplyed on.
> >
> > The session-c1.scope workaround refers to a systemd bug that has been
> > said to be hard to reproduce, but the details have been lost in time.
> >
> > Fixes: https://phabricator.freedesktop.org/T63
> >
> > Cc: martyn.we...@collabora.co.uk
> > Cc: fabien.lahoud...@collabora.co.uk
> > Cc: matt.hoos...@gmail.com
> > Cc: sjoerd.sim...@collabora.co.uk
> > Signed-off-by: Pekka Paalanen 
> >
> > ---
> >
> > Hi all,
> >
> > I have cross-posted this patch to systemd-devel with the hope that
> > someone would recall details about the systemd or PAM plugin race that
> > prompted the session-c1.scope workaround. I belive Martyn spoke about it
> > in person with Lennart, but as far as Martyn recalls, there is no record
> > of the issue. Enabling session lingering was mentioned as another
> > workaround.
> > ---
> >   doc/systemd/README | 45 +++
> >   doc/systemd/weston.service | 66 
> > ++
> >   2 files changed, 111 insertions(+)
> >   create mode 100644 doc/systemd/README
> >   create mode 100644 doc/systemd/weston.service
> >
> > diff --git a/doc/systemd/README b/doc/systemd/README
> > new file mode 100644
> > index ..2aa3aa9a
> > --- /dev/null
> > +++ b/doc/systemd/README
> > @@ -0,0 +1,45 @@
> > +   Systemd integration examples
> > +
> > +These examples rely on Weston's logind and systemd support. Weston needs 
> > to be
> > +built with options: --enable-dbus --enable-systemd-login 
> > --enable-systemd-notify
> > +
> > +Furthermore, Weston needs to be configured to load systemd-notify.so 
> > plugin.
> > +This can be done on the Weston command line:
> > +
> > +$ weston --modules=systemd-notify.so
> > +
> > +or in weston.ini:
> > +
> > +[core]
> > +modules=systemd-notify.so
> > +
> > +The plugin implements the systemd service notification protocol, watchdog
> > +protocol, and also allows socket activation and configuring listening 
> > sockets
> > +via systemd.
> > +
> > +
> > +   weston.service
> > +
> > +An example on how to run Weston as a system service. It starts a full user
> > +session of the named user on the given virtual terminal.
> > +
> > +This is useful for running a login manager or for dedicated systems that 
> > do not
> > +have personal user accounts and do not need the user to log in.
> > +
> > +You should very least customize the user, but likely also the tty and
> > +and the weston command line. See 'systemctl edit' command for an easy way 
> > to
> > +do that per-system if you don't edit the service file before installing it.
> > +
> > +This approach has an issue that in one system was worked around with the
> > +"After=session-c1.scope" directive. The details have been forgotten, but
> > +enabling session lingering was mentioned as another workaround. It might
> > +perhaps have something to do with multiple system units triggering the 
> > setup
> > +of a user session. It would be much better to start Weston as a systemd 
> > user
> > +service instead to avoid the issue completely.
> > +
> > +
> > +TODO: add an example of socket activation and defining sockets with systemd
> > +
> > +TODO: talk about starting Weston as a systemd user service, as that would
> > +often be more appropriate than as a system service. The user can still be
> > +automatically logged in. Presumably the auto-login service can allocate 
> > the VT.
> > diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
> > new file mode 100644
> > index ..80d242a6
> > --- /dev/null
> > +++ b/doc/systemd/weston.service
> > @@ -0,0 +1,66 @@
> > +# This is a system unit for launching Weston with auto-login as the
> > +# user configured here.
> > +#
> > +# Weston must be built with systemd support, and your weston.ini must load
> > +# the plugin systemd-notify.so.
> > +
> > +[Unit]
> > +Description=Weston, a Wayland compositor, as a 

[systemd-devel] Spec for journalctl log entry data structure

2017-11-29 Thread Thomas Güttler

  
  
Hi,


is there a spec or docs about the datastructure of a log entry in
  journalctl?


Which fields does a log record have?


Regards,
  Thomas Güttler



-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
  

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


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread Mantas Mikulėnas
On Wed, Nov 29, 2017 at 10:32 AM, Jérémy Rosen 
wrote:

> I had a quick glance but didn't actually test...
>
> 1) please open a pull request on github, you will have more feedback that
> way
>

I think it's supposed to be a patch for Weston on fd.o and only cc'd here
to systemd-devel...

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


Re: [systemd-devel] [PATCH v2] udev rules: add by-location symlinks to nvme devices

2017-11-29 Thread Lennart Poettering
On Di, 28.11.17 22:00, charles.r...@dell.com (charles.r...@dell.com) wrote:

> On systems with multiple 2.5-inch form factor PCIe SSD devices, locating the
> physical drive can be made easier with symlinks that contain the drive bay
> and slot information like this:

The first version you submitted through github, could you submit this
one too, please?

Thanks,

Lennart

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


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread systemd github import bot
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-11-29 Thread Jérémy Rosen

I had a quick glance but didn't actually test...

1) please open a pull request on github, you will have more feedback 
that way
2) you probably want to add Alias=display-manager.service, so it can 
pull it other graphical services


Regards
Jérémy

On 28/11/2017 11:14, Pekka Paalanen wrote:

From: Pekka Paalanen 

There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.

This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.

The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.

The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.

Fixes: https://phabricator.freedesktop.org/T63

Cc: martyn.we...@collabora.co.uk
Cc: fabien.lahoud...@collabora.co.uk
Cc: matt.hoos...@gmail.com
Cc: sjoerd.sim...@collabora.co.uk
Signed-off-by: Pekka Paalanen 

---

Hi all,

I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
  doc/systemd/README | 45 +++
  doc/systemd/weston.service | 66 ++
  2 files changed, 111 insertions(+)
  create mode 100644 doc/systemd/README
  create mode 100644 doc/systemd/weston.service

diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index ..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+   Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login 
--enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+This can be done on the Weston command line:
+
+$ weston --modules=systemd-notify.so
+
+or in weston.ini:
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+   weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index ..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[Unit]
+Description=Weston, a Wayland compositor, as a system service
+Documentation=man:weston(1) man:weston.ini(5)
+Documentation=http://wayland.freedesktop.org/
+
+# Make sure we are started after logins are permitted.
+After=systemd-user-sessions.service
+
+# If Plymouth is used, we want to start when it is on its way out.
+After=plymouth-quit-wait.service
+
+# D-Bus is necessary for contacting logind. Logind is required.
+Wants=dbus.socket
+After=dbus.socket
+
+# This scope is created by pam_systemd when logging in as the user.
+# This directive is a workaround to a