dietpi-services vs systemd vs init

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
baz123
Posts: 166
Joined: Thu Jan 12, 2017 9:23 pm

Re: dietpi-services vs systemd vs init

Post by baz123 »

Hi @MichaIng yes I see all that (and by system I am meaning anything controlled by systemd services), but it can only ever be a partial solution and it may actually cause more problems than it solves, especially if it is opaque to the user (as it was to me and I've used DietPi for years and think it is great).

For instance, I self install EmonCMS (the full system not your package) and as well as a LAMP stack, it also needs Redis. For various reasons it does not use Redis from APT but PECL. This means Redis is installed outside of dietpi-services scope and there is no way DietPi can possibly know the dependency order. Equally EmonCMS uses Mosquitto which again you cannot know the dependency or the start order. Actually, EmonCMS is pretty robust and it sorts itself out quite happily.

So whilst I do agree with what you do to some extent, and for certain packages it may be vital, I think this should be more transparent so users are aware of what is actually happening and, where the user so desires, the services are left to systemd to manage as per the defined service files.
We simply "disable" it, which means that systemd does not autostart them on boot
Does this mean you actually use

Code: Select all

systemctl disable service
If so that can have unexpected consequences (as I outlined elsewhere). Do you then run a

Code: Select all

systemctl enable service
then a

Code: Select all

systemctl start service
Looking at the code it seems you do.

I think the real concern here is how this is communicated to users. I was unaware of this process (and that probably explains some issues I had in the past) and also unaware of the ability to exclude services from DietPi control (.dietpi-services_include_exclude).

Might I suggest that, when a package that includes a service is installed, you ask the user if they wish the service to be controlled by DietPi? Alternatively an overall check after install? As a minimum, is it possible to exclude services from some sort of config tool (other than just CLI or editing a file)?

On installing and running Monit as a service,
What you mean by "delay" it starting?
In this particular case, if left to systemd to start the service file, the web interface for Monit never started properly. I tried all manner of wants, requires, after etc all to no avail. The only solution was to introduce a timer file that systemd starts so the service is delayed for 30s before being started - then it was all OK.

This has been a really useful insight as to how this all works 'under the hood'. Thanks.

My final observation is that this does expose what I have always felt is the greatest weakness of DietPi, the documentation. So much of this useful info is buried in this forum. However, please keep up the great work you do.
MattG
Posts: 11
Joined: Sat Dec 08, 2018 5:00 pm

Re: dietpi-services vs systemd vs init

Post by MattG »

FYI, another side-effect of wrapping dietpi-services around systemd: again, if you want cpu affinity/priority adjustments, you can no longer do "systemctl restart <service>", you need to instead use "dietpi-services restart <service>". This is because dietpi-services "owns" the cpu affinity/priority config.

Case in point, I changed my mpd config and restarted, first with systemd, and my affinity settings weren't honored. I should have known better, after my participation in this thread. But it's another use-case where dietpi-services has taken over some systemd functionality.
MattG
Posts: 11
Joined: Sat Dec 08, 2018 5:00 pm

Re: dietpi-services vs systemd vs init

Post by MattG »

Now even dietpi-services does not seem to honor cpu affinity/scheduling preferences.

I'm switching between two different DACs right now, so I'm restarting MPD a fair amount.

Example, I first stop mpd via "dietpi-services stop mpd". I verify no mpd process is running. Then I do "dietpi-services start mpd". It starts, but is not running with the priority or affinity I have specified:

Code: Select all

root@dietpi-music:~# ps ax | grep mpd | grep -v grep
<no output, shows mpd is not running>

root@dietpi-music:~# dietpi-services start mpd
[  OK  ] DietPi-Services | Root access verified.

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: start

[  OK  ] DietPi-Services | start mpd
root@dietpi-music:~# ps ax | grep mpd | grep -v grep
18991 ?        Ssl    0:01 /usr/local/bin/mpd --no-daemon /etc/mpd.conf
root@dietpi-music:~# taskset -cp 18991
pid 18991's current affinity list: 0,1

# can see above it is now running, but pinned to cores 0,1, but should be 2,3 (see below).

root@dietpi-music:~# top -b -n 1
top - 18:31:54 up 5 days,  8:41,  2 users,  load average: 0.22, 0.12, 0.03
Tasks:  84 total,   1 running,  44 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.4 us,  0.1 sy,  0.0 ni, 99.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1000208 total,   323324 free,    37628 used,   639256 buff/cache
KiB Swap:  1097724 total,  1097724 free,        0 used.   850260 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
19008 root      20   0    8124   3116   2728 R  11.8  0.3   0:00.05 top
<snip>
18991 root      20   0  136680  22772  16840 S   0.0  2.3   0:01.08 mpd

# shoes priority/nice level is the default, which is not what is specified:

root@dietpi-music:~# cat /DietPi/dietpi/.dietpi-process_tool
<snip>
aname_save[4]='bin/mpd'
anice_save[4]=-15
aaffinity_save[4]='2,3'
aschedule_policy_save[4]='SCHED_FIFO'
aschedule_priority_save[4]='80'
After reboot, the affinity and priority is as I expect.

Is this is a bug in dietpi-services and/or dietpi-process_tooll?
User avatar
MichaIng
Site Admin
Posts: 2295
Joined: Sat Nov 18, 2017 6:21 pm

Re: dietpi-services vs systemd vs init

Post by MichaIng »

@MattG
Sorry for late reply:
- I get your points and indeed I also thought in the past, that having services enabled even under dietpi-services control might be beneficial. It would be possible to use systemd unit drop-ins to add mentioned After=/Before= entries (for non-strong requirements) and e.g. as well have them started after dietpi-postboot.service, which currently does the "dietpi-service start" after boot process has finished otherwise. But the latter is actually not even required, if all wanted dependencies/order directives are added.
- About nice/affinity/scheduler: Jep, dietpi-process_tool is meant to allow changing/setting these. dietpi-process_tool is invoked by "dietpi-services start", but currently not, when (re)starting a single process. This is actually something we should add.
To workaround: Just use "dietpi-services start" and you will see process tool applying nice/affinity/scheduler afterwards. Already running processes are usually ignored by systemd, so it should not hurt or interrupt that these are touched as well, at least I never faced this.
Post Reply