I will explain you my problem statement.

I want to provide a piece of executable to my third party. Folder structure
of my output is something like this.
     /BingoDast
     |___
            /BingoDast/bin/   ---> this contains exectuables
     |___
            /BingoDast/lib/ ----> this contains required libraries.
     |___
            /BingoDast/Units/  ----> this contains unit files which runs my
executables

Now my third party don't want anything else apart from this package. And he
doesn't want to add any other files like generator files or they dont want
to modify any unit files existing.

Thirdparty is expecting is a commands like

export PATH=$PATH:/BingoDast/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/BingoDast/lib

for executables and libraries. Similar to run they need to have a
environment variable path like for Eg:
 export SYSTEMD_UNIT_PATH=/BingoDast/Units
and he should be able to start, stop the unit files available under
/BingoDast/Units folder.

But when I tried setting SYSTEMD_UNIT_PATH which is empty in case, value
set for this is not reflecting.

Why this value given to this environment variable is not working

Regards.
Raghu

--
Regards,

Raghavendra. H. R
(Raghu)

On Fri, Sep 23, 2016 at 12:00 PM, Kai Krakow <hurikha...@gmail.com> wrote:

> Am Thu, 22 Sep 2016 11:43:56 +0530
> schrieb "Raghavendra. H. R" <raghuh...@gmail.com>:
>
> > 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 <hurikha...@gmail.com>
> > wrote:
> >
> > > Am Wed, 21 Sep 2016 16:56:52 +0530
> > > schrieb "Raghavendra. H. R" <raghuh...@gmail.com>:
> > >
> > > > 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
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to