>>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 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?
>
&g
