Re: [systemd-devel] why do we have aliases fro timedated, resolved, networkd, and what are they good for?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 12, 2016 at 11:55:21AM -0500, Brian Kroth wrote:
> Umut Tezduyar Lindskog  2016-09-12 07:19:
> >Hi Michael,
> >
> >On Sat, Sep 10, 2016 at 1:00 AM, Michael Biebl  wrote:
> >>Hi
> >>
> >>I wonder why we have the following aliases/symlinks
> >>
> >>dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
> >>dbus-org.freedesktop.import1.service -> systemd-importd.service
> >>dbus-org.freedesktop.locale1.service -> systemd-localed.service
> >>dbus-org.freedesktop.login1.service -> systemd-logind.service
> >>dbus-org.freedesktop.machine1.service -> systemd-machined.service
> >>dbus-org.freedesktop.network1.service -> systemd-networkd.service
> >>dbus-org.freedesktop.resolve1.service -> systemd-resolved.service
> >>dbus-org.freedesktop.timedate1.service -> systemd-timedated.service
> >>
> >>Those dbus-org.* aliases are used in the corresponding D-Bus system
> >>service files (SystemdService=dbus-org...)
> >>The symlinks/aliases are created statically in $libdir/systemd/system,
> >>so they can't be removed via systemctl disable.
> >>
> >>So, I'm asking myself what good those aliases are for?
> >>They actually have a downside:
> >>We just had a Debian bug report, where a user was masking
> >>systemd-resolved.service, but he was puzzled that he could still
> >>trigger the start of the service via systemd-resolve.
> >>This happened via D-Bus activation and the aliased name (which he had
> >>not masked).
> >
> >AFAIK, that 2 step service file name is for providing a way to prevent
> >dbus activation.
> 
> As in, it was intentionally done this way to allow masking a
> traditional service separately from a dbus activate one?

I think that we should refuse to start a service which is masked,
even if the alias is not masked. This is the general rule which is
expected and followed mostly. Note that the relationship is one-way:
an alias can be masked and this has no effect on "real" service.

Current behaviour sounds like a implementation oversight.

[...]
> For instance, I believe I can declare a service as desired for boot,
> even if I don't know where it's actual .service file is (eg: it's
> generated by legacy sysv init script or some such) by simply adding
> a symlink of
> /etc/systemd/system/multi-user.target.wants.d/foo.service ->
> /bin/true.
Yes, we generally ignore the target of the symlink (as long as
it's not /dev/null).

> >Masking resolved alias file should prevent dbus
> >activation. "systemctl mask dbus-org.freedesktop.resolve1.service".
Yes.

> I think the trouble with that is that it requires enumerating all of
> the symlinks and determining what else might link to another service
> that's masked (via a symlink elsewhere) [...]
No, it's the other way around, see my note above.

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

Re: [systemd-devel] Is it possible to load unit files from paths other than default paths ?

[Kai Krakow]

Am Thu, 22 Sep 2016 11:43:56 +0530
schrieb "Raghavendra. H. R" :

> Thank you for the suggestions.
> But with this suggestion I need to run as user something like that.
> 
> In normal init.d systems, we have environment variables like PATH &
> LD_LIBRARY_PATH.
> No matter where I place my new executable or library, adding that
> path into these environment variables is enough to execute or link
> the library.
> 
> Probably this kind of facility is not available in Systemd init
> systems.

Then this is like asking how sysvinit could load files from other
locations than /etc/init.d. I don't think that is possible. To solve
this, one copies the init scripts from where they are to init.d and
then just enables them. Tip: systemd works the same.

Adding a location where init scripts reside to PATH is just not exactly
what would work during boot. You are just exploiting and side effect
of /etc/init.d being scripts and not pure configuration. Service files
for systemd are configuration. Actually, this trick won't solve startup
dependencies as sysvinit systems only look at that directory (or the
runlevel directories where you'd symlink your scripts which is what
you'd do in systemd, too: symlink the services).

If this is how you do it, create a generator which creates a service
files for each script in a directory. Gentoo has something
for /etc/local.d that works this way. Another way would be (if the copy
source is already systemd service files) to just copy those with the
generator. But that was already suggested.

Here's the template to get you going:
https://gitweb.gentoo.org/proj/gentoo-systemd-integration.git/tree/system-generators/gentoo-local-generator

It expects /etc/local.d/*.{start,stop} bash scripts. I think it is easy
to adapt for you.

> On Thu, Sep 22, 2016 at 12:34 AM, Kai Krakow 
> wrote:
> 
> > Am Wed, 21 Sep 2016 16:56:52 +0530
> > schrieb "Raghavendra. H. R" :
> >  
> > > Hi,
> > >
> > > I'm newbie with systemd boot system and I need help in resolving
> > > one issue.
> > >
> > > I would like to create a service under a customized path Eg:/mnt
> > > and systemd should be able to pick my unit file from this.
> > >
> > > I tried by setting *Environment=SYSTEMD_UNIT_PATH=/mnt *from the
> > > console but it didnt help and found the error *"Failed to start
> > > startup.service: Unit startup.service failed to load: No such
> > > file or directory."*
> > >
> > >
> > > Is it possible to achieve this ?  
> >
> > Not sure if this helps you, i.e. is appropriate for your use-case...
> >
> > But if the directory happens to be a home directory and the services
> > are designed to be run as user, you could make the service files go
> > into $HOME/.config/systemd/user/ (or symlink this to your
> > mountpoint) and enable linger on the user (loginctl enable-linger
> > $USER).
> >
> > You can then manage these units as the user through "system --user
> > {start,stop,enable,...}" (only with real login sessions, not through
> > sudo -iu $USER, but ssh would work).
> >
> > --
> > Regards,
> > Kai
> >
> > Replies to list-only preferred.
> >
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >  
> 




-- 
Regards,
Kai

Replies to list-only preferred.

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