[systemd-devel] Fwd: With my layer, Systemd not invoking my application at startup
Colin Guthrie
gmane at colin.guthr.ie
Thu Jul 2 01:16:32 PDT 2015
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/
More information about the systemd-devel
mailing list