DietPi-RAMlog | Additional work for disabling

[Fourdee]

https://github.com/Fourdee/DietPi/pull/1919#issuecomment-405108537

[Fourdee]

https://github.com/Fourdee/DietPi/commit/e85f2efa39bd7d3867f06a804149c47c45c3170e

[Fourdee]

Retests:

• /var/tmp/dietpi/logs/dietpi-ramlog_store/ exists with content, after disabled and 2nd reboot. Due to dietpi-ramlog being disabled, however, systemD runs stop on this service regardless.

Aside from the above its fine.

[Fourdee]

NB: if not resolved https://github.com/Fourdee/DietPi/issues/1924#issuecomment-405766368, Type=forking does not wait for the process to finish?
Change to oneshot for disable service.

[MichaIng]

@Fourdee
I will test.

https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS
So for our needs, forking and oneshot both have the effect (compared to default=simple), that ExecStart needs to finish before systemd starts follow-up units. In our case of dietpi-ramlog/ramdisk services, oneshot actually fits better, since we do not start a daemon within the scripts. But without PIDFile info for systemd to stop on shutdown, I guess both types have practically the same effect.
And yeah I remember you saying the nice green dot on systemd status gives one the impression that something is active (actually tmpfs mount) 😉.
Ah more importantly, maybe ExecStop doesn't get called for oneshot scripts, or worse, called directly after ExecStart has finished. Jep we stay with forking 👍!

According to the above, I think the disable service should be better oneshot, so systemd does not go on until all it's tasks are finished.

[Fourdee]

Hmm, think we could simplify this a little. With disabling dietpi-ramlog we risk something going wrong for the user and their logs.

Basically, its part of the DietPi system. Maybe we should simply detect if running in RAM or DISK mode, and inform the user in dietpi-ramlog about which mode is running?

EDIT: I don't like the current method, its messy. The previous method has risk during umount on a live system. Hmm, will think about it.

[MichaIng]

@Fourdee
Hmm, if I am not thinking wrong, then disabling/enabling the service does not include some risk, it is toggle mounting tmpfs to /var/log, which in both directions needs proper copy of /var/log file/folder skeletons.

For this reason, toggle in both directions, should call /DietPi/dietpi/dietpi-ramlog 1 directly and assure that on usual boot it is called again. As toggle in both directions now has the service enabled at first, all of this should be fine. Leaving all this checks to dietpi-ramlog.service for me leads to unneeded overhead and possible confusion/misunderstanding for end user.

[Fourdee]

@MichaIng

Yep agree, I just need more coffee in my system 🤣

https://github.com/Fourdee/DietPi/issues/1924#issuecomment-405766368

Resolved with:
https://github.com/Fourdee/DietPi/commit/ac6e524cf30aa4087a0ddef9b9765499c7d6f052

[Fourdee]

Hmm,

ramlog > full
full < ramlog

• 1st test 🈯️
• 2nd test 🈴 service still reported as enabled, but does not run? | /var/tmp/dietpi/logs/dietpi-ramlog_store/ still exists.

root@DietPi:~# systemctl status dietpi-ramlog
● dietpi-ramlog.service - DietPi-RAMlog
   Loaded: loaded (/etc/systemd/system/dietpi-ramlog.service; enabled; vendor pr
eset: enabled)

I'll do a bash script and try and debug this.

root@DietPi:~# systemctl status dietpi-ramlog_disable -l
● dietpi-ramlog_disable.service - DietPi - Boot service to allow dietpi-ramlog t
o start and copy skeletons back to /var/log, then finally disable ramlog
   Loaded: loaded (/etc/systemd/system/dietpi-ramlog_disable.service; enabled; v
endor preset: enabled)
   Active: inactive (dead)

Jul 18 17:19:48 DietPi systemd[1]: Dependency failed

Jul 18 17:19:48 DietPi systemd[1]: Dependency failed either:

• dietpi-ram* not started
• dietpi-ramlog being stopped during run, causes this to then fail?

[MichaIng]

@Fourdee

cat << _EOF_ > /etc/systemd/system/dietpi-ramlog_disable.service
[Unit]
Description=DietPi - Boot service to allow dietpi-ramlog to start and copy skeletons back to /var/log, then finally disable ramlog
After=dietpi-ramlog.service dietpi-ramdisk.service
Before=dietpi-boot.service rsyslog.service syslog.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'systemctl stop dietpi-ramlog; systemctl disable dietpi-ramlog; rm -R /var/tmp/dietpi/logs/dietpi-ramlog_store/*; systemctl disable dietpi-ramlog_disable; rm /etc/systemd/system/dietpi-ramlog_disable.service'

[Install]
WantedBy=local-fs.target
_EOF_

Works:

• Require=dietpi-ramlog in combination with systemctl stop dietpi-ramlog as first command leads to service terminates itself.
• The service does not require ramdisk either, does it?
• I also removed systemctl daemon-reload, as I am not sure if this could cause issues, when called during systemd run.

[Fourdee]

@MichaIng

Require=dietpi-ramlog in combination with systemctl stop dietpi-ramlog as first command leads to service terminates itself.

Yep confirmed. 👍

The service does not require ramdisk either, does it?

systemctl stop dietpi-ramdisk does, uses /DietPi in the service

Just doing some further tests, will send commit in a few.

---

🈯️ test 1 >

root@DietPi:~# cat /var/tmp/dietpi/logs/dietpi-ramlog_disable_debug.log
Removed /etc/systemd/system/local-fs.target.wants/dietpi-ramlog.service.
Removed /etc/systemd/system/local-fs.target.wants/dietpi-ramlog_disable.service.

🈯️ test 2 >

root@DietPi:~# systemctl status dietpi-ramlog -l
● dietpi-ramlog.service - DietPi-RAMlog
   Loaded: loaded (/etc/systemd/system/dietpi-ramlog.service; disabled; vendor p
reset: enabled)
   Active: inactive (dead) since Wed 2018-07-18 17:34:10 BST; 3min 30s ago
root@DietPi:~# cat /var/tmp/dietpi/logs/dietpi-ramlog
dietpi-ramlog_disable_debug.log  dietpi-ramlog_store/
dietpi-ramlog.log

root@DietPi:~# cat /var/tmp/dietpi/logs/dietpi-ramlog_disable_debug.log
Removed /etc/systemd/system/local-fs.target.wants/dietpi-ramlog.service.
Removed /etc/systemd/system/local-fs.target.wants/dietpi-ramlog_disable.service.

[MichaIng]

@Fourdee
Ah yes sure, so Require=dietpi-ramdisk should stay.

[Fourdee]

Good to go: https://github.com/Fourdee/DietPi/commit/00fc31b3970d335f685e060e16e11ae40e7da2be

Passed testing my end: https://github.com/Fourdee/DietPi/issues/1924#issuecomment-405993612

[MichaIng]

@Fourdee
Jep works fine now here as well 👍.

[Fourdee]

Completed.