Bug#444980: udev not restarted after exiting runlevel 1

[Pierre Ynard]

Hello Michael,

> I don't think there is anything to fix on the udev side, as the
> process is killed by "/etc/init.d/rc single".

It's my understanding that this means that you believe udev shouldn't be
stopped in runlevel 1? I know that arguments have been brought forward
by others 10 years ago, but I wanted to know, what are your reasons
behind this opinion now?

Surely the technical hindrances with the init script aren't a blocker
anymore like they were back then? Are you opposed to adding LSB headers
to cleanly stop udev in runlevel 1 and restart it in runlevel 2? Why?

-- 
Pierre Ynard

Bug#444980: udev not restarted after exiting runlevel 1

[Dmitry Bogatov]

control: reassign -1 udev

[2019-02-19 15:01] Pierre Ynard 
> As said in the history of the thread, this isn't a problem particular
> to udev. portmap was mentioned. On my system I also have that issue
> with rdnssd: it is started in runlevel S before networking, and isn't
> restarted when leaving runlevel 1. Then there are all the network
> processes such as at least dhclient, and worse than not being restarted,
> the interfaces are not even marked as brought down when going into
> runlevel 1.
>
> I tried to fiddle with LSB headers and rc symlinks to get udev and
> rdnssd to restart in runlevel 2, but I guess I don't know how sysv-rc
> works anymore because I couldn't get anywhere, and anyway I don't
> want to mess with it too much. In the end I added restart logic in
> /etc/rc.local and it seems to work fine; and I switch in and out of
> runlevel 1 all the time.
>
> I don't see why we couldn't properly fix this to have each of them shut
> down cleanly in runlevel 1 and then restart in runlevel 2. When I look
> at udev's initscript, it seems like it must be much better in that
> regard now than what was described 10 years ago.

Probably we can, just nobody did it. Sorry, I am not up to this.

Reassigned to udev, since /etc/init.d/udev belongs to bin:udev.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#444980: udev not restarted after exiting runlevel 1

[Pierre Ynard]

As said in the history of the thread, this isn't a problem particular
to udev. portmap was mentioned. On my system I also have that issue
with rdnssd: it is started in runlevel S before networking, and isn't
restarted when leaving runlevel 1. Then there are all the network
processes such as at least dhclient, and worse than not being restarted,
the interfaces are not even marked as brought down when going into
runlevel 1.

I tried to fiddle with LSB headers and rc symlinks to get udev and
rdnssd to restart in runlevel 2, but I guess I don't know how sysv-rc
works anymore because I couldn't get anywhere, and anyway I don't
want to mess with it too much. In the end I added restart logic in
/etc/rc.local and it seems to work fine; and I switch in and out of
runlevel 1 all the time.

I don't see why we couldn't properly fix this to have each of them shut
down cleanly in runlevel 1 and then restart in runlevel 2. When I look
at udev's initscript, it seems like it must be much better in that
regard now than what was described 10 years ago.

-- 
Pierre Ynard

Bug#444980: udev not restarted after exiting runlevel 1

[Felipe Sateler]

On Sun, Jan 13, 2019 at 10:31 AM Dmitry Bogatov  wrote:

>
> [2019-01-11 14:34] KatolaZ 
> > On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
> > >
> > > [2019-01-08 14:32] Michael Biebl 
> > > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > > > >
> > > > > control: tags -1 +moreinfo
> > > > >
> > > > > Seems old discussion did not ended in solution. Let us try again.
> > > > >
> > > > > Dear udev maintainers, did anything changed? Are there still
> problems
> > > > > running /etc/init.d/udev from runlevel 1 (when udev daemon was
> killed)
> > > > > manually by sysadmin to restart it?
> > > > >
> > > >
> > > > That's not what this bug report is about.
> > > >
> > > > It's about udev being killed when switching to runlevel 1 and not
> being
> > > > restarted automatically when switching back to say runlevel 2.
> > > >
> > > > That issue is still valid today.
> > >
> > > I understand. Perfect solution would be move udev script (or part, that
> > > actually starts process/es) to stages (2 3 4 5)? Is it feasible today?
> > >
> >
> > I don't think it is possible, since udev gets started in early boot,
> > before filesystems are mounted, but I might be wrong.
>
> Yes, I see, that `mountdefsubsys', `procps' and number of other declare
> soft dependency (Should-Start:) on udev. Any idea, where can I find
> reasoning, why it is so?
>

I don't think you can move udev out of runlevel S. For example, mdadm
relies on udev to assemble arrays, so if you move udev out., you probably
won't be able to mount mdadm arrays.

-- 

Saludos,
Felipe Sateler

Bug#444980: udev not restarted after exiting runlevel 1

[Dmitry Bogatov]

[2019-01-11 14:34] KatolaZ 
> On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
> > 
> > [2019-01-08 14:32] Michael Biebl 
> > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > > > 
> > > > control: tags -1 +moreinfo
> > > > 
> > > > Seems old discussion did not ended in solution. Let us try again.
> > > > 
> > > > Dear udev maintainers, did anything changed? Are there still problems
> > > > running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
> > > > manually by sysadmin to restart it?
> > > >
> > >
> > > That's not what this bug report is about.
> > > 
> > > It's about udev being killed when switching to runlevel 1 and not being
> > > restarted automatically when switching back to say runlevel 2.
> > >
> > > That issue is still valid today.
> > 
> > I understand. Perfect solution would be move udev script (or part, that
> > actually starts process/es) to stages (2 3 4 5)? Is it feasible today?
> > 
> 
> I don't think it is possible, since udev gets started in early boot,
> before filesystems are mounted, but I might be wrong.

Yes, I see, that `mountdefsubsys', `procps' and number of other declare
soft dependency (Should-Start:) on udev. Any idea, where can I find
reasoning, why it is so?

Bug#444980: udev not restarted after exiting runlevel 1

[KatolaZ]

On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
> 
> [2019-01-08 14:32] Michael Biebl 
> > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > > 
> > > control: tags -1 +moreinfo
> > > 
> > > Seems old discussion did not ended in solution. Let us try again.
> > > 
> > > Dear udev maintainers, did anything changed? Are there still problems
> > > running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
> > > manually by sysadmin to restart it?
> > >
> >
> > That's not what this bug report is about.
> > 
> > It's about udev being killed when switching to runlevel 1 and not being
> > restarted automatically when switching back to say runlevel 2.
> >
> > That issue is still valid today.
> 
> I understand. Perfect solution would be move udev script (or part, that
> actually starts process/es) to stages (2 3 4 5)? Is it feasible today?
> 

I don't think it is possible, since udev gets started in early boot,
before filesystems are mounted, but I might be wrong.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

Bug#444980: udev not restarted after exiting runlevel 1

[Dmitry Bogatov]

[2019-01-08 14:32] Michael Biebl 
> Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > 
> > control: tags -1 +moreinfo
> > 
> > Seems old discussion did not ended in solution. Let us try again.
> > 
> > Dear udev maintainers, did anything changed? Are there still problems
> > running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
> > manually by sysadmin to restart it?
> >
>
> That's not what this bug report is about.
> 
> It's about udev being killed when switching to runlevel 1 and not being
> restarted automatically when switching back to say runlevel 2.
>
> That issue is still valid today.

I understand. Perfect solution would be move udev script (or part, that
actually starts process/es) to stages (2 3 4 5)? Is it feasible today?

Bug#444980: udev not restarted after exiting runlevel 1

[Michael Biebl]

Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> 
> control: tags -1 +moreinfo
> 
> Seems old discussion did not ended in solution. Let us try again.
> 
> Dear udev maintainers, did anything changed? Are there still problems
> running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
> manually by sysadmin to restart it?
> 

That's not what this bug report is about.

It's about udev being killed when switching to runlevel 1 and not being
restarted automatically when switching back to say runlevel 2.

That issue is still valid today.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Dmitry Bogatov]

control: tags -1 +moreinfo

Seems old discussion did not ended in solution. Let us try again.

Dear udev maintainers, did anything changed? Are there still problems
running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
manually by sysadmin to restart it?

[2010-06-05 09:05] Petter Reinholdtsen 
> [Henrique de Moraes Holschuh]
> > Trying to track that is a losing proposition. You'd also need to add
> > dhclient and other dhcp clients, wpa supplicant helpers, pppoe
> > helpers...
> 
> My idea is to implement some omitpid feature like the one we use for
> shutdown in the killprocs script, to allow udev to survive runlevel 1.
> With it in place, the other daemons that want to keep running can
> register their pid there.
> 
> > Our S runlevel does way too much, which obviously screws up runlevel
> > 1 a great deal.
> 
> Yeah.  There is a lot of work left before single user and runlevel 1
> on Debian is working properly, and allow one to enter runlevel 1 and
> return to runlevel 2.  At the moment a reboot is needed after
> switching to runlevel 1 to be sure to recover the machine state.
> 
> But udev should probably keep running also in runlevel 1, so such
> mechanism is probably smart to implement anyway.
> 
> Happy hacking,
> -- 
> Petter Reinholdtsen

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Henrique de Moraes Holschuh]
> Trying to track that is a losing proposition. You'd also need to add
> dhclient and other dhcp clients, wpa supplicant helpers, pppoe
> helpers...

My idea is to implement some omitpid feature like the one we use for
shutdown in the killprocs script, to allow udev to survive runlevel 1.
With it in place, the other daemons that want to keep running can
register their pid there.

> Our S runlevel does way too much, which obviously screws up runlevel
> 1 a great deal.

Yeah.  There is a lot of work left before single user and runlevel 1
on Debian is working properly, and allow one to enter runlevel 1 and
return to runlevel 2.  At the moment a reboot is needed after
switching to runlevel 1 to be sure to recover the machine state.

But udev should probably keep running also in runlevel 1, so such
mechanism is probably smart to implement anyway.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: [Pkg-sysvinit-devel] Bug#444980: udev not restarted after exiting runlevel 1

[Henrique de Moraes Holschuh]

On Sat, 29 May 2010, Fr�d�ric Bri�re wrote:
> On Thu, Sep 10, 2009 at 12:19:21PM +0200, Petter Reinholdtsen wrote:
> > Mentioned this issue to Scott James Remnant, and he suggested that it
> > is not right to kill all processes when entering runlevel 1.  It might
> 
> Seems strange indeed to kill processes that would already be running in
> runlevel S.
> 
> Anyway, I just wanted to add pppd to the short list of rcS.d daemons you
> compiled[*] a while ago.  Any PPP interface started from
> /etc/init.d/networking is currently torn down when going to rc1, and
> never brought up again.

Trying to track that is a losing proposition. You'd also need to add
dhclient and other dhcp clients, wpa supplicant helpers, pppoe helpers...

Our S runlevel does way too much, which obviously screws up runlevel 1 a
great deal.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Frédéric Brière]

On Thu, Sep 10, 2009 at 12:19:21PM +0200, Petter Reinholdtsen wrote:
> Mentioned this issue to Scott James Remnant, and he suggested that it
> is not right to kill all processes when entering runlevel 1.  It might

Seems strange indeed to kill processes that would already be running in
runlevel S.

Anyway, I just wanted to add pppd to the short list of rcS.d daemons you
compiled[*] a while ago.  Any PPP interface started from
/etc/init.d/networking is currently torn down when going to rc1, and
never brought up again.


 [*] 


-- 
I bet the human brain is a kludge.
-- Marvin Minsky



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Marco d'Itri]
> This looks wrong since pidof will probably return multiple values.

Yeah.  Probably need to loop over them all.

Mentioned this issue to Scott James Remnant, and he suggested that it
is not right to kill all processes when entering runlevel 1.  It might
be a good point, and that we should instead enforce that all services
that should stop in runlevel 1 should include a stop symlink in rc1.d/
It might be a better long term solution, but it would imediately break
a few packages, and leave user processes behind when switching from
runlevel 2 to 1.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

Here is a draft patch, if we decide to special case udev.  I'm not
sure we want it, but gave it a go to have a proposal on the table.
The patch is not tested.

Index: debian/initscripts/etc/init.d/killprocs
===
--- debian/initscripts/etc/init.d/killprocs (revision 1676)
+++ debian/initscripts/etc/init.d/killprocs (working copy)
@@ -13,9 +13,16 @@
 . /lib/lsb/init-functions

 do_start () {
-   # Kill all processes.
+   # Kill all processes, except udev, which should run in single
+   # user and runlevel 1.
+   OMITPIDS=""
+   if [ -x /sbin/udevd ] ; then
+   pid=$(pidof /sbin/udevd)
+   OMITPIDS="${OMITPIDS:+$OMITPIDS }-o $pid"
+
+   fi
log_action_begin_msg "Asking all remaining processes to terminate"
-   killall5 -15 # SIGTERM
+   killall5 $OMITPIDS -15 # SIGTERM
log_action_end_msg 0
alldead=""
for seq in 1 2 3 4 5 6 7 8 9 10; do
@@ -25,7 +32,7 @@
# sense to wait for processes to die, or it fail and
# there is nothing to wait for.

-   if killall5 -18 ; then
+   if killall5 $OMITPIDS -18 ; then
:
else
alldead=1
@@ -36,7 +43,7 @@
done
if [ -z "$alldead" ] ; then
log_action_begin_msg "Killing all remaining processes"
-   killall5 -9 # SIGKILL
+   killall5 $OMITPIDS -9 # SIGKILL
log_action_end_msg 1
else
log_action_begin_msg "All processes ended within $seq seconds."

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: [Pkg-sysvinit-devel] Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Marco d'Itri]
> It is /, but what can be done to the root file system with /dev
> mounted on it?

It can be inaccesable/inresponsive when killall5 is running, for
example if it is a fuser file system, because the user space process
needed to access / is SIGSTOPed.  It migth be safer to chdir to /dev/
to make sure udevd do not have to look up / to update /dev/.

>> BTW, if udevd should survive runlevel 1 (which is not the same as
>> single user), there need to be start symlink in rc1.d/.
> Why if it is not going to be killed?

My idea was to make sure it isn't started again when switching from
runlevel 1 to any of 2-5.  But if udev do not have start symlinks in
runlevels 2-5 either, that should not be needed.  Ie either

  Default-start: S
  Default-stop:

or

  Default-Start: S 1 2 3 4 5
  Default-Stop:

Should work if killprocs do not kill udevd, and I see now that udev
uses the former.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Aug 31, Petter Reinholdtsen  wrote:

> What is the working directory of the udev process?  I hope it is
> /dev/, to avoid issues with / if something need to be done to the root
> file system.
It is /, but what can be done to the root file system with /dev mounted
on it?

> Is there a pid file around, to make sure the correct process and not
> just any process named udev is available?  Could you create one?  Why
No (udevd is started well before there is a writeable file system, and
there are also the child processes).
If somebody has other processes named udevd around he deserves any
trouble he gets.

> did you propose to use pgrep instead of pidof, btw?  'pidof
> /sbin/udevd' sime like a safer alternative, as it check the process
> inode info to make sure the correct process is found.
No real reason.

> BTW, if udevd should survive runlevel 1 (which is not the same as
> single user), there need to be start symlink in rc1.d/.
Why if it is not going to be killed?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Marco d'Itri]
> The only files udev keeps open are on /dev, and it's almost
> impossible to unmount it anyway. I am not aware of other daemons
> which should run in single user mode.

What is the working directory of the udev process?  I hope it is
/dev/, to avoid issues with / if something need to be done to the root
file system.

If udev indeed should run in single user mode and runlevel 1, we
should try to find a way to make that happen.

> Since without udev /dev will not stay in sync with reality I think
> it is reasonable to believe that it is a fundamental system
> component which should be active even in single user mode.  I also
> argue that it should not even be stopped, because then events may be
> lost.

Right.

Is there a pid file around, to make sure the correct process and not
just any process named udev is available?  Could you create one?  Why
did you propose to use pgrep instead of pidof, btw?  'pidof
/sbin/udevd' sime like a safer alternative, as it check the process
inode info to make sure the correct process is found.

BTW, if udevd should survive runlevel 1 (which is not the same as
single user), there need to be start symlink in rc1.d/.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: [Pkg-sysvinit-devel] Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Aug 30, Petter Reinholdtsen  wrote:

> I guess the design question that need to be decided, is if udev should
> be running in runlevel 1 or not, and that again depend on the
> understanding of what runlevel 1 should be.  In my head, runlevel 1
So far nobody provided a compelling argument about why it should not.

> should give the sysadmin a system without any daemons running, to be
> able to edit files and partitions without having any processes
> blocking the work.
The only files udev keeps open are on /dev, and it's almost impossible
to unmount it anyway. I am not aware of other daemons which should run
in single user mode.
Since without udev /dev will not stay in sync with reality I think it
is reasonable to believe that it is a fundamental system component which
should be active even in single user mode.
I also argue that it should not even be stopped, because then events may
be lost.

> I am not very fond of special casing for individual packages in the
> initscripts package, and very reluctant to add such code in
> init.d/killprocs.
I am also not very fond of adding complexity to my packages because the
maintainers of other packages are unwilling to properly fix bugs in
their own package, so we may have a problem here.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: [Pkg-sysvinit-devel] Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Marco d'Itri]
> I do not believe that the best fix for this bug should happen in the
> udev package.

Can you explain why you do not believe the fix should happen in udev?

Personally, I believe the best solution would be to add a simpler
script in runlevels 2 to 5 to restart udev if it was stopped in
runlevel 1, and only use the existing udev script with a lot of extra
stuff going on in rcS.d/.

I guess the design question that need to be decided, is if udev should
be running in runlevel 1 or not, and that again depend on the
understanding of what runlevel 1 should be.  In my head, runlevel 1
should give the sysadmin a system without any daemons running, to be
able to edit files and partitions without having any processes
blocking the work.

> A simple fix could be something like:
> 
> DONTKILL=$(for p in $(pgrep udev); do echo "-o $p"; done)
> killall5 $DONTKILL
> 
> Feel free to close this bug if you do not want to modify initscripts.

I am not very fond of special casing for individual packages in the
initscripts package, and very reluctant to add such code in
init.d/killprocs.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

reassign 444980 initscripts
thanks

I do not believe that the best fix for this bug should happen in the
udev package.
A simple fix could be something like:

DONTKILL=$(for p in $(pgrep udev); do echo "-o $p"; done)
killall5 $DONTKILL

Feel free to close this bug if you do not want to modify initscripts.

On Jul 07, Marco d'Itri  wrote:

> On Jul 07, Frans Pop  wrote:
> 
> > I don't think so. Single user mode is for sysadmin tasks and I'd say that 
> > the udev daemon should be running for those as performing those tasks 
> > could result it udev triggers being generated, which should be processed.
> What could I do then? /etc/rc1.d/S30killprocs does not allow excluding
> processes.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Aug 24, Raphael Geissert  wrote:

> Couldn't that extra functionality be split up in an extra init script? so 
> that 
No, it could not (with enough time and money most things can be done,
but this does not mean that it would also be a good idea to try).
There are specific actions which have to be performed before and after
starting the daemon.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Raphael Geissert]

Hi Marco,

On Saturday 22 August 2009 14:12:57 Marco d'Itri wrote:
> On Aug 22, Petter Reinholdtsen  wrote:
> > If it is safe to start udev using the init.d script after the daemon
> > was killed by killprocs, this would work also for udev.  If you want a
>
> It is not, the udev init script does much more than start the daemon (it
> could be argued that this is a problem in itself, but nobody has
> proposed a better solution so far so it's what we need to work with).
> How difficult it would be to whitelist udevd and just not kill it?

Couldn't that extra functionality be split up in an extra init script? so that 
one truly becomes an rcS script while the other, the one starting the daemon, 
is started during rcS and rc2-5. On a quick glance to the init script it 
doesn't look that difficult, and as for the rest it is similar to the fact 
that udev is already being started during the initrd and resumed later, 
right?

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Aug 22, Petter Reinholdtsen  wrote:

> Not sure, but I suspect it really is not wanted behaviour.  I suspect
> the comment from Wouter Verhelst is spot on, and runlevel 1 is what
> single user mode should be, ie 'the bare minimum for the system to
> work'.  No daemons should block umounting of file systems or otherwise
> get in the way of the sysadmin trying to fix stuff that need single
> user mode to be fixed. :)
udev will not prevent unmounting file systems, but lack of udev may
get in the way of fixing stuff...

> Adding such omitpid feature would probably end up being used by
> several packages over time, and slowly making runlevel 1 less and less
> useful.
So whitelist just udev?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

[Marco d'Itri]
> It is not, the udev init script does much more than start the daemon
> (it could be argued that this is a problem in itself, but nobody has
> proposed a better solution so far so it's what we need to work
> with).

Hm, sad.

> How difficult it would be to whitelist udevd and just not kill it?

Not sure, but I suspect it really is not wanted behaviour.  I suspect
the comment from Wouter Verhelst is spot on, and runlevel 1 is what
single user mode should be, ie 'the bare minimum for the system to
work'.  No daemons should block umounting of file systems or otherwise
get in the way of the sysadmin trying to fix stuff that need single
user mode to be fixed. :)

Adding such omitpid feature would probably end up being used by
several packages over time, and slowly making runlevel 1 less and less
useful.

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Aug 22, Petter Reinholdtsen  wrote:

> If it is safe to start udev using the init.d script after the daemon
> was killed by killprocs, this would work also for udev.  If you want a
It is not, the udev init script does much more than start the daemon (it
could be argued that this is a problem in itself, but nobody has
proposed a better solution so far so it's what we need to work with).
How difficult it would be to whitelist udevd and just not kill it?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Petter Reinholdtsen]

Saw your request on d...@. :)

This problem seem similar to the problem with portmap, which also is
killed when entering runlevel 1.  It will start from rcS.d, but also
have a start script in runlevels 2 - 5 which do nothing if portmap is
already running and only trigger when returning from runlevel 1.

If it is safe to start udev using the init.d script after the daemon
was killed by killprocs, this would work also for udev.  If you want a
controlled killing of udev in runlevel 1, it is better to install a
stop symlink in rc1.d than leave it to killprocs.

Ie something like this in the header might do it.

# Default-Start: S 2 3 4 5
# Default-Stop:  1

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Jul 09, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> I would tend to disagree. 'single user mode' means 'the bare minimum for
> the system to work'; provided the system still has a static /dev if udev
> is not active (it does, right?), udev is not required at all for
> single user.
If the system is switched to single user mode it will still have the
original /dev, which is hard to be unmounted automatically without
causing troubles.
And trying would be a stupid idea anyway, people actually use the
persistent device names created by udev.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Wouter Verhelst]

On Mon, Jul 07, 2008 at 04:56:02PM +0200, Frans Pop wrote:
> Marco d'Itri wrote:
> > Actually, should udev be killed at all when switching to single user
> > mode?
> 
> I don't think so. Single user mode is for sysadmin tasks and I'd say that 
> the udev daemon should be running for those as performing those tasks 
> could result it udev triggers being generated, which should be processed.

I would tend to disagree. 'single user mode' means 'the bare minimum for
the system to work'; provided the system still has a static /dev if udev
is not active (it does, right?), udev is not required at all for
single user.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

On Jul 07, Frans Pop <[EMAIL PROTECTED]> wrote:

> I don't think so. Single user mode is for sysadmin tasks and I'd say that 
> the udev daemon should be running for those as performing those tasks 
> could result it udev triggers being generated, which should be processed.
What could I do then? /etc/rc1.d/S30killprocs does not allow excluding
processes.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Frans Pop]

Marco d'Itri wrote:
> Actually, should udev be killed at all when switching to single user
> mode?

I don't think so. Single user mode is for sysadmin tasks and I'd say that 
the udev daemon should be running for those as performing those tasks 
could result it udev triggers being generated, which should be processed.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Bug#444980: udev not restarted after exiting runlevel 1

[Marco d'Itri]

Actually, should udev be killed at all when switching to single user
mode?
Do we have a definition of how single user mode should work?

Obviously I am not looking forward to make the udev init script even
more complex.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#444980: udev not restarted after exiting runlevel 1

[Tomassino Ferrauto]

Package: udev
Version: 0.114-2
Severity: normal

When entering runlevel 1 udevd is killed but it is not restarted when exiting 
runlevel 1 and going back
to runlevel 2. I think this is due to the fact that the script starting udev is 
in rcS.d and it doesn't
get re-executed when going back to multi-user mode. However it seems correct to 
me that that script
is not re-executed as it does things not needed on udev restart. It seems to me 
that there are two
possibilities: let udevd remain active also in single-user mode or add another 
script in rc{2,3,4,5}.d
that starts udev (if it has not already started).

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 24
lrwxrwxrwx 1 root root   13 2007-10-02 14:31 010_ipod.rules -> ../ipod.rules
lrwxrwxrwx 1 root root   23 2007-10-02 14:31 010-no-legacy-ptys.rules -> 
../no-legacy-ptys.rules
lrwxrwxrwx 1 root root   21 2007-10-02 14:31 011_key_usbstick.rules -> 
../key_usbstick.rules
lrwxrwxrwx 1 root root   20 2007-10-02 14:31 020_permissions.rules -> 
../permissions.rules
lrwxrwxrwx 1 root root   19 2007-10-02 14:31 025_libgphoto2.rules -> 
../libgphoto2.rules
lrwxrwxrwx 1 root root   16 2007-10-02 14:31 025_libsane.rules -> 
../libsane.rules
lrwxrwxrwx 1 root root   22 2007-10-02 14:31 025_logitechmouse.rules -> 
../logitechmouse.rules
lrwxrwxrwx 1 root root   15 2007-10-02 14:31 85-pcmcia.rules -> ../pcmcia.rules
lrwxrwxrwx 1 root root   16 2007-10-02 14:31 libmtp6.rules -> ../libmtp6.rules
lrwxrwxrwx 1 root root   15 2007-10-02 14:31 libnjb.rules -> ../libnjb.rules
lrwxrwxrwx 1 root root   13 2007-10-02 14:31 udev.rules -> ../udev.rules
lrwxrwxrwx 1 root root   25 2007-10-02 14:31 z20_persistent-input.rules -> 
../persistent-input.rules
lrwxrwxrwx 1 root root   19 2007-10-02 14:31 z20_persistent.rules -> 
../persistent.rules
-rw-r--r-- 1 root root  671 2006-08-28 18:10 z25_persistent-cd.rules
-rw-r--r-- 1 root root  583 2006-08-28 18:10 z25_persistent-net.rules
lrwxrwxrwx 1 root root   33 2007-10-02 14:31 z45_persistent-net-generator.rules 
-> ../persistent-net-generator.rules
lrwxrwxrwx 1 root root   12 2007-10-02 14:31 z50_run.rules -> ../run.rules
lrwxrwxrwx 1 root root   16 2007-10-02 14:31 z55_hotplug.rules -> 
../hotplug.rules
lrwxrwxrwx 1 root root   19 2007-10-02 14:31 z60_alsa-utils.rules -> 
../alsa-utils.rules
lrwxrwxrwx 1 root root   15 2007-10-02 14:31 z60_hdparm.rules -> ../hdparm.rules
-rw-r--r-- 1 root root 2589 2007-06-03 22:17 z60_libpisock9.rules
-rw-r--r-- 1 root root   80 2007-09-01 10:52 z60_virtualbox.rules
-rw-r--r-- 1 root root 5716 2007-06-02 19:21 z60_xserver-xorg-input-wacom.rules
lrwxrwxrwx 1 root root   29 2007-10-02 14:31 z75_cd-aliases-generator.rules -> 
../cd-aliases-generator.rules
lrwxrwxrwx 1 root root   12 2007-10-02 14:31 z99_hal.rules -> ../hal.rules

-- /sys/:
/sys/block/dm-0/dev
/sys/block/dm-1/dev
/sys/block/dm-2/dev
/sys/block/dm-3/dev
/sys/block/dm-4/dev
/sys/block/dm-5/dev
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hdc/dev
/sys/block/loop0/dev
/sys/block/loop10/dev
/sys/block/loop11/dev
/sys/block/loop12/dev
/sys/block/loop13/dev
/sys/block/loop14/dev
/sys/block/loop15/dev
/sys/block/loop16/dev
/sys/block/loop17/dev
/sys/block/loop18/dev
/sys/block/loop19/dev
/sys/block/loop1/dev
/sys/block/loop2/dev
/sys/block/loop3/dev
/sys/block/loop4/dev
/sys/block/loop5/dev
/sys/block/loop6/dev
/sys/block/loop7/dev
/sys/block/loop8/dev
/sys/block/loop9/dev
/sys/class/drm/card0/dev
/sys/class/drm/card1/dev
/sys/class/graphics/fb0/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input3/event3/dev
/sys/class/input/input4/event4/dev
/sys/class/input/input5/event5/dev
/sys/class/input/input5/mouse0/dev
/sys/class/input/input5/ts0/dev
/sys/class/input/input6/event6/dev
/sys/class/input/input7/event7/dev
/sys/class/input/input7/mouse1/dev
/sys/class/input/input7/ts1/dev
/sys/class/input/input8/event8/dev
/sys/class/input/input8/mouse2/dev
/sys/class/input/input8/ts2/dev
/sys/class/input/mice/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/hpet/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/misc/snapshot/dev
/sys/class/sound/adsp/dev
/sys/class/sound/audio1/dev
/sys/class/sound/audio/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/controlC1/dev
/sys/class/sound/dsp1/dev
/sys/class/sound/dsp/dev
/sys/class/sound/mixer1/dev
/sys/class/sound/mixer/dev
/sys/class/sound/pcmC0D0c/dev
/sys/class/sound/pcmC0D0p/dev
/sys/class/sound/pcmC0D1c/dev
/sys/class/sound/pcmC0D2c/dev
/sys/class/sound/pcmC0D3c/dev
/sys/class/sound/pcmC0D4p/dev
/sys/class/sound/pcmC1D0c/dev
/sys/class/sound/pcmC1D0p/dev
/sys/class/sound/seq/dev
/sys/class/sound/sequencer2/dev
/sys/class/sound/sequencer/dev
/sys/class/sound/timer/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev1.3/dev
/sys/class/usb_device/usbdev2.1/dev
/sys/class/usb_device/usbdev3.1/dev
/sys/clas