dietpi-services vs systemd vs init

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
MattG
Posts: 11
Joined: Sat Dec 08, 2018 5:00 pm

dietpi-services vs systemd vs init

Post by MattG »

I'm trying to understand where dietpi-services starts and ends versus systemd and/or init.

In particular, I want to tweak the runtime parameters of the mpd daemon.

It looks like there is a systemd service file for mpd here:
/lib/systemd/system/mpd.service

However, when I do "dietpi-services enable mpd", that service file is not copied or symlink'ed anywhere in the /etc/systemd tree.

With most Linux distros I've worked with, it's considered bad practice to edit the service file in /lib/systemd, but rather make a copy to place in /etc/systemd, and edit the latter.

So what I ended up doing is:

Code: Select all

dietpi-services disable mpd
dietpi-services unmask mpd
systemctl enable mpd
rm /etc/systemd/system/multi-user.target.wants/mpd.service
cp /etc/systemd/system/multi-user.target.wants/mpd.service /etc/systemd/system/multi-user.target.wants/mpd.service
And then edit /etc/systemd/system/multi-user.target.wants/mpd.service as I want.

Is this the right way to go about this? Or should I just edit /lib/systemd/system/mpd.service directly, and let dietpi-services manage the mpd service?

Thanks!
baz123
Posts: 166
Joined: Thu Jan 12, 2017 9:23 pm

Re: dietpi-services vs systemd vs init

Post by baz123 »

Firstly, I don't know how the "dietpi-services" functionality works so cannot answer that part.

However, my general understanding of systemd is that the files in /etc/ should never be edited - they are system generated so edits are likely to be overwritten by an enable/disable. Editing the files in /lib/ should be avoided as an update to a package will cause your changes to be lost.

My preferred way is to create drop-in files - https://wiki.archlinux.org/index.php/sy ... ided_units probably gives the best explanation of this.

Also note from the man page

"In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in."

HTH
MattG
Posts: 11
Joined: Sat Dec 08, 2018 5:00 pm

Re: dietpi-services vs systemd vs init

Post by MattG »

Thank you, that is indeed helpful.

I may be overlooking something, but my drop-in doesn't seem to be honored on reboot. Specifically, the stock mpd.service file has this:

Code: Select all

ExecStart=/usr/local/bin/mpd --no-daemon /etc/mpd.conf
And in my drop-in override, I have this:

Code: Select all

ExecStart=
ExecStart=/usr/bin/taskset -c 2,3 /usr/local/bin/mpd --no-daemon /etc/mpd.conf
After reboot, mpd is running, but not affinitized cores 2 and 3 as I intend:

Code: Select all

root@dietpi-music:~# ps ax | grep mpd | grep -v grep
  441 ?        Ssl    0:01 /usr/local/bin/mpd --no-daemon /etc/mpd.conf

root@dietpi-music:~# taskset -cp 441
pid 441's current affinity list: 0-3
But then I did "systemctl daemon-reload" followed by "systemctl restart mpd.service", and now I have the affinity I want:

Code: Select all

root@dietpi-music:~# systemctl daemon-reload
root@dietpi-music:~# systemctl  restart mpd.service

root@dietpi-music:~# ps ax | grep mpd | grep -v grep
 1618 ?        S<sl   0:01 /usr/local/bin/mpd --no-daemon /etc/mpd.conf

root@dietpi-music:~# taskset -cp 1618
pid 1618's current affinity list: 2,3
Also, is dietpi-services documented anywhere? I still would like to know if it's more correct to work within the dietpi-services framework, or if I can do what I've done and work with systemd in a more "general Linux" fashion.

Thanks again!
User avatar
WarHawk
Posts: 631
Joined: Thu Jul 20, 2017 8:55 am

Re: dietpi-services vs systemd vs init

Post by WarHawk »

Many config files are in the /etc directory... (actually I think all of em are there)
http://www.aboutlinux.info/2007/03/what ... xunix.html

You can edit the configs for most services there...once changed the service that was started on the previous config needs to be restarted with the new config...thus a service restart is needed.

Also it is a VERY smart thing to do is to copy the original config file to a config.old before modifying the config...this way if something is borked...you can go back to the old config with minimal trouble.

Code: Select all

# cp /etc/whateverfile.conf /etc/whateverfile.conf.old (or just /etc/whateverfile.old
Be careful when changing thing as super user
User avatar
MichaIng
Site Admin
Posts: 2421
Joined: Sat Nov 18, 2017 6:21 pm

Re: dietpi-services vs systemd vs init

Post by MichaIng »

@MattG
Instead of touching mpd.service, I suggest you use dietpi-process_tool to set it's affinity. If I'm not mistaken, currently it would anyway override your set ones with every dietpi-services (re)start with default 0-3 ;).

In general dietpi-services is just a frontend for systemctl that we use to start/stop/restart all known/added services on boot, before and after software installs, updates and such, in an order that respects cross-access, e.g. webserver accessing PHP-FPM, or PHP accessing database via module and such.
So you can configure any services as you would do on any other systemd driven OS.

dietpi-process_tool runs after every dietpi-services (re)start to apply nice, affinity, scheduler policy and such. So this is the easiest way have these values adjusted. Now that I am thinking about, it should be less intrusive and only apply values for processes where user did actually choose to do :?.
MattG
Posts: 11
Joined: Sat Dec 08, 2018 5:00 pm

Re: dietpi-services vs systemd vs init

Post by MattG »

@MichaIng - thank you! I removed the systemd mpd drop-in I mentioned above, and instead used dietpi-process_tool as you suggested. After reboot, everything had the affinity and scheduling params I wanted. That also explains why the affinity/scheduling I specified in my drop-in appeared to not be honored (as it was overridden by dietpi-process_tool).

However, at the risk of being pedantic, I would suggest that your statement, so you can configure any services as you would do on any other systemd driven OS, is a bit misleading, at least in the case of CPU affinity and/or scheduling. On any other systemd-driven OS, if I want to change process affinity and/or the scheduler, I would do it with drop-ins, as described above. Furthemore, on non-DietPi systemd OSes, I'm not aware of any extra process(es) that forces affinity/scheduling.
User avatar
MichaIng
Site Admin
Posts: 2421
Joined: Sat Nov 18, 2017 6:21 pm

Re: dietpi-services vs systemd vs init

Post by MichaIng »

@MattG
Jep you are right. As said, we will change the behaviour of process tool to only apply changes that were actually chosen by user via process_tool GUI.
baz123
Posts: 166
Joined: Thu Jan 12, 2017 9:23 pm

Re: dietpi-services vs systemd vs init

Post by baz123 »

WarHawk wrote: Tue Dec 11, 2018 5:42 am Many config files are in the /etc directory... (actually I think all of em are there)
This thing that is not well understood is that when a system file is enabled, systemd creates the required symlinks (if the actual file is not in /etc). In this way is creates wants and timer 'files'. All installed packages should work in this way.

If you do a 'systemctl disable' systemd will delete the relevant file in the /etc/ directory (as that is the only way to stop it starting) whether that 'file' is an actual file or a symlink.

Thus, if you put the file directly in the /etc and then run a disable, the file is deleted (in fact if you create the symlink directly to /etc it will delete the actual symlinked file on disable - you need to symlink the service file to one of the other locations and then use enable).

Always better to put services files in one of the other locations that systemd scans on an enable command.

As a note - that link is quite old and systemd behaviour has changed over time (even between jessie and stretch).
baz123
Posts: 166
Joined: Thu Jan 12, 2017 9:23 pm

Re: dietpi-services vs systemd vs init

Post by baz123 »

@MichaIng Is this tool and how you manipulate systemd documented anywhere? I ask as I have had real issues with getting Monit to start correctly and I suspect now, it is because of how DietPi interacts with systemd and appears to force certain behaviours. I had just installed Monit and created a service file for it. Ended up requiring a timer file to delay it starting.

I'm not a fan of interfering with system processes so you must have good reason for doing so. Is this simply a hang over from init days?

I note
MichaIng wrote: Tue Dec 11, 2018 3:59 pm In general dietpi-services is just a frontend for systemctl that we use to start/stop/restart all known/added services on boot, before and after software installs, updates and such, in an order that respects cross-access, e.g. webserver accessing PHP-FPM, or PHP accessing database via module and such.
So you can configure any services as you would do on any other systemd driven OS.
systemd is pretty good at doing this - is it really necessary?

Could you expand on the rationale please?
User avatar
MichaIng
Site Admin
Posts: 2421
Joined: Sat Nov 18, 2017 6:21 pm

Re: dietpi-services vs systemd vs init

Post by MichaIng »

@baz123
We do not touch system services, just the user installed additional software services, webserver, multimedia daemons and such. We simply "disable" it, which means that systemd does not autostart them on boot and e.g. when upgraded via APT. But this only affects services (names) from a certain list, so your custom service should no be affected. You can find here which services we handle manually: https://github.com/Fourdee/DietPi/blob/ ... rvices#L46
Ended up requiring a timer file to delay it starting.
What you mean by "delay" it starting? Systemd starts it as fast as all units/targets listed in After= and Requires= are up. But After= only affects on services actually handled by systemd, so e.g. if you want something to start after mariadb.service, this will not work on DietPi, that is true. You could use the custom include/exclude list to include you service into dietpi-services handling or exclude one: /DietPi/dietpi/.dietpi-services_include_exclude, e.g. add + myservice or - mariadb.

Systemd does handling itself as good as it can, since it does not know when the user want to do some maintenance tasks, where running services might cause issues or even end up with corrupted data/database and such. And e.g. if you have Nextcloud running, and so prevent database corruption you stop mariadb, then webserver/PHP access, the cron job and such will throw ugly error messages, spam your log and such. So it is good to have alle related services stopped in a reasonable order. This is something systemd cant do. Also systemd does only know the dependencies, listed in the systemd unit, but e.g. webservers do not depend on PHP, only if you use them in certain ways, having an actual PHP page. PHP does not depend on e.g. a memory cache server, databases and such, but if your PHP pages or a certain PHP module and config setting require them, systemd does not know it. And you cannot add simply all possible services to the systemd unit list where service might or might not rely/depend on, based on the active/inactive modules and how you use it. So systemd does only respect the hard dependencies, while DietPi handles more possible and expected dependencies, based on usual install/usage.
Post Reply