9:33 a.m.
Greetings;
For years, I have been starting fetchmail as a background daemon by having the
line:
su user -c "fetchmail -d etc etc" in my rc.local script.
Forced to re-install because something wiped the partition table on my boot
drive, I installed F8 and I believe its was uptodate as of last night.
But, its not running anymore via that procedure, and setroubleshoot's gui will
display that it was denied at the time of the boot.
It still works perfectly if I cut/paste that line into a root shell after I'm
logged in.
How can I address this?
I've also bz'd it.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I've found my niche. If you're wondering why I'm not there, there was
this little hole in the bottom ...
-- John Croll
1:32 p.m.
Gene Heskett wrote:
For years, I have been starting fetchmail as a background daemon by
having the line:
su user -c "fetchmail -d etc etc" in my rc.local script.
Forced to re-install because something wiped the partition table on
my boot drive, I installed F8 and I believe its was uptodate as of
last night.
But, its not running anymore via that procedure, and
setroubleshoot's gui will display that it was denied at the time of
the boot.
It still works perfectly if I cut/paste that line into a root shell
after I'm logged in.
How can I address this?
I've got similar things in /etc/rc.local that used to use su -c. I
don't recall having them get denied outright, but the programs that
were run definitely didn't pick up the proper SELinux contexts. So I
now have a few entries like this:
runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's no trick to being a humorist when you have the whole
government working for you.
-- Will Rogers.
3:46 p.m.
On Sunday 06 January 2008, Todd Zullinger wrote:
Gene Heskett wrote:
> For years, I have been starting fetchmail as a background daemon by
> having the line:
> su user -c "fetchmail -d etc etc" in my rc.local script.
>
> Forced to re-install because something wiped the partition table on
> my boot drive, I installed F8 and I believe its was uptodate as of
> last night.
>
> But, its not running anymore via that procedure, and
> setroubleshoot's gui will display that it was denied at the time of
> the boot.
>
> It still works perfectly if I cut/paste that line into a root shell
> after I'm logged in.
>
> How can I address this?
I've got similar things in /etc/rc.local that used to use su -c. I
don't recall having them get denied outright, but the programs that
were run definitely didn't pick up the proper SELinux contexts. So I
now have a few entries like this:
runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz
I'm afraid I have pretty close to a NDI what that will do, Todd. And your use
of the words 'used to' above also tells be your are doing this su user -c
function differently now. Can you elaborate? The manpage for runcon is so
concise as to be obtuse.
Here is the line in question, in rc.local, that does not now work:
su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
Can you translate that into a 'runcon' style line please?
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Failure is not an option -- it comes bundled with Windows.
4:06 p.m.
Gene Heskett wrote:
>I've got similar things in /etc/rc.local that used to use su
-c. I
>don't recall having them get denied outright, but the programs that
>were run definitely didn't pick up the proper SELinux contexts. So I
>now have a few entries like this:
>
>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz
I'm afraid I have pretty close to a NDI what that will do, Todd.
And your use of the words 'used to' above also tells be your are
doing this su user -c function differently now. Can you elaborate?
The manpage for runcon is so concise as to be obtuse.
I noticed that the processes I started with su -c didn't have the
proper SELinux contexts, so that's why I added the runcon call. It
sets up the processes to use the same contexts as they would get if I
had logged in as tmz and run them (AFAIK). Using runuser is very
similar to using su. I don't know if you'd have any problems using su
instead of runuser or not. I'm far from knowledgeable on the subject.
Here is the line in question, in rc.local, that does not now work:
su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
Can you translate that into a 'runcon' style line please?
Sure. (No guarantees that this is the best or most correct way. :)
runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene
(I think I'd remove the --fetchmailrc option since ~/.fetchmailrc is
the default and using the -l option to runuser will make the command
run as gene, so ~/.fetchmailrc will be /home/gene/.fetchmailrc. But
that shouldn't matter at all in regards to SELinux.)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The kind of man who wants the government to adopt and enforce his
ideas is always the kind of man whose ideas are idiotic.
-- H. L. Mencken
2:19 a.m.
On Sunday 06 January 2008, Todd Zullinger wrote:
Gene Heskett wrote:
>>I've got similar things in /etc/rc.local that used to use su -c. I
>>don't recall having them get denied outright, but the programs that
>>were run definitely didn't pick up the proper SELinux contexts. So I
>>now have a few entries like this:
>>
>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz
>
> I'm afraid I have pretty close to a NDI what that will do, Todd.
> And your use of the words 'used to' above also tells be your are
> doing this su user -c function differently now. Can you elaborate?
> The manpage for runcon is so concise as to be obtuse.
I noticed that the processes I started with su -c didn't have the
proper SELinux contexts, so that's why I added the runcon call. It
sets up the processes to use the same contexts as they would get if I
had logged in as tmz and run them (AFAIK). Using runuser is very
similar to using su. I don't know if you'd have any problems using su
instead of runuser or not. I'm far from knowledgeable on the subject.
> Here is the line in question, in rc.local, that does not now work:
>
> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
>
> Can you translate that into a 'runcon' style line please?
Sure. (No guarantees that this is the best or most correct way. :)
runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene
(I think I'd remove the --fetchmailrc option since ~/.fetchmailrc is
the default and using the -l option to runuser will make the command
run as gene, so ~/.fetchmailrc will be /home/gene/.fetchmailrc. But
that shouldn't matter at all in regards to SELinux.)
Now I have a more pressing problem. If I exec that file after booting and
logging in I get a bunch of rejects from several things I tried to convert so
they weren't running as root, like heyu, so I took those back out, but the
fetchmail line says this:
starting fetchmail
user_u:system_r:unconfined_t is not a valid context
And fetchmail is not running.
But the bigger problem is that according to the trace I can see by shift
pageup as soon as I log in from a fresh reboot, there is absolutely nothing
showing to indicate that S99local ever ran, nothing in that file is echoed or
performed. setroubleshooter is also silent on the subject.
I can post this rc.local if you'd like.
An ls -lZ on it:
-rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local
And I just did an autorelabel. I've been following setroubleshooter's advice
& doing the semanage things too so hopefully I won't need to do them again.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Please don't recommend me to your friends-- it's difficult enough to
cope with you alone.
9:29 a.m.
On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote:
On Sunday 06 January 2008, Todd Zullinger wrote:
>Gene Heskett wrote:
>>>I've got similar things in /etc/rc.local that used to use su -c. I
>>>don't recall having them get denied outright, but the programs that
>>>were run definitely didn't pick up the proper SELinux contexts. So I
>>>now have a few entries like this:
>>>
>>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm"
tmz
>>
>> I'm afraid I have pretty close to a NDI what that will do, Todd.
>> And your use of the words 'used to' above also tells be your are
>> doing this su user -c function differently now. Can you elaborate?
>> The manpage for runcon is so concise as to be obtuse.
>
>I noticed that the processes I started with su -c didn't have the
>proper SELinux contexts, so that's why I added the runcon call. It
>sets up the processes to use the same contexts as they would get if I
>had logged in as tmz and run them (AFAIK). Using runuser is very
>similar to using su. I don't know if you'd have any problems using su
>instead of runuser or not. I'm far from knowledgeable on the subject.
>
>> Here is the line in question, in rc.local, that does not now work:
>>
>> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
>>
>> Can you translate that into a 'runcon' style line please?
>
>Sure. (No guarantees that this is the best or most correct way. :)
>
>runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene
for F8 I think it should be "unconfined_u:system_r:unconfined_t" for
rawhide i think it is "unconfined_u:unconfined_r:unconfined_t"
I don't really understand the rest of what you are asking... typically
we on list like to see the output of ausearch -m AVC -ts recent or some
other form of the raw denial (its at the bottom of the setroubleshoot
output) so we actually know what is failing.
-Eric
10:23 a.m.
On Monday 07 January 2008, Eric Paris wrote:
On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote:
> On Sunday 06 January 2008, Todd Zullinger wrote:
> >Gene Heskett wrote:
> >>>I've got similar things in /etc/rc.local that used to use su -c. I
> >>>don't recall having them get denied outright, but the programs that
> >>>were run definitely didn't pick up the proper SELinux contexts. So
I
> >>>now have a few entries like this:
> >>>
> >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen
-dm" tmz
> >>
> >> I'm afraid I have pretty close to a NDI what that will do, Todd.
> >> And your use of the words 'used to' above also tells be your are
> >> doing this su user -c function differently now. Can you elaborate?
> >> The manpage for runcon is so concise as to be obtuse.
> >
> >I noticed that the processes I started with su -c didn't have the
> >proper SELinux contexts, so that's why I added the runcon call. It
> >sets up the processes to use the same contexts as they would get if I
> >had logged in as tmz and run them (AFAIK). Using runuser is very
> >similar to using su. I don't know if you'd have any problems using su
> >instead of runuser or not. I'm far from knowledgeable on the subject.
> >
> >> Here is the line in question, in rc.local, that does not now work:
> >>
> >> su gene -c "fetchmail -d 90 --fetchmailrc
/home/gene/.fetchmailrc"
> >>
> >> Can you translate that into a 'runcon' style line please?
> >
> >Sure. (No guarantees that this is the best or most correct way. :)
> >
> >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90"
> > gene
for F8 I think it should be "unconfined_u:system_r:unconfined_t" for
rawhide i think it is "unconfined_u:unconfined_r:unconfined_t"
and both of those return "invalid context" and fetchmail is not started.
I don't really understand the rest of what you are asking...
typically
we on list like to see the output of ausearch -m AVC -ts recent or some
other form of the raw denial (its at the bottom of the setroubleshoot
output) so we actually know what is failing.
That output of "ausearch -m AVC -ts recent" is empty, as is the
setroubleshoot screen after running rc.local three times just now.
The larger problem ATM is that rc.local is NOT being executed at the
end of the bootup. And yet:
root@coyote ~]# ls -l /etc/rc.d/rc3.d/S99local
lrwxrwxrwx 1 root root 11 2008-01-04 22:39 /etc/rc.d/rc3.d/S99local -> ../rc.local
and
[root@coyote ~]# ls -lZ /etc/rc.d/rc3.d/S99local
lrwxrwxrwx root root system_u:object_r:etc_t:s0 /etc/rc.d/rc3.d/S99local ->
../rc.local
and
[root@coyote ~]# ls -lZ /etc/rc.d/rc.local
-rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local
I boot and login at runlevel 3, the everything but X, then run startx by hand.
I'm a big dummy maybe, and an old fart, but *I* can run it by using the
S99local link exactly the same as it real name, so why doesn't init run it?
I should be seeing in my login console, all of this:
------------
[root@coyote ~]# /etc/rc.d/rc.local
/root/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/bin
/usr/local/mozilla /usr/lib/qt-3.3
restoring audio settings
starting heyu
heyu_engine is running - use 'heyu restart' to reconfigure
CM11A clock set to Mon, 11:03:52 (Standard Time), Day 6
Emulating macro Dawn_Off at address 1013
heyu started
LATITUDE=39:41 LONGITUDE=80:17
starting fetchmail
user_u:system_r:unconfined_t is not a valid context
starting drift-checker
adding shop.coyote.den to xhost access list
5279 ttyUSB0 00:00:00 heyu
5281 ? 00:00:38 heyu
20736 ? 00:00:00 heyu
4097 ? 00:00:04 fetchmail
restoreing midi playback to Audigy 2 card
setup env for nitros9 development
ssh
/opt/os9
--------------
But I am not.
Thanks Eric.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Don't hate me because I'm beautiful. Hate me because I'm beautiful,
smart
and rich."
-- Calvin Keegan
10:53 a.m.
On Mon, 2008-01-07 at 11:23 -0500, Gene Heskett wrote:
On Monday 07 January 2008, Eric Paris wrote:
>On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote:
>> On Sunday 06 January 2008, Todd Zullinger wrote:
>> >Gene Heskett wrote:
>> >>>I've got similar things in /etc/rc.local that used to use su -c.
I
>> >>>don't recall having them get denied outright, but the programs
that
>> >>>were run definitely didn't pick up the proper SELinux contexts.
So I
>> >>>now have a few entries like this:
>> >>>
>> >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen
-dm" tmz
>> >>
>> >> I'm afraid I have pretty close to a NDI what that will do, Todd.
>> >> And your use of the words 'used to' above also tells be your
are
>> >> doing this su user -c function differently now. Can you elaborate?
>> >> The manpage for runcon is so concise as to be obtuse.
>> >
>> >I noticed that the processes I started with su -c didn't have the
>> >proper SELinux contexts, so that's why I added the runcon call. It
>> >sets up the processes to use the same contexts as they would get if I
>> >had logged in as tmz and run them (AFAIK). Using runuser is very
>> >similar to using su. I don't know if you'd have any problems using
su
>> >instead of runuser or not. I'm far from knowledgeable on the subject.
>> >
>> >> Here is the line in question, in rc.local, that does not now work:
>> >>
>> >> su gene -c "fetchmail -d 90 --fetchmailrc
/home/gene/.fetchmailrc"
>> >>
>> >> Can you translate that into a 'runcon' style line please?
>> >
>> >Sure. (No guarantees that this is the best or most correct way. :)
>> >
>> >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d
90"
>> > gene
>
>for F8 I think it should be "unconfined_u:system_r:unconfined_t" for
>rawhide i think it is "unconfined_u:unconfined_r:unconfined_t"
and both of those return "invalid context" and fetchmail is not started.
ahh, yeah, i should have paid more attention to the suggestion you were
given on how to use runcon and read the man page again.
runcon -t unconfined_t -- whatever you want to run.
I think i'll have a little chat with dan about this stuff....
>I don't really understand the rest of what you are asking... typically
>we on list like to see the output of ausearch -m AVC -ts recent or some
>other form of the raw denial (its at the bottom of the setroubleshoot
>output) so we actually know what is failing.
That output of "ausearch -m AVC -ts recent" is empty, as is the
setroubleshoot screen after running rc.local three times just now.
The larger problem ATM is that rc.local is NOT being executed at the
end of the bootup. And yet:
I'm at a total loss on this one, did it execute on boot up if you add
enforcing=0 to the kernel boot line?
-Eric
11:51 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Paris wrote:
On Mon, 2008-01-07 at 11:23 -0500, Gene Heskett wrote:
> On Monday 07 January 2008, Eric Paris wrote:
>> On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote:
>>> On Sunday 06 January 2008, Todd Zullinger wrote:
>>>> Gene Heskett wrote:
>>>>>> I've got similar things in /etc/rc.local that used to use su
-c. I
>>>>>> don't recall having them get denied outright, but the
programs that
>>>>>> were run definitely didn't pick up the proper SELinux
contexts. So I
>>>>>> now have a few entries like this:
>>>>>>
>>>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "screen
-dm" tmz
>>>>> I'm afraid I have pretty close to a NDI what that will do, Todd.
>>>>> And your use of the words 'used to' above also tells be your
are
>>>>> doing this su user -c function differently now. Can you elaborate?
>>>>> The manpage for runcon is so concise as to be obtuse.
>>>> I noticed that the processes I started with su -c didn't have the
>>>> proper SELinux contexts, so that's why I added the runcon call. It
>>>> sets up the processes to use the same contexts as they would get if I
>>>> had logged in as tmz and run them (AFAIK). Using runuser is very
>>>> similar to using su. I don't know if you'd have any problems
using su
>>>> instead of runuser or not. I'm far from knowledgeable on the
subject.
>>>>
>>>>> Here is the line in question, in rc.local, that does not now work:
>>>>>
>>>>> su gene -c "fetchmail -d 90 --fetchmailrc
/home/gene/.fetchmailrc"
>>>>>
>>>>> Can you translate that into a 'runcon' style line please?
>>>> Sure. (No guarantees that this is the best or most correct way. :)
>>>>
>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d
90"
>>>> gene
>> for F8 I think it should be "unconfined_u:system_r:unconfined_t" for
>> rawhide i think it is "unconfined_u:unconfined_r:unconfined_t"
> and both of those return "invalid context" and fetchmail is not started.
ahh, yeah, i should have paid more attention to the suggestion you were
given on how to use runcon and read the man page again.
runcon -t unconfined_t -- whatever you want to run.
I think i'll have a little chat with dan about this stuff....
>> I don't really understand the rest of what you are asking... typically
>> we on list like to see the output of ausearch -m AVC -ts recent or some
>> other form of the raw denial (its at the bottom of the setroubleshoot
>> output) so we actually know what is failing.
> That output of "ausearch -m AVC -ts recent" is empty, as is the
> setroubleshoot screen after running rc.local three times just now.
>
> The larger problem ATM is that rc.local is NOT being executed at the
> end of the bootup. And yet:
I'm at a total loss on this one, did it execute on boot up if you add
enforcing=0 to the kernel boot line?
-Eric
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
You are missing the s0
at the end
runcon user_u:system_r:unconfined_t:s0 -- runuser -l -c "fetchmail -d 90"
runcon -t unconfined_t -- runuser -l -c "fetchmail -d 90"
Would also work.
Why are you doing this though? Is this because fetchmail runs under a
context that SELinux is preventing when run from init?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkeCZowACgkQrlYvE4MpobPF5QCeJmNt5AAN6AwRbU5L6cQECyjz
2c4An1fsyV9VuksIL1fFPNJnQa7ZTlFQ
=p9u2
-----END PGP SIGNATURE-----
2:53 p.m.
On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote:
I boot and login at runlevel 3, the everything but X, then run startx
by
hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using
the S99local link exactly the same as it real name, so why doesn't init run
it?
I had something similar happen to me some time in the past, say about Fedora
Core 3, and my init script was hanging (I could see it with pstree) asking
for user input. I would pepper the script with
echo $$ so far so good >> /tmp/cursed-initscript.log
to see if it is started at all and then hangs or exits somewhere.
Davide Bolcioni
--
There is no place like /home.
6:10 p.m.
On Monday 07 January 2008, Davide Bolcioni wrote:
On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote:
> I boot and login at runlevel 3, the everything but X, then run startx by
> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using
> the S99local link exactly the same as it real name, so why doesn't init
> run it?
I had something similar happen to me some time in the past, say about Fedora
Core 3, and my init script was hanging (I could see it with pstree) asking
for user input. I would pepper the script with
echo $$ so far so good >> /tmp/cursed-initscript.log
to see if it is started at all and then hangs or exits somewhere.
Interesting idea Davide
according to pstree, init is indeed still present, top of the list in fact:
init─┬─/usr/bin/sealer
├─acpid
├─artsd
├─atd
├─auditd─┬─audispd───{audispd}
│ └─{auditd}
├─automount───4*[{automount}]
├─avahi-daemon───avahi-daemon
├─console-kit-dae───61*[{console-kit-dae}]
├─crond
├─cupsd
├─2*[dbus-daemon───{dbus-daemon}]
├─dbus-launch
├─dcopserver
├─drift-checker───sleep
├─fetchmail
├─gam_server
├─gconfd-2
├─gpg-agent
├─gpm
├─hald───hald-runner─┬─hald-addon-acpi
│ ├─hald-addon-hid-
│ ├─hald-addon-inpu
│ ├─hald-addon-stor
│ └─hald-addon-usb-
├─hcid
├─2*[heyu]
├─kaccess
├─kded
├─kdeinit─┬─gkrellm───{gkrellm}
│ ├─kio_file
│ ├─klauncher
│ ├─konsole─┬─su───bash───amrecover
│ │ ├─su───bash───pstree
│ │ └─2*[su───bash]
│ ├─konsole───2*[su───bash]
│ ├─konsole─┬─su───bash
│ │ └─su───bash───htop
│ ├─konsole───4*[su───bash───tail]
│ ├─kwin
│ ├─nm-applet
│ ├─puplet
│ └─python
├─kdesktop
├─kgpg
├─kicker
├─kio_uiserver
├─kmail───4*[{kmail}]
├─kmix
├─knotify
├─ksensors
├─ksmserver
├─kwalletmanager
├─login───bash───startx───xinit─┬─X
│ └─ck-xinit-sessio───startkde─┬─kwrapper
│ └─ssh-agent
├─login───bash
├─4*[mingetty]
├─notification-da
├─ntpd
├─pcscd
├─restorecond
├─rklogd
├─rpc.idmapd
├─rpc.statd
├─rpcbind
├─rsyslogd───{rsyslogd}
├─2*[sendmail]
├─setroubleshootd───2*[{setroubleshootd}]
├─spamd───2*[spamd]
├─sshd
├─start_kdeinit
├─udevd
├─xinetd───amandad───amindexd
└─yum-updatesd
OTOH, I have NDI if that is normal. It is also sitting there in an htop
screen showing "init(3)" which I assume is the runlevel. I'll pepper the
last S## before that and see if its hung, and the top of rc.local, but that
doesn't show anyplace, and if I run it by hand, it does everything and exits
cleanly.
Many thanks for the hint.
Davide Bolcioni
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Artistic ventures highlighted. Rob a museum.
6:31 p.m.
On Monday 07 January 2008, Davide Bolcioni wrote:
On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote:
> I boot and login at runlevel 3, the everything but X, then run startx by
> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using
> the S99local link exactly the same as it real name, so why doesn't init
> run it?
I had something similar happen to me some time in the past, say about Fedora
Core 3, and my init script was hanging (I could see it with pstree) asking
for user input. I would pepper the script with
echo $$ so far so good >> /tmp/cursed-initscript.log
And would you believe, it all worked on this reboot. I think I'll go shoot
the neighbors worthless tomcat. This is frustrating, it failed absolutely on
the last 3 reboots.
I put that echo in S98wine, S99anacron, S99 firstboot and S99local, and while
init is still visible in a pstree output, that file looks like this:
2563 so far so good, start of wine
2563 so far so good, end of wine startup
2571 so far so good, start of anacron
2571 so far so good, end of anacron
2581 so far so good, start of firstboot
2581 so far so good, firstboot should exit here
2588 so far so good, start of rc.local
to see if it is started at all and then hangs or exits somewhere.
Davide Bolcioni
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
QOTD:
"A child of 5 could understand this! Fetch me a child of 5."
8:13 p.m.
On Monday 07 January 2008, Gene Heskett wrote:
On Monday 07 January 2008, Davide Bolcioni wrote:
>On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote:
>> I boot and login at runlevel 3, the everything but X, then run startx by
>> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using
>> the S99local link exactly the same as it real name, so why doesn't init
>> run it?
>
>I had something similar happen to me some time in the past, say about
> Fedora Core 3, and my init script was hanging (I could see it with pstree)
> asking for user input. I would pepper the script with
>
> echo $$ so far so good >> /tmp/cursed-initscript.log
And would you believe, it all worked on this reboot. I think I'll go shoot
the neighbors worthless tomcat. This is frustrating, it failed absolutely
on the last 3 reboots.
I put that echo in S98wine, S99anacron, S99 firstboot and S99local, and
while init is still visible in a pstree output, that file looks like this:
2563 so far so good, start of wine
2563 so far so good, end of wine startup
2571 so far so good, start of anacron
2571 so far so good, end of anacron
2581 so far so good, start of firstboot
2581 so far so good, firstboot should exit here
2588 so far so good, start of rc.local
>to see if it is started at all and then hangs or exits somewhere.
>
>Davide Bolcioni
And a PS to the PS if you will. That boot above had an selinux=0 on the grub
kernel line that I had forgot adding earlier this day. I obviously have a
bad case of CRS. So I took it out and rebooted again. Of course it had to
relabel everything, but this time S99local ran just fine including getting
fetchmail started. Repeatable? Damnifiknow.
Thanks for the hints though, that might come in handy yet. Humm, I should
take the double >> back to a single > for the first one, else that file will
get pretty big in a few years. :)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Fortune and love befriend the bold.
-- Ovid
5946
days inactive
5948
days old
selinux@lists.fedoraproject.org
12 comments
5 participants
participants (5)
-
Daniel J Walsh -
Davide Bolcioni -
Eric Paris -
Gene Heskett -
Todd Zullinger