[systemd-devel] Fwd: With my layer, Systemd not invoking my application at startup
Vipin Nair
vipin.jn at gmail.com
Sat Jul 4 07:59:12 PDT 2015
>>OK, so you do not appear to be creating the user or changing ownership
>>in your service?
Right, the purpose of service is totally different.
>> Do you do that inside /opt/test_app itself or somewhere
>>else? If so, please include that information.
We use the yacto project model to build the project and create the final
file system image.
There we have the concept of 'pkg_preinst_' and 'pkg_postinstall' modules
for each service. So the preinst is run on the build machine
and sets up the file system. Postinstall can be either run on the build
machine or on the board during the 1st boot.
On the board, this postinstall modules are run before systemd starts the
systemd enabled services.
As part of postinstall script I am doing the user creation and file
ownership changes.
Inside this post install script module, I am registering with systemd
(using the systemctl enable command)
And the problem I am facing is that, if I run my post install on the build
machine, then systemd is able to invoke my service during the 1st boot,
but if I run my postinstall script on the machine, then systemd is not able
to invoke my service at 1st boot. From invoke, I mean systemd is not at all
starting the service.
>>OK, so "post_install" is not a systemd term. It is meaninless in the
>>upstream project. This is presumably something related to your build
>>system but you likely won't find any support for this via the systemd
>>mailing list. I'd get in touch with your distribution for this.
The post_install is a Yacto related term here. In yacto they do a systemd
package and that is what I am using inside my scripts.
I am not sure whether the problem I am facing is with systemd or Yacto, so
I have mailed the problem in both the mailing groups. But have not received
any response from Yacto group yet.
Thanks
Vipin
On Thu, Jul 2, 2015 at 1:46 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Hi,
>
> First of all, please keep the list included in your replies. Other
> people may be able to help.
>
> Vipin Nair wrote on 02/07/15 08:05:
> > Thanks a lot Colin for your valuable inputs.
> >
> > here is my service unit file :
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > [Unit] Description=McAfee Agent (masvc) [Service] Type=forking
> > ExecStartPre=-/bin/mkdir -p /var/tmp/config_file
> > ExecStartPre=-/bin/chmod 777
> > /var/tmp/config_fileExecStartPre=-/bin/chmod o+t
> > /var/tmp/config_fileExecStart=/opt/test_app start
> > ExecStop=/opt/test_appstop Type=forking TimeoutStartSec=20
> > SendSIGKILL=no [Install] WantedBy=multi-user.target
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> My mail client decided to reformat it. Sorry.
>
> So for all your ExecStartPre's there you could replace with a tmpfiles.d
> snippet that defines this. tmpfiles is run very early on boot.
>
> > From you reply , I get a feel you have misunderstand the purpose of my
> > service. My service is meant to serve some other purpose.
> > But for service to run, I have to create a new user and change the owner
> > ship of certain files to the new user.
>
> OK, so you do not appear to be creating the user or changing ownership
> in your service? Do you do that inside /opt/test_app itself or somewhere
> else? If so, please include that information.
>
> > Also during the 1st boot after reboot, I have to run a configuration
> > application which sets up the platform / env for my service to run.
>
> OK, so perhaps this answers my question above. How do you run this
> configuration application?
>
> If it simply creates users then you should look into systemd sysusers
> (see "man 5 sysusers.d") to create the user and systemd tmpfiles (see
> "man 5 tmpfiles.d") to create folders and change ownership of files.
>
> > So creating the new user, changing the file ownership and running the
> > configuration app, I have to do as part of post_install and it is to be
> > run on the target board.
>
> OK, so "post_install" is not a systemd term. It is meaninless in the
> upstream project. This is presumably something related to your build
> system but you likely won't find any support for this via the systemd
> mailing list. I'd get in touch with your distribution for this.
>
> Like I said, the sysusers and tmpfiles infrastructure provided by
> systemd can certainly perform some of what you need for your environment
> setup.
>
> > But with this the systemd, does not start my service during the 1st boot.
>
> When you say "does not start" do you mean it doesn't even try to start
> it? Or it tries and fails because the user is not yet setup?
>
> > If I just run the post install on the build machine (commenting out the
> > commands which are suppose to fail) and the then use the image, I see
> > that systemd does invoke my service during the 1st boot.
>
> Again "post install" is not a systemd upstream thing. This is part of
> your build system and you should seek help from them for this.
>
>
>
> > Does systemd waits for the post-install to be finished before
> > registering the services ?
>
> systemd has no concept of "post-install". It does have a first boot and
> it does have a way of bootstrapping itself after factory reset (i.e. the
> removal of /etc and /var). These capabilities of systemd might be able
> to completely replace your post-install process. See the various blog
> posts about systemd and "Factory reset" to see if you think this could
> help you.
>
> HTHs
>
> Col
>
> > If I have to register with systemd after the post-install is run what
> > more I have to do ?
> >
> > Waiting for your inputs.
> >
> > Kindly let me know if you need any other information from end.
> >
> > Thanks
> > Vipin
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Jul 1, 2015 at 1:41 PM, Colin Guthrie <colin at mageia.org
> > <mailto:colin at mageia.org>> wrote:
> >
> > Vipin Nair wrote on 01/07/15 07:00:
> > >
> > >
> > > Hi All,
> > >
> > > I am using the yacto style project and I have created a layer (my
> first
> > > layer) and have build it with WindRiver media which uses Systemd
> for the
> > > startup services.
> > >
> > > As per my application need, I have to create a new user on the
> final
> > > image and change the owner permissions of certain files to the new
> user.
> > > Since I could not get it done on the build machine, I have written
> the
> > > post install script such that it gets executed on the target board
> > > during the 1st boot cycle
> > > and from within the post install script I am creating the new user
> and
> > > changing the file ownership. And this works.
> > >
> > > But the only problem I have now is that, even though I register my
> > > service with Systemd at pre-install (or postinstall) section
> (using the
> > > systemctl enable command)
> > > my service is not getting launched by Systemd during the 1st boot.
> On
> > > subsequent reboots, it invokes my service at boot up.
> >
> >
> > It's hard to say without seeing your actual service (specifically
> it's
> > [Install] section) as otherwise we cannot tell what data systemctl
> > enable has to work with.
> >
> > However, from the description of your problem I think you're likely
> > trying to solve it the wrong way.
> >
> > systemd comes with two concepts to do what you want. sysusers is a
> > mechanism to initialise system users and can be confirured to run on
> > first boot. It will create your user for you.
> >
> > tmpfiles can create and change ownership of files and directories. It
> > runs on every boot.
> >
> > Dropping in the appropriate configuration snippet for both might be
> > sufficient for your needs and is likely cleaner than using a service.
> >
> > Hope this helps.
> >
> > Col
> >
> >
> > --
> >
> > Colin Guthrie
> > colin(at)mageia.org <http://mageia.org>
> > http://colin.guthr.ie/
> >
> > Day Job:
> > Tribalogic Limited http://www.tribalogic.net/
> > Open Source:
> > Mageia Contributor http://www.mageia.org/
> > PulseAudio Hacker http://www.pulseaudio.org/
> > Trac Hacker http://trac.edgewall.org/
> >
> >
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
> Tribalogic Limited http://www.tribalogic.net/
> Open Source:
> Mageia Contributor http://www.mageia.org/
> PulseAudio Hacker http://www.pulseaudio.org/
> Trac Hacker http://trac.edgewall.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150704/cc60d8d9/attachment-0001.html>
More information about the systemd-devel
mailing list