Open registration is disabled at the moment due to spam.If you need a new account, please contact Keto on oftc.net IRC and provide your desired username and email.
This Bugzilla instance is no longer in active use, so you should only need an account if you wish to use the Sailfish OS community OBS.
Bug 542 - Several packages' systemd configurations are inconsistent
Summary: Several packages' systemd configurations are inconsistent
Status: NEW
Alias: None
Product: Mer Core
Classification: Unclassified
Component: systemd (show other bugs)
Version: unspecified
Hardware: All Mer
: Low normal
Assignee: Not Taken
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-18 17:33 UTC by Thilo Fromm
Modified: 2012-08-20 11:09 UTC (History)
3 users (show)

See Also:

Attachments
script for verifying dependency soft-links against service files' WantedBy= entries. (1.58 KB, application/x-shellscript)
2012-08-18 17:33 UTC, Thilo Fromm 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thilo Fromm 2012-08-18 17:33:27 UTC 
Created attachment 18 [details]
script for verifying dependency soft-links against service files' WantedBy= entries.

This bug is a follow-up to https://bugs.nemomobile.org/show_bug.cgi?id=172 which was first found in the Nemo project.

Several packages install different dependency soft-links than they list in their systemd configuration file.

In mer-core at least the following packages are affected: sshd, connman, ofono, boardname, and systemd itself.

Some background on how systemd determines dependencies:

- In order to configure service - target dependencies systemd uses sub-
  directories for each target named "<target>.wants" which contain soft links
  to the service files this target depends on.

- systemd configuration files can have an optional [Install] section 
  specifying dependent units in the WantedBy= option. This option is 
  read by "systemctl enable" / "systemctl disable" to create or remove those
  soft links. See the man page for "systemd.unit" for more information on 
  [Install]: http://0pointer.de/public/systemd-man/systemd.unit.html


The problematic packages I listed above now introduce a problem. They bring their own systemd configuration files, complete with an [Install] section which contains a valid WantedBy=... . This certainly is a good thing.

However, the package installation scripts manually create soft links *in the wrong place*. This way the package installer script creates a symlink which conflicts with the package's own systemd configuration.

Here's an example:

- connman.service has this:

[Install]
WantedBy=multi-user.target

  => This means "systemctl enable connman.service" will create a symbolic link

       multi-user.target.wants/connman.service -> connman.service

     and "systemctl disable connman.service" will try to remove this link.

- The connman package, however, creates a link itself upon installation.
  This link is created in network.target.wants/ instead of 
  multi-user.target.wants/, thereby conflicting with the information in its own
  systemd service file.


This behavior is true for all the packages mentioned above.


I attached a script to this bug which checks .service files against soft-links installed. Only the ERROR: output of this script is relevant for this bug, though.


There are at least two possible fixes for this:

1) remove the [Install] sections from all the packages' service files
   (This is OK with systemd; it will consider the services 'static', but 
    enable/disable won't work)

or

2) fix the packages' installer scripts to either call 
   "systemctl enable <service>" (preferred) or at least create the soft links
   in the right place.
Comment 1 Thilo Fromm 2012-08-18 17:38:20 UTC 
Script output:

...

ERROR: spurious soft link from multi-user.target.wants to 
   sshd.socket. sshd.socket is wanted by sockets.target, 
   not by multi-user.target.wants.
ERROR: spurious soft link from network.target.wants to 
   connman.service. connman.service is wanted by 
   multi-user.target, not by network.target.wants.
ERROR: spurious soft link from network.target.wants to 
   ofono.service. ofono.service is wanted by 
   multi-user.target, not by network.target.wants.
ERROR: spurious soft link from sysinit.target.wants to 
   boardname.service. boardname.service is wanted by 
   basic.target, not by sysinit.target.wants.
ERROR: spurious soft link from sysinit.target.wants to 
   systemd-readahead-collect.service. 
   systemd-readahead-collect.service is wanted by
   default.target, not by sysinit.target.wants.
ERROR: spurious soft link from sysinit.target.wants
   to systemd-readahead-replay.service. 
   systemd-readahead-replay.service is wanted by 
   default.target, not by sysinit.target.wants.

...
Comment 2 Marko Saukko 2012-08-19 09:42:10 UTC 
Thanks for the script. These needs to be fixed accordingly, and creating proper link that are static in packages would be the preferred way. We don't need the [Install] but still it would be nice if the systemctl enable/disable would work if user for some reason would like to use those.

It seems however that systemctl enable/disble is not using the /lib/systemd/systemd/ but is instead using /etc/systemd/system/ to create those links. Is that expected behaviour with systemctl or something that is misconfigured atm?

[root@localhost ~]# ls -l /lib/systemd/system/multi-user.target.wants/ofono.service 
lrwxrwxrwx 1 root root 16 2012-08-13 18:10 /lib/systemd/system/multi-user.target.wants/ofono.service -> ../ofono.service
[root@localhost ~]# systemctl disable ofono.service
[root@localhost ~]# systemctl enable ofono.service
ln -s '/lib/systemd/system/ofono.service' '/etc/systemd/system/multi-user.target.wants/ofono.service'
[root@localhost ~]# systemctl disable ofono.service
rm '/etc/systemd/system/multi-user.target.wants/ofono.service'
[root@localhost ~]#
Comment 3 Thilo Fromm 2012-08-19 10:03:38 UTC 
(In reply to comment #2)

> It seems however that systemctl enable/disble is not using the
> /lib/systemd/systemd/ but is instead using /etc/systemd/system/ to create those
> links. Is that expected behaviour with systemctl or something that is
> misconfigured atm?

It is expected behavior. If you create links in /lib/systemd/system/....wants/ then your service dependency is considered 'static' by systemd. 

Put links in /etc/systemd/... and the service is considered 'active'. Remove any links but provide an [Install] section and the service will be considered 'inactive'.

So either:

A) create soft-links manually in /lib/systemd/system, and *do not* provide an
   [Install] section. Your service is now 'static'.

or

B) provide an [Install] section, and in the package installer just copy the 
   .service file to /lib/systemd/system, then call 

   systemctl daemon-reload && systemctl enable <whatever>.service

   instead of calling "ln -s" ... manually.
   Your service can now be managed with "systemctl enable/disable"


Personally I'd prefer B) since
- it enables users to enable/disable their services without manual hassles
- it honors the systemctl interface over manually patching stuff in the back-
  end, hence is more robust to systemd internal changes
Comment 4 Marko Saukko 2012-08-19 12:06:37 UTC 
In general we should avoid as much files that are not part of the rpm packages. Mainly because those files needs to be handled separately when package is installed/updated/removed, thus creating link in %install instead of calling enable in %post and disable in %postun should be preferred.

If some vendor wants to disable some service that usually means that vendor doesn't need the service and by installing it it would consume space in the target device. Mer Core shouldn't have services that needs to be installed but disabled. So removing the service from vendor point of view is the way to disable the service imo.

Anyway this bug is quite low on priority, thus doesn't need immediate attention and we should define what is the policy properly for this.

Adding Carsten as CC.
Comment 5 Thilo Fromm 2012-08-19 12:52:53 UTC 
(In reply to comment #4)

> In general we should avoid as much files that are not part of the rpm packages.
> Mainly because those files needs to be handled separately when package is
> installed/updated/removed, thus creating link in %install instead of calling
> enable in %post and disable in %postun should be preferred.

How is calling 

"systemctl enable <service>" in %post, 
"systemctl disable <service>" in %postun 

any different from calling 

"ln -s <service> <.wants>" in %post, 
"rm <.wants>" in %postun? 

Apart from the fact that the former uses a public interface (systemctl), while the latter does things behind systemd's back.

With "systemctl <enable|disable>" you don't need to care about changes in the systemd back-end (symlinks representing dependencies) for instance - systemd will.
Comment 6 Thilo Fromm 2012-08-19 13:58:17 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> 
> > In general we should avoid as much files that are not part of the rpm packages.
> > Mainly because those files needs to be handled separately when package is
> > installed/updated/removed, thus creating link in %install instead of calling
> > enable in %post and disable in %postun should be preferred.
> 
> How is calling 
> 
> "systemctl enable <service>" in %post, 
> "systemctl disable <service>" in %postun 
> 
> any different from calling 
> 
> "ln -s <service> <.wants>" in %post, 
> "rm <.wants>" in %postun? 
> 

Oh wait, you're creating the soft links at package creation time, not in the installer script. Okay, I see the difference. Changed my mind and will now support your suggestion of creating the links at package creation time.
Comment 7 Thilo Fromm 2012-08-19 15:23:20 UTC 
I added a patch which changes the WantedBy= setting to sysinit.target in the [Install] section of the readahead-collect, readahead-replay service files of the systemd package. Review URL is http://review.merproject.org/775. Marko, I added you to the review.

Current script output:


ERROR: spurious soft link from multi-user.target.wants to sshd.socket. 
  sshd.socket is wanted by sockets.target, not by multi-user.target.wants.
ERROR: spurious soft link from network.target.wants to connman.service. 
  connman.service is wanted by multi-user.target, not by network.target.wants.
ERROR: spurious soft link from network.target.wants to ofono.service. 
  ofono.service is wanted by multi-user.target, not by network.target.wants.
ERROR: spurious soft link from sysinit.target.wants to boardname.service. 
  boardname.service is wanted by basic.target, not by sysinit.target.wants.

Fixup status
------------
Done: systemd
Open: sshd, connman, ofono, boardname
Comment 8 David Greaves 2012-08-20 11:09:06 UTC 
triaged