Bug#901404: systemd-shim: Please dpkg-divert the dbus services you want dbus-activatable
Package: systemd-shim Version: 10-3 Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: shim-patches-removal Hello Debian systemd-shim Maintainers, The Debian systemd package is currently carrying a debian-specific patch to enable usage of various systemd daemons via systemd-shim on Debian systems. In particular, it patches several systemd services to make them activatable by DBus. [1] Unfortunately none of the systemd maintainers actively tests the non-systemd code paths in those daemons anymore, so we don't feel comfortable enabling those services for sysvinit in the systemd package itself. systemd-shim already has code to dpkg-divert a dbus service provided by systemd, so we think systemd-shim should take over the divert of the rest of the units which it wants to support to run under sysvinit. We intend to drop the patch before buster is released in the not too distant future. When we do that, we will bump the severity of this bug report to serious. [1] https://salsa.debian.org/systemd-team/systemd/blob/debian/238-1/debian/patches/debian/Make-logind-hostnamed-localed-timedated-D-Bus-activa.patch Saludos, Felipe Sateler -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-shim depends on: pn cgmanager ii libc6 2.27-3 ii libglib2.0-0 2.56.1-2 systemd-shim recommends no packages. Versions of packages systemd-shim suggests: pn pm-utils
Bug#901405: systemd-shim: Please add a sysvinit service to create directories on /run at boot
Package: systemd-shim Version: 10-3 Severity: normal User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: shim-patches-removal Hello Debian systemd-shim Maintainers, The Debian systemd package is currently carrying two debian-specific patches to enable usage of systemd-shim on Debian systems. In particular, we patch some code to continue even if /run/systemd/machines/ and /run/systemd/machines/ don't exist[1][2]. These two patches could be avoided if systemd-shim would create the relevant directories during early boot (sometime in rcS). Therefore we would like for systemd-shim to provide these directories so we can drop these patches. If you ship such a SysV init script, please make sure to mask that, so it is not accidentally run when systemd is the active PID 1 (assuming the SysV init script is called /etc/init.d/systemd-shim, the symlink would be /lib/systemd/system/systemd-shim.service → /dev/null). We intend to drop the patches before buster is released in the not too distant future. When we do that, we will bump the severity of this bug report to serious. [1] https://salsa.debian.org/systemd-team/systemd/blob/debian/238-1/debian/patches/debian/Start-logind-on-demand-via-libpam-systemd.patch [2] https://salsa.debian.org/systemd-team/systemd/blob/debian/238-1/debian/patches/debian/Make-sd_login_monitor_new-work-for-logind-without-sy.patch Saludos, Felipe Sateler -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-shim depends on: pn cgmanager ii libc6 2.27-3 ii libglib2.0-0 2.56.1-2 systemd-shim recommends no packages. Versions of packages systemd-shim suggests: pn pm-utils
Bug#901405: systemd-shim: Please add a sysvinit service to create directories on /run at boot
On Fri, Oct 19, 2018 at 10:45 AM Chris Ruvolo wrote: > > In particular, we patch some code to continue even if > > /run/systemd/machines/ and /run/systemd/machines/ don't exist[1][2]. > > Hi. Can you clarify the two directory names? I see the same one listed > twice. > Sorry, copy paste fail. The other directory is /run/systemd/seats/ . -- Saludos, Felipe Sateler
Bug#919213: irqbalance: endless loop during configure, system reaches maximum of open files
On Sun, 13 Jan 2019 18:10:57 +0100 Axel Beckert wrote: > Package: irqbalance > Version: 1.5.0-2 > Severity: serious > > On one of my systems (not the one I'm writing the report on), a > Raspberry Pi 2 with Debian Sid armhf and sysvinit, the terminal which I > ran the upgrade in, looked like this (excerpt): > > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d irqbalance defaults > Executing /usr/sbin/update-rc.d irqbalance enable > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d irqbalance defaults > Executing /usr/sbin/update-rc.d irqbalance enable > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... What are the versions of init-system-helpers and systemd? Since version 1.56, we use systemctl to enable links (which seems the case with your log), but for some reason SYSTEMCTL_SKIP_SYSV environment variable appears to not be respected. Saludos
Bug#940987: rdetails fails: TypeError: sequence item 0: expected str instance, bytes found
Package: apt-xapian-index
Version: 0.50
Severity: important
Hi,
Trying to issue axi-cache rdetails fails:
% axi-cache rdetails apt-xapian-index
Traceback (most recent call last):
File "/usr/bin/axi-cache", line 861, in
sys.exit(ui.perform())
File "/usr/bin/axi-cache", line 852, in perform
return f(self.args)
File "/usr/bin/axi-cache", line 718, in do_rdetails
print(name, tag, " ".join(deps))
TypeError: sequence item 0: expected str instance, bytes found
It seems the query is returning bytes instead of strings. Converting
with utf-8 makes it work (but I have no idea if this fix is correct):
deps = map(lambda x: x.decode('utf-8'), db.get_rdeps(name, pfx))
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt-xapian-index depends on:
ii python3 3.7.3-1
ii python3-apt 1.8.4
ii python3-debian 0.1.36
ii python3-xapian 1.4.12-2
apt-xapian-index recommends no packages.
Versions of packages apt-xapian-index suggests:
ii python3-xdg 0.25-5
-- no debconf information
Bug#796635: Systemd job
Hi Bryan,
On Thu, 17 Sep 2015 11:45:25 -0400 Bryan Quigley
wrote:
> Here is a debdiff that implements a systemd unit.
>
> (This is the first unit I've written, so review definitely needed)
Thanks for the patch. I agree with your previous comment that this
should maybe be a cronjob instead of boot script, but I get it that
you may want to keep the changes relatively minimal.
Some comments:
> diff -Nru nvi-1.81.6/debian/nvi.init nvi-1.81.6/debian/nvi.init
> --- nvi-1.81.6/debian/nvi.init1969-12-31 19:00:00.0 -0500
> +++ nvi-1.81.6/debian/nvi.init2015-09-16 22:54:43.0 -0400
> @@ -0,0 +1,21 @@
> +#!/bin/sh
> +### BEGIN INIT INFO
> +# Provides: nviboot
> +# Required-Start:$remote_fs
> +# Required-Stop:
> +# Default-Start: S
Why did you preserve runlevel S? I don't think this really belongs in
recovery mode.
> +# Default-Stop:
> +# Short-Description: Script to recover nvi edit sessions.
> +### END INIT INFO
> +
> +. /lib/lsb/init-functions
> +
> +case "$1" in
> + start)
> +/usr/share/vi/recover
+1 on moving the logic outside of init script.
> +;;
> + stop|restart|reload|force-reload)
restart (and force-reload?) should probably re-run the recovery script.
> +;;
> +esac
> +
> +exit 0
> diff -Nru nvi-1.81.6/debian/nvi.service nvi-1.81.6/debian/nvi.service
> --- nvi-1.81.6/debian/nvi.service 1969-12-31 19:00:00.0 -0500
> +++ nvi-1.81.6/debian/nvi.service 2015-09-16 22:54:51.0 -0400
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=To recover nvi edit sessions.
s/To r/R/ ?
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/share/vi/recover
> +
> +[Install]
> +WantedBy=multi-user.target
This will start after basic boot, which is good. I think the init
script should be changed to match this.
Also, the init script Provides: nviboot, so you should provide a link
from nviboot.service to nvi.service in /lib/systemd/system.
> diff -Nru nvi-1.81.6/debian/patches/30make_recover_script_init_ready.patch
> nvi-1.81.6/debian/patches/30make_recover_script_init_ready.patch
> --- nvi-1.81.6/debian/patches/30make_recover_script_init_ready.patch
> 1969-12-31 19:00:00.0 -0500
> +++ nvi-1.81.6/debian/patches/30make_recover_script_init_ready.patch
> 2015-09-17 11:10:01.0 -0400
> @@ -0,0 +1,72 @@
> +Description: Changes recover script so it can be run by init
> +This was mostly just merging code from the previous init script
> +Author: Bryan Quigley
> +
> +---
> +Bug-Debian: https://bugs.debian.org/796635
> +Bug-Ubuntu: https://launchpad.net/bugs/1489939
> +Forwarded: no
> +Last-Update: <2015-09-17>
> +
> +--- nvi-1.81.6.orig/dist/recover.in
> nvi-1.81.6/dist/recover.in
> +@@ -8,11 +8,18 @@ RECDIR="@vi_cv_path_preserve@"
> + SENDMAIL="@vi_cv_path_sendmail@"
> +
> + echo 'Recovering nvi editor sessions.'
> ++sessions_found=""
> +
> + # Check editor backup files.
> + vibackup=`echo $RECDIR/vi.*`
> + if [ "$vibackup" != "$RECDIR/vi.*" ]; then
> + for i in $vibackup; do
> ++# Discard symlinks
> ++if test -L $i ; then
> ++rm -f $i
> ++continue
> ++fi
> ++
> + # Only test files that are readable.
> + if test ! -r $i; then
> + continue
> +@@ -36,6 +43,12 @@ fi
> + virecovery=`echo $RECDIR/recover.*`
> + if [ "$virecovery" != "$RECDIR/recover.*" ]; then
> + for i in $virecovery; do
> ++# Discard symlinks
> ++if test -L $i ; then
> ++rm -f $i
> ++continue
> ++fi
> ++
> + # Only test files that are readable.
> + if test ! -r $i; then
> + continue
> +@@ -49,11 +62,21 @@ if [ "$virecovery" != "$RECDIR/recover.*
> + # Delete any recovery files that are zero length, corrupted,
> + # or that have no corresponding backup file. Else send mail
> + # to the user.
> +-recfile=`awk '/^X-vi-recover-path:/{print $2}' < $i`
> +-if test -n "$recfile" -a -s "$recfile"; then
> +-$SENDMAIL -t < $i
> +-else
> +-rm $i
> +-fi
> ++recfile=`awk '/^X-vi-recover-path:/{print $2}' < $i`
> ++if test -n "$recfile" -a -s "$recfile"; then
> ++sessions_found="yes"
> ++owner=`stat --format='%U' $recfile`
> ++(su - nobody -s /bin/sh -c "$SENDMAIL $owner < $i"
> &) /dev/null 2>&0
> ++else
> ++rm $i
> ++fi
> + done
> + fi
> ++
> ++if [ -n "$sessions_found" ] ; then
> ++echo "done."
> ++else
> ++echo "none found."
> ++fi
This is a behavior change: previously the recover script would not
print any output. Maybe this should not be printed?
> ++
> ++
> diff -Nru nvi-1.81.6/debian/
Bug#796635: Systemd job
On 2 November 2015 at 18:57, Bryan Quigley wrote: > Thanks for the review Felipe > >> Why did you preserve runlevel S? I don't think this really belongs in >> recovery mode. > Changed > >>> +;; >>> + stop|restart|reload|force-reload) >> >> restart (and force-reload?) should probably re-run the recovery script. > > Changed. > > >>> +Description=To recover nvi edit sessions. >> >> s/To r/R/ ? > +1 > >> Also, the init script Provides: nviboot, so you should provide a link >> from nviboot.service to nvi.service in /lib/systemd/system. > I changed it so it provided nvi. That was the whole reason I changed > the name afterall. OK. > >>> ++if [ -n "$sessions_found" ] ; then >>> ++echo "done." >>> ++else >>> ++echo "none found." >>> ++fi >> >> This is a behavior change: previously the recover script would not >> print any output. Maybe this should not be printed? > > The previous init script did print none found though. Maybe I'm worrying too much (I leave it to you to decide), but maybe people are using this in cronjobs or other scripted environments, and this changes the output. > >> Why do you invoke dh_systemd_enable manually? the --with=systemd above >> should do it. >> >>> + dh_installinit -- start 70 S . >> >> start argument is obsolete now and just invokes `defaults`, so this >> override can go. > > Because I didn't know what i was doing, oops. You removed the --no-start --no-restart-on-upgrade arguments to dh_systemd_start, are you sure you want to restart on package install/upgrade? > >> However, this changes the name of the init script from nviboot to nvi. >> This means you need to use dpkg-maintscript-helper to handle the >> rename, and remove the old enablement links as well. If you want to do >> this you might as well move it out of runlevel S ;) > > Moved out of runlevel S and it deletes nviboot correctly now. Cool. Except for 3 things: 1. Instead of adding the rm_connfile calls maually, you can use the dh_installdeb support. Check the manpage for details (basically, put the rm_conffile part only once in debian/nvi.maintscript). 2. This is not really a rm_conffile, but rather a mv_conffile (the script is renamed, not removed). 3. This will not preserve enable/disable modifications by the user. There is no simple solution for this (you need to check in preinst the state if differing from the default, and restore it in postinst for the new script name), so maybe just adding a note to NEWS.Debian suffices? Any modifications made to the init script will be lost anyways when using systemd as then only the service file will be used. Thanks for your work! -- Saludos, Felipe Sateler
Bug#796635: Systemd job
On 2 Nov 2015 18:58, "Bryan Quigley" wrote: > > Thanks for the review Felipe > > > Why did you preserve runlevel S? I don't think this really belongs in > > recovery mode. > Changed > > >> +;; > >> + stop|restart|reload|force-reload) > > > > restart (and force-reload?) should probably re-run the recovery script. > > Changed. > > > >> +Description=To recover nvi edit sessions. > > > > s/To r/R/ ? > +1 > > > Also, the init script Provides: nviboot, so you should provide a link > > from nviboot.service to nvi.service in /lib/systemd/system. > I changed it so it provided nvi. That was the whole reason I changed > the name afterall. > > >> ++if [ -n "$sessions_found" ] ; then > >> ++echo "done." > >> ++else > >> ++echo "none found." > >> ++fi > > > > This is a behavior change: previously the recover script would not > > print any output. Maybe this should not be printed? > > The previous init script did print none found though. > > > Why do you invoke dh_systemd_enable manually? the --with=systemd above > > should do it. > > > >> + dh_installinit -- start 70 S . > > > > start argument is obsolete now and just invokes `defaults`, so this > > override can go. > > Because I didn't know what i was doing, oops. > > > However, this changes the name of the init script from nviboot to nvi. > > This means you need to use dpkg-maintscript-helper to handle the > > rename, and remove the old enablement links as well. If you want to do > > this you might as well move it out of runlevel S ;) > > Moved out of runlevel S and it deletes nviboot correctly now. > Also, you might want to remove the - from the su call. A login shell is not required. Saludos
Bug#796635: Systemd job
On 3 November 2015 at 17:48, Bryan Quigley wrote:
> On Mon, Nov 2, 2015 at 5:24 PM, Felipe Sateler wrote:
>>>>> ++if [ -n "$sessions_found" ] ; then
>>>>> ++echo "done."
>>>>> ++else
>>>>> ++echo "none found."
>>>>> ++fi
>>>>
>>>> This is a behavior change: previously the recover script would not
>>>> print any output. Maybe this should not be printed?
>>>
>>> The previous init script did print none found though.
>>
>> Maybe I'm worrying too much (I leave it to you to decide), but maybe
>> people are using this in cronjobs or other scripted environments, and
>> this changes the output.
>
> I don't think there's an obvious win either way. Either it's closer
> the previous init script or to the previous recover script.
>
>>
>>>
>>>> Why do you invoke dh_systemd_enable manually? the --with=systemd above
>>>> should do it.
>>>>
>>>>> + dh_installinit -- start 70 S .
>>>>
>>>> start argument is obsolete now and just invokes `defaults`, so this
>>>> override can go.
>>>
>>> Because I didn't know what i was doing, oops.
>>
>> You removed the --no-start --no-restart-on-upgrade arguments to
>> dh_systemd_start, are you sure you want to restart on package
>> install/upgrade?
>
> Yea, I was thinking about that. Might as well let the script run on
> package upgrade. It shouldn't hurt anything and it might clear out
> old files before an upgrade on machines that haven't been restarted
> recently.
>
>>>> However, this changes the name of the init script from nviboot to nvi.
>>>> This means you need to use dpkg-maintscript-helper to handle the
>>>> rename, and remove the old enablement links as well. If you want to do
>>>> this you might as well move it out of runlevel S ;)
>>>
>>> Moved out of runlevel S and it deletes nviboot correctly now.
>>
>> Cool. Except for 3 things:
>>
>> 1. Instead of adding the rm_connfile calls maually, you can use the
>> dh_installdeb support. Check the manpage for details (basically, put
>> the rm_conffile part only once in debian/nvi.maintscript).
>
> Heh. that's much quicker. Thanks!
You need to remove the -- "$@" part: it is being added twice to the
resulting scripts (check debian/nvi/DEBIAN/{pre,post}* after a build):
dpkg-maintscript-helper rm_conffile /etc/init.d/nviboot 1.81.6-12 nvi
-- "$@" -- "$@"
>>
>> 2. This is not really a rm_conffile, but rather a mv_conffile (the
>> script is renamed, not removed).
>
> Really the init get's split up to nvi and the recover script. If the
> modified the recover script logic the mv_conffile wouldn't help them.
Indeed.
>
>>
>> 3. This will not preserve enable/disable modifications by the user.
>> There is no simple solution for this (you need to check in preinst the
>> state if differing from the default, and restore it in postinst for
>> the new script name), so maybe just adding a note to NEWS.Debian
>> suffices? Any modifications made to the init script will be lost
>> anyways when using systemd as then only the service file will be used.
>
> Added to to NEWS.Debian.
Great.
>
>>Also, you might want to remove the - from the su call. A login shell is not
>>require
> Done.
>
>> Thanks for your work!
> Thanks for all your work reviewing this! I learned a bunch.
After the above change I think this would be ready for upload. Can you
upload or do you need sponsoring? I can do the actual upload.
--
Saludos,
Felipe Sateler
Bug#796635: Systemd job
On 3 November 2015 at 18:15, Bryan Quigley wrote:
>> You need to remove the -- "$@" part: it is being added twice to the
>> resulting scripts (check debian/nvi/DEBIAN/{pre,post}* after a build):
>>
>> dpkg-maintscript-helper rm_conffile /etc/init.d/nviboot 1.81.6-12 nvi
>> -- "$@" -- "$@"
>>
>
>>>> Thanks for your work!
>>> Thanks for all your work reviewing this! I learned a bunch.
>>
>> After the above change I think this would be ready for upload. Can you
>> upload or do you need sponsoring? I can do the actual upload.
>
> I need sponsoring.
OK, I will take a look at uploading over the weekend.
--
Saludos,
Felipe Sateler
Bug#796635: Systemd job
On 3 November 2015 at 20:19, Felipe Sateler wrote:
> On 3 November 2015 at 18:15, Bryan Quigley
> wrote:
>>> You need to remove the -- "$@" part: it is being added twice to the
>>> resulting scripts (check debian/nvi/DEBIAN/{pre,post}* after a build):
>>>
>>> dpkg-maintscript-helper rm_conffile /etc/init.d/nviboot 1.81.6-12 nvi
>>> -- "$@" -- "$@"
>>>
>>
>>>>> Thanks for your work!
>>>> Thanks for all your work reviewing this! I learned a bunch.
>>>
>>> After the above change I think this would be ready for upload. Can you
>>> upload or do you need sponsoring? I can do the actual upload.
>>
>> I need sponsoring.
>
> OK, I will take a look at uploading over the weekend.
Uploaded with minor changelog edit:
* QA upload
* Add systemd job (Closes: #796635)
* Make recover script complete enough for use in init process
- Rename init script from nviboot to nvi, move out of runlevel S
* Cleanup
--
Saludos,
Felipe Sateler
Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Hi Roger, On 28 November 2015 at 11:12, Roger Shimizu wrote: > Dear systemd maintainers, > > I'm in the process of ITA adjtimex package, which contains a bug you > reported that need to support rcS service. I'm trying to fix this > before send out my 1st release to close ITA. Excellent! > >> Package: adjtimex >> Severity: important >> User: pkg-systemd-maintain...@lists.alioth.debian.org >> Usertags: init-rcs-service >> Your package adjtimex has an initscript that is enabled in runlevel >> S, but it does not provide a corresponding systemd service unit. > > As you may already know, adjtimex is a tool to set up kernel time > variables in boot time. Correct time and time ticking is important to > many services, including time-sync service, so in SysV world adjtimex > is run in rcS level, which is very early. > > Enclosed the "adjtimex.service" file I wrote and confirmed working > well on my box. > Since this is the first time I write service file, it would be helpful > if you can help to review it. I have some comments: > [Unit] > Description=adjtimex service in early boot I think the description of the init script is better: "set the kernel time variables". > ConditionFileIsExecutable=/etc/init.d/adjtimex I thin this is superflous. > DefaultDependencies=no > After=local-fs.target > Before=time-sync.target sysinit.target shutdown.target > Conflicts=shutdown.target I'm not sure about time-sync.target. `man systemd.special` says that time-sync.target is for synchronizing against a remote source, which AFAICT adjtimex doesn't do. Note that if what you wanted to do is to run before other time-synchronization daemons, this will not do it. sysinit.target should be ok, though. I don't think the conflict/before with shutdown.target is relevant, as this unit does nothing on stop, and thus does not need to do anything on shutdown. > > [Service] > Type=oneshot > ExecStart=/etc/init.d/adjtimex start I think you should call the program directly and bypass the init script. You can do as follows: # default values Environment=TICK=1 Environment=FREQ=0 # override as in the init script EnvironmentFile=-/etc/default/adjtimex ExecStart=/sbin/adjtimex -tick $TICK -frequency $FREQ > TimeoutSec=0 This is almost certainly wrong. I think you should skip this entry and leave it at the default. At some point the system needs to continue booting, even if the time is wrong, no? > StandardOutput=tty Do not set this, as this overrides the administrator default in /etc/systemd/system.conf. Let standard output go to the system-wide default. > #RemainAfterExit=yes I have seen that Type=oneshot services that do not have RemainAfterExit=yes can be executed multiple times during boot. This may or may not be a problem here. > > [Install] > WantedBy=sysinit.target > > I also have one doubt whether to have "RemainAfterExit=yes", which is > commented out now. > After setting the kernel time variables, adjtimex simply exits and > don't need to remain as daemon. I guess it should be okay to be "no". The RemainAfterExit directive controls wether systemd considers the unit "active" after all the running processes in the unit exited. This can trigger multiple runs during boot, if at some point this unit is wanted, but it already ran and exited. My sense is that RemainAfterExit should be =yes for most Type=oneshot service. Unfortunately, that means that to manually re-run the unit, one needs to do a "restart" instead of a "start" to make systemd run the program again. > > Looking forward to your reply. Thank you! Thank you for your contribution! -- Saludos, Felipe Sateler
Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
On 29 November 2015 at 11:04, Roger Shimizu wrote:
> Dear Felipe and Andreas,
>
> Your detailed feedback is really helpful.
> I really appreciate your kindness help!
>
> Enclosed my updated adjtimex.service file.
> Here's the explanation why I changed a bit.
>
>>> [Unit]
>>> Description=adjtimex service in early boot
>> I think the description of the init script is better: "set the kernel
>> time variables".
>
> I changed to "Description=the kernel time variables setting"
> Because it's more proper in the log with context:
>
> Nov 29 22:36:01 sid systemd[1]: Starting the kernel time variables setting...
> Nov 29 22:36:01 sid systemd[1]: Started the kernel time variables setting.
Note that this is not the only place that this description appears. It
also shows in the output of "systemctl status adjtimex.service", or
"systemctl list-units". This should really be a full descriptive
sentence. Maybe, "Adjust kernel time variables".
>
>>> #RemainAfterExit=yes
>> I have seen that Type=oneshot services that do not have
>> RemainAfterExit=yes can be executed multiple times during boot. This
>> may or may not be a problem here.
>> The RemainAfterExit directive controls wether systemd considers the
>> unit "active" after all the running processes in the unit exited. This
>> can trigger multiple runs during boot, if at some point this unit is
>> wanted, but it already ran and exited. My sense is that
>> RemainAfterExit should be =yes for most Type=oneshot service.
>> Unfortunately, that means that to manually re-run the unit, one needs
>> to do a "restart" instead of a "start" to make systemd run the program
>> again.
>
> Considering adjtimex is simply set time ticking related kernel
> variables on boot, it won't look after those kernel variables, which
> may be changed by other processes, such as NTP client, I think it's
> better to indicate the user that adjtimex service is NOT "active"
> after exiting. So I removed the line completely.
>
> If you're comfortable with this version of adjtimex.service, together
> with another minor fix, I'll build a package to upload to mentors, and
> ask for sponsor in mentors list.
> Environment="TICK=1 FREQ=0"
I don't think this works. There should be no quotes there, or systemd
might treat TICK variable as containing "1 FREQ=0".
> EnvironmentFile=-/etc/default/adjtimex
> ExecStart=/sbin/adjtimex -tick "$TICK" -frequency "$FREQ"
I think the quotes are superfluous. If you want to preserve quoting,
systemd does it by using ${TICK} and ${FREQ} syntax.
There is more information on using variables here:
http://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines
--
Saludos,
Felipe Sateler
Bug#796630: rdnssd: Has init script in runlevel S but no matching service file
On 22 December 2015 at 04:30, Andreas Henriksson wrote: > Control: tags -1 + patch > > Hello Felipe Sateler! Hi! > > On Sat, Aug 22, 2015 at 10:42:00PM -0300, fsate...@debian.org wrote: > [...] >> Your package rdnssd has an initscript that is enabled in runlevel S, >> but it does not provide a corresponding systemd service unit. > [...] > > Since rdnssd is QA-maintained, I looked into if I could create a > service file for it and ended up with the attached debdiff. > If you have time to have a look at it that would be great! Looks good. I'd also add the PIDFile option, because this daemon appears to spawn workers (systemd might guess incorrectly the main pid). -- Saludos, Felipe Sateler
