Re: [systemd-devel] /etc/systemd/system/default.target.wants/no longer checked for unit files

2017-07-14 Thread Felipe Sateler 
On Fri, 14 Jul 2017 12:28:20 +0200, Michael Biebl wrote:

> 2017-07-14 12:24 GMT+02:00 Mantas Mikulėnas :
>> On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones
>>  wrote:
>>>
>>>
>>> https://github.com/systemd/systemd/issues/6334
>>>
>>> Since this commit
>>>
>>> https://github.com/systemd/systemd/
commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
>>> (in v233 and v234), you can no longer create
>>> /etc/systemd/system/default.target.wants/ and drop in service files
>>> (or symlinks).  The directory is skipped.  I have reverted the commit
>>> on top of systemd from git and that makes defaults.target.wants work
>>> again.
>>>
>>> Is this supposed to work?  It worked fine since at least Fedora 18-25,
>>> but it is now broken in Fedora 26.
>>>
>>> If it was never supposed to work, how are you supposed to enable a
>>> service for the default target, even allowing for the user to change
>>> the default target and still have the service enabled?
>>
>>
>> The current convention is to install all regular services into
>> multi-user.target, and I would expect all custom "daily use" targets to
>> be superset of multi-user.target as well, like the provided
>> graphical.target already is.
> 
> Seems like default.target is used by quite a few services though:
> https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target
> 
> If default.target is not supposed to be used, then this should be
> mentioned somewhere.

The user manager has a real default.target. Many (most?) of the units 
listed above are user services.

-- 
Saludos,
Felipe Sateler

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

[systemd-devel] no user dbus session in container

2017-07-14 Thread arnaud gaboury 
 % systemctl --version
systemd 233
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
default-hierarchy=hybrid

% machinectl list
MACHINE CLASS SERVICEOS VERSION ADDRESSES
poppy   container systemd-nspawn fedora 26  192.168.1.94...

% machinectl show poppy
Name=poppy
Id=59b720b533834a4eafe07a62c2482266
Timestamp=Wed 2017-07-12 22:07:15 CEST
TimestampMonotonic=6928076
Service=systemd-nspawn
Unit=systemd-nspawn@poppy.service
Leader=648
Class=container
RootDirectory=/var/lib/machines/poppy
State=running

After upgrade from Fedora 25 to 26, there is no more user dbus session for
user in container.

On container:
$ ps -ef | grep dbus
5:dbus35 1  0 Jul13 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
--syslog-only
65:root  1195  1163  0 14:18 pts/000:00:00 grep -nI --color dbus

On host:
$ ps -ef | grep dbus
195:dbus   582 1  1 Jul12 ?00:21:57 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
204:gabx   614   602  0 Jul12 ?00:00:00 /usr/bin/dbus-daemon
--session --address=systemd: --nofork --nopidfile --systemd-activation
251:gabx  1593  1588  0 Jul12 ?00:00:00 /usr/bin/dbus-daemon
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork
--print-address 3
333:vu-popp+ 16543 16502  0 22:52 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
--syslog-only

On container, user can't connect to dbus session, and I have no idea why.
May someone please give me some hints on how to debug this issue? Thank you
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/systemd/system/default.target.wants/ no longer checked for unit files

2017-07-14 Thread Michael Biebl 
2017-07-14 12:24 GMT+02:00 Mantas Mikulėnas :
> On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones 
> wrote:
>>
>>
>> https://github.com/systemd/systemd/issues/6334
>>
>> Since this commit
>>
>> https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
>> (in v233 and v234), you can no longer create
>> /etc/systemd/system/default.target.wants/ and drop in service files
>> (or symlinks).  The directory is skipped.  I have reverted the commit
>> on top of systemd from git and that makes defaults.target.wants work
>> again.
>>
>> Is this supposed to work?  It worked fine since at least Fedora 18-25,
>> but it is now broken in Fedora 26.
>>
>> If it was never supposed to work, how are you supposed to enable a
>> service for the default target, even allowing for the user to change
>> the default target and still have the service enabled?
>
>
> The current convention is to install all regular services into
> multi-user.target, and I would expect all custom "daily use" targets to be
> superset of multi-user.target as well, like the provided graphical.target
> already is.

Seems like default.target is used by quite a few services though:
https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target

If default.target is not supposed to be used, then this should be
mentioned somewhere.


-- 
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] /etc/systemd/system/default.target.wants/ no longer checked for unit files

2017-07-14 Thread Richard W.M. Jones 
On Fri, Jul 14, 2017 at 01:24:53PM +0300, Mantas Mikulėnas wrote:
> On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones 
> wrote:
> 
> >
> > https://github.com/systemd/systemd/issues/6334
> >
> > Since this commit
> > https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119
> > bbb4427244
> > (in v233 and v234), you can no longer create
> > /etc/systemd/system/default.target.wants/ and drop in service files
> > (or symlinks).  The directory is skipped.  I have reverted the commit
> > on top of systemd from git and that makes defaults.target.wants work
> > again.
> >
> > Is this supposed to work?  It worked fine since at least Fedora 18-25,
> > but it is now broken in Fedora 26.
> >
> > If it was never supposed to work, how are you supposed to enable a
> > service for the default target, even allowing for the user to change
> > the default target and still have the service enabled?
> >
> 
> The current convention is to install all regular services into
> multi-user.target, and I would expect all custom "daily use" targets to be
> superset of multi-user.target as well, like the provided graphical.target
> already is.
> 
> IMHO, don't try to second-guess the user. If they know how to create custom
> targets, they'll probably know how to look what's inside their
> multi-user.target.wants/ and deal with it.

The commit seems as if it was intended to be pure optimization, and
yet it breaks an existing use case.  Also the documentation doesn't
mention anything about default.target.wants being deprecated.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/systemd/system/default.target.wants/ no longer checked for unit files

2017-07-14 Thread Mantas Mikulėnas 
On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones 
wrote:

>
> https://github.com/systemd/systemd/issues/6334
>
> Since this commit
> https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119
> bbb4427244
> (in v233 and v234), you can no longer create
> /etc/systemd/system/default.target.wants/ and drop in service files
> (or symlinks).  The directory is skipped.  I have reverted the commit
> on top of systemd from git and that makes defaults.target.wants work
> again.
>
> Is this supposed to work?  It worked fine since at least Fedora 18-25,
> but it is now broken in Fedora 26.
>
> If it was never supposed to work, how are you supposed to enable a
> service for the default target, even allowing for the user to change
> the default target and still have the service enabled?
>

The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to be
superset of multi-user.target as well, like the provided graphical.target
already is.

IMHO, don't try to second-guess the user. If they know how to create custom
targets, they'll probably know how to look what's inside their
multi-user.target.wants/ and deal with it.

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

[systemd-devel] Hashmap iteration is too costly

2017-07-14 Thread vcaputo 
The current hashmap iteration incurs at least one function call per
iteration, and in my observations using gcc 6.3 w/-g -O2, it's two:

 internal_hashmap_iterate()
 hashmap_iterate_entry()

for every element in the hashmap.

In profiles of `journalctl -b --no-pager` having multiple (50) log files,
the hashmap iteration shows up as ~10% of the CPU in callgrind output.

Since it appears effort has been made to keep the hashmap structure opaque,
making these iterators zero-cost seems non-trivial.

As an experiment, I added two new hashmap functions:

 hashmap_get_array()
 ordered_hashmap_get_array()

These return an allocated array snapshot of the hashmap's contents, in the
same order they would be iterated in.  Their implementation has direct
access to the hashmap internals, and uses inlined versions of the
type-specific iterator functions to avoid the per-element function call
overhead of the usual iterators.

You can find the code here:

https://github.com/systemd/systemd/compare/303608...vcaputo:hashmap_get_array

The last commit includes some numbers, which I'll include them here for
convenience:

Before:

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m16.452s
   user0m16.371s
   sys 0m0.066s

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m16.375s
   user0m16.310s
   sys 0m0.057s

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m16.390s
   user0m16.329s
   sys 0m0.047s

 After:

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m15.827s
   user0m15.769s
   sys 0m0.052s

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m15.650s
   user0m15.592s
   sys 0m0.050s

  # time ./journalctl -b -1 --no-pager > /dev/null
   real0m15.646s
   user0m15.574s
   sys 0m0.056s


Note this is adding the cost of a malloc and free, and copying the
elements.  It's still faster than the existing hashmap iterator.

I'm not sold on this being a good solution, it's more meant to shed light
on what I feel is a bit of a wart and hopefully start some discussion.

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

Re: [systemd-devel] Systemd weird behavior after upgrade -

2017-07-14 Thread arnaud gaboury 
On Thu, Jul 13, 2017 at 11:58 PM Reindl Harald 
wrote:

>
>
> Am 13.07.2017 um 23:40 schrieb arnaud gaboury:
> > (no HTML crapps)
>
> still HTML and no meaningful quoting to distinct your "i respond to
> myself" answer with your initial post - no idea what you expect by
> sending a bunch of mails with the same content within a few hours nor
> why you think it's a good idea to upgrade to F26 a dy after release if
> the system is important and you have no testing environment
>

I have been dealing for a while and worked hard on this issue. I don't need
your sarcasm neither your advise on going or not Fedora 26. but best a few
hints on how to solve my issues.

Your answer is worthless.

>
> additionally this is the upstzream mailing list and not the Fedora
> users-list nur the Fedora bugtracker - here you go:
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
>
> > OS= Fedora 26
> > Linux container managed by machinectl
> >
> >   % systemctl --version
> > systemd 233
> > +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
> > +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS
> > +KMOD +IDN default-hierarchy=hybrid
> >
> > % machinectl list
> > MACHINE CLASS SERVICEOS VERSION ADDRESSES
> > poppy   container systemd-nspawn fedora 26  192.168.1.94...
> >
> > % machinectl show poppy
> > Name=poppy
> > Id=59b720b533834a4eafe07a62c2482266
> > Timestamp=Wed 2017-07-12 22:07:15 CEST
> > TimestampMonotonic=6928076
> > Service=systemd-nspawn
> > Unit=systemd-nspawn@poppy.service
> > Leader=648
> > Class=container
> > RootDirectory=/var/lib/machines/poppy
> > State=running
> >
> >
> >
> -
> >
> > After upgrade from Fedora 25 to 26, some services are broken.
> > Below are some broken service status
> >
> >
> > % systemctl status user@1000.service
> > ● user@1000.service - User Manager for UID 1000
> > Loaded: loaded (/usr/lib/systemd/system/user@.service; static;
> > vendor preset: disabled)
> > Active: failed (Result: protocol) since Wed 2017-07-12 22:09:45
> > CEST; 15h ago
> >   Main PID: 257 (code=exited, status=237/KEYRING)
> >
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[1]: Starting User Manager for UID 1000...
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[257]: user@1000.service: Failed at step KEYRING spawning
> > /usr/lib/systemd/systemd: Permission denied
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[1]: Failed to start User Manager for UID 1000.
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[1]: user@1000.service: Unit entered failed state.
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[1]: user@1000.service: Failed with result 'protocol'.
> >
> >
> > %  systemctl status user.slice
> > ● user.slice - User and Session Slice
> > Loaded: loaded (/usr/lib/systemd/system/user.slice; static; vendor
> > preset: disabled)
> > Active: active since Wed 2017-07-12 22:07:15 CEST; 15h ago
> >   Docs: man:systemd.special(7)
> > CGroup: /user.slice
> > └─user-1000.slice
> >   ├─session-c1.scope
> >   │ ├─ 256 login -- poisonivy
> >   │ ├─ 258 -zsh
> >   │ ├─ 356 su
> >   │ ├─ 357 zsh
> >   │ ├─1553 systemctl status user.slice
> >   │ └─1554 less
> >   └─session-c2.scope
> > ├─449 login -- poisonivy
> > ├─450 -zsh
> > ├─494 su
> > ├─495 zsh
> > └─526 /usr/bin/python3 -O /usr/bin/ranger
> >
> > Jul 12 22:09:45 thetradinghall.com 
> > systemd[1]: user.slice: Failed to set invocation ID on control group
> > /user.slice, ignoring: Operation not permitted
> >
> > % systemctl status opendkim.service
> > ● opendkim.service - DomainKeys Identified Mail (DKIM) Milter
> > Loaded: loaded (/usr/lib/systemd/system/opendkim.service; enabled;
> > vendor preset: disabled)
> >Drop-In: /etc/systemd/system/opendkim.service.d
> > └─override.conf
> > Active: failed (Result: exit-code) since Thu 2017-07-13 11:33:25
> > CEST; 2h 30min ago
> >   Docs: man:opendkim(8)
> > man:opendkim.conf(5)
> > man:opendkim-genkey(8)
> > man:opendkim-genzone(8)
> >
> >
> > Jul 13 11:33:25 thetradinghall systemd[1]: Starting DomainKeys
> > Identified Mail (DKIM) Milter...
> > Jul 13 11:33:25 thetradinghall systemd[1243]: opendkim.service: Failed
> > at step KEYRING spawning /usr/sbin/opendkim: Permission denied
> >
> > *N.B:* I can manually start opendkim as root
> >
> >
> > I have no ideas why these new issues. The only hint is the following
> > one. Hope below command outputs may help:
> >
> >

[systemd-devel] /etc/systemd/system/default.target.wants/ no longer checked for unit files

2017-07-14 Thread Richard W.M. Jones 

https://github.com/systemd/systemd/issues/6334

Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks).  The directory is skipped.  I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.

Is this supposed to work?  It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.

If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel